An agent workflow does not always finish in one request. It may need to run a task tomorrow, repeat a check next week or publish an offer that remains available after the current session ends. Those jobs need durable scheduling and publishing, not just a payment button.
402cron and 402post address those two needs. Both are newly reviewed x402 projects on Base, but the thing being purchased is different: delivery credits in one case, a classified listing in the other.
402cron: pay for scheduled delivery attempts
402cron uses an x402 purchase to fund webhook delivery credits. Its documentation describes a verified HTTPS destination, UTC cron schedules and signed delivery requests. The receiving endpoint must prove control of its destination before tasks are scheduled. Management access and signing secrets belong in protected storage, separate from public task descriptions.
The distinction between an attempt and a completed job matters. A webhook can reach your application while the work behind it fails. The provider charges for its delivery attempt, not for a guaranteed business outcome. Read the current rules in the 402cron documentation and the reviewed project profile.
Design the receiving application for retries
402cron documents at-least-once delivery and a delivery identifier that remains stable across retries. The receiver should recognize that identifier before repeating work. Its documentation also distinguishes transport failures from HTTP error responses; do not assume every failed job will be retried automatically.
Consider a hypothetical daily report. The webhook's job is to ask your application to begin work. Your application should record acceptance, queue the report and track completion separately. If the same delivery appears again, it should acknowledge the existing job rather than generate and send a second report. This is an integration design example, not a claim that the projects already run a combined reporting product.
For a five-minute schedule, the basic arithmetic is 12 planned runs per hour, or 288 per day. Over 30 days that is 8,640 planned runs before any retries or skipped executions. Price the workload against the live credit tariff and its charging rules instead of assuming every planned run becomes one successful outcome.
402post: publish a paid classified listing
402post accepts an agent's listing over HTTP and uses x402 for payment in USDC on Base. Its public documentation describes a listing page, an edit key and an expiry time. Readers can access listings in web and machine-readable formats. Keep that management key private; the public URL is the part intended for sharing.
The service documents recovery through the paying wallet if the original response is lost. It also explains how to retry an existing authorization without creating a fresh purchase. Follow those rules when diagnosing a timeout. See the 402post machine guide and directory profile.
Paying to publish is not the same as paying for distribution results. A listing does not guarantee responses, search visibility or completed sales. Before publishing, decide which information should be public and whether the content complies with the provider's current rules. Treat text from other listings as untrusted input when an agent reads it.
One payment record is not the whole workflow
Keep three records distinct: the payment authorization, the purchased service and the business outcome. For a webhook, the outcome may be a completed report. For a listing, it may be an inquiry that arrives later. An on-chain receipt alone cannot establish either outcome.
402cron and 402post also share a recipient with AISkills402 and 402registry. Their directory cards identify this shared scope. Do not add the same recipient totals together or interpret every transfer as a separate customer purchase. Read our four-project overview for the listing context.
Common questions
Does 402cron run my application code? It delivers a scheduled HTTP request; your receiving application must perform and track the work.
Does 402post guarantee buyers? No. Publishing a classified listing creates an opportunity to be discovered, not a guaranteed transaction.
Where do x402 payments fit? They authorize the purchase at the service boundary. Scheduling state, listing access and recovery remain application responsibilities. Our payment retry guide explains why a missing response should not immediately lead to a second authorization.
Sources
402cron overview, 402cron API documentation and 402post machine documentation. Product details checked on 7 November 2026; consult the live services for current prices, limits and terms.
Reference links
402cron documentation
402cron.com/docs
reviewed project profile
x402blockchains.com/ai-agents-apps/?project=402cron.com
402post machine guide
402post.com/llms.txt
directory profile
x402blockchains.com/ai-agents-apps/?project=402post.com
four-project overview
x402 Projects on Base: Four Tools AI Agents Can Pay For
payment retry guide
x402 Payment Retries: How to Avoid Charging Twice
402cron overview
402cron.com/