New: Connect AI assistants via MCP

Core Concepts

Agent Payment Check

Agent Payment Check (x402 / MPP)

The agent payment check is a sub-check for HTTP monitors that understands machine payments. An agent-payable endpoint is supposed to answer an unpaid request with HTTP 402 Payment Required and a payment envelope describing what to pay. A normal uptime check calls that an outage. This check treats a 402 with a valid envelope as the healthy state, parses the envelope on every check, and opens an incident when the endpoint stops asking for payment correctly or starts asking for something different.

Sentinel never pays. It sends the same unpaid request an agent sends before deciding whether to pay, reads the challenge, and stops there. Nothing is signed and nothing is settled.

Use Cases

  • You sell to agents — a deploy that drops the envelope, a config change that moves the pay-to address, or a facilitator outage all look like uptime to a plain check
  • Your agent depends on a paid API — pin the price you agreed to and find out when the seller changes it, moves network, or rotates the wallet
  • You run a registry or marketplace — every service in Sentinel's own agent directory is verified this way, with the observed price published beside the stated one

How It Works

  1. Sentinel requests the paid route from every region on the monitor's interval, without a payment header
  2. The response must be an HTTP 402; a 200, a 500, a redirect or a timeout fails the check
  3. The payment envelope is parsed: x402 v2 from the payment-required header, x402 v1 from the JSON body, or an MPP challenge from WWW-Authenticate: Payment
  4. If you set expected values, the envelope's price, network and pay-to address are compared against them
  5. Any failure opens an incident at critical severity; when the envelope matches again, it resolves

Setting Up the Check

  1. Create or edit an HTTP monitor whose URL is the paid route itself (the endpoint that answers 402), not a docs page or manifest
  2. Set the method and, for POST routes, a JSON body the endpoint accepts. The endpoint should answer 402 before it validates the body
  3. Under check types, enable Agent Payment
  4. Optionally fill in the expected amount, network and pay-to address. Read them off a real 402 response so the values match what the endpoint advertises
  5. Save. The first check runs immediately from every region

Supported Protocols

Protocol Where the envelope lives
x402 v2 Base64 JSON in the payment-required response header
x402 v1 JSON body with an x402Version key
MPP Stripe's Machine Payments Protocol: a WWW-Authenticate: Payment … challenge header

The check tries them in that order and records which one it found. An endpoint that offers both (some serve an x402 header and an MPP challenge together) is read as x402 v2.

Expected Values

All three are optional. Leave them blank and the check asserts only that a 402 with a parseable envelope came back.

Setting Compared against Example
amount The envelope's price in USD. Atomic USDC amounts (6 decimals) are normalized for you, so 10000 on the wire matches 0.01 0.01
network The payment network. Use the CAIP-2 id the endpoint advertises; for MPP challenges, tempo eip155:8453
pay_to The recipient address, compared case-insensitively. Always paste the full address 0x325b…d430

Endpoints that advertise several offers (more than one network, or tiered prices) are fine: set the values you care about and leave the rest blank. Asserting one amount against an endpoint that legitimately offers two prices will fail on the one you didn't mean.

What Opens an Incident

Condition Reason shown
Any status other than 402 Expected an HTTP 402 payment challenge, got HTTP 200
402 with no recognizable envelope 402 without a recognizable payment envelope
Price differs from amount Expected $0.01, envelope says $0.05
Recipient differs from pay_to Pay-to address changed
Network missing from the envelope Expected network not offered

Failures alert as critical, through every channel the monitor routes to, with a repeat at most once an hour while the condition persists. Recovery notifies once the envelope matches again.

The Observed Envelope

Each successful check stores the parsed envelope on the monitor: protocol, and for every offer the price in USD, network and pay-to. The monitor page shows it, and the API returns it, so when something breaks you can see exactly what the endpoint was advertising. In Sentinel's agent directory this is the "observed" price published beside each listing's stated pricing.

API, MCP, CLI and Terraform

The check is the payment entry in check_types, configured through payment_settings. Supplying expected values enables the check on its own. 

POST /api/v1/monitors
{
  "url": "https://api.example.com/v1/signals",
  "monitor_type": "http",
  "http_method": "POST",
  "request_body": "{\"q\":\"test\"}",
  "check_types": ["payment"],
  "payment_settings": {
    "expected": {
      "amount": "0.01",
      "network": "eip155:8453",
      "pay_to": "0x325bdF6F7efAB24a2210c48c1b64cAb2eAe1d430"
    }
  }
}

The CLI takes the same object with --check-types payment --payment-settings '{…}', the MCP create_monitor and update_monitor tools accept payment_settings directly, and the Terraform provider exposes it as the payment_settings attribute on sentinel_monitor. See the monitors API reference for the full field list.

Availability and Limits

  • Available on every plan, including free, at the check interval your plan allows
  • HTTP monitors only
  • Cannot be combined with keyword or JSON assertions on the same monitor, since the 402 body is not the page an agent would receive after paying
  • Sentinel reads the challenge only; it never signs or settles a payment
API MonitoringPing Monitoring