402cron

Signed webhook delivery on a cron schedule — pay per run in USDC on Base via x402. No account, no card, no human.

We guarantee that we tried to deliver your task.
We never pretend we can guarantee what someone else's server does with it.

How it works

1. Pay first. One x402 payment in USDC on Base buys delivery credits. The response carries your management token — shown once, tied to the wallet that paid. Credits never expire.
2. Prove the destination. Register the URL you want us to call — it must be https://. Verification is one request from us to the exact URL you registered: POST, headers X-402cron-Challenge: and X-402cron-Event: verify, JSON body {"challenge":""}. Reply within 5 seconds, without a redirect, with a body that is the bare value or {"challenge":""}; we read the first 512 bytes and do not check the HTTP status (2xx is fine). Then call POST /api/destinations/{id}/verify within 15 minutes of registering. A fixed-response webhook cannot pass: you need an endpoint you can program. Registering a URL that is still pending issues a new challenge and a new signing secret every time — the old secret immediately stops verifying deliveries; a verified URL is left untouched unless you add ?rotate=1. The daily verification allowance (10 per destination, 40 per client, UTC day) does not reset on re-registration. The permission covers that path and everything beneath it — not the whole domain. Your endpoint must be able to return the challenge value we send: a fixed-response catch hook cannot pass, and a sandbox without a public URL cannot receive deliveries at all.
3. Schedule it. Create a task with a 5-field cron expression, always UTC, one minute at the finest. We deliver a signed HTTP request on that schedule.

Every delivery carries an HMAC signature, a timestamp and a delivery id that stays the same across retries. Delivery is at-least-once: if your acknowledgement is lost we will send the same delivery id again, so treat a repeated id as already handled. Answer within 2 seconds — return 202 and do the work in your own background; the timeout is for acceptance, not for finishing.

When things fail

A timeout or an unreachable host is retried, at most 3 attempts per execution, and then the task pauses itself. A 4xx or 5xx from your server is a clear answer, not a fault on our side, so it is never retried — but 20 refusals or 10 server errors in a row pause the task too. The task status always says which of these stopped it, and resuming is one call.

Pricing

You pay per delivery attempt, not per outcome. A 2xx, a 4xx, a 5xx, a timeout and an unreachable host each cost one credit — we tried, and trying is what we charge for. Our own failures cost you nothing, and a skipped execution (the previous one is still running) costs nothing either. One failing cycle is at most 3 credits.

You buy a quantity, never a calendar period: a month that expires while your agent sleeps is a month you paid for and never used.

For builders

Nobody complains: 28 silent failures of a paid API for AI agents — what broke without a symptom while we built this, with the fix and the check for each. More on the blog.

For machines

Who runs it

Georgi Kalchev

I build and maintain my own small web services, working with AI coding agents along the way.

After one of my sites reached 561 million database reads and failed, I started measuring costs carefully, testing everything before release, and being clear about what works and what does not.

Also by the same person: AISkills402 (tested skill files for agents), 402post (paid listings for agents) and 402registry (discoverability audit for agents).

My professional profile is on LinkedIn; I post on X (@AiGenMaster).