Publish a visual workflow as an x402 API

Can a visual AI agent builder publish a pay-per-call API?

Yes. Suede AI Agent Studio can publish a visual workflow as a stable API endpoint. Publishing the endpoint and enabling x402 payments are separate steps. The service's current call state determines whether a caller can preview it, pay to run it, or cannot call it.

1. Build: choose a lead-qualification template or connect Input, LLM and Output nodes. Define the prospect fields and the structured qualification result. See building flows.
2. Test: use sample prospect data and inspect the run before launch. Check both the useful output and the failure path. A dry-run result is not proof of a live paid call.
3. Publish: launch the flow, then save the returned public page, run URL and discovery URLs. The request and response shapes are shown below. An intended nonzero price alone does not switch payments on.
4. Enable payments: complete the requirements in the payment guide. Confirm that discovery reports payment-enabled and read the current x402 requirements before a caller pays.
5. Verify the caller experience: use the caller API guide to distinguish an unpaid 402 challenge from a paid run and its result. Check the actual receipt and run record before claiming a successful sale.

Ordinary standalone services may advertise preview. Company-backed or otherwise unavailable services do not gain a public dry-run path merely because they have a published URL. Verify actual receipts and run records when testing the workflow.

One request, an agent out the other side

From the studio, the Launch button does this for you; from code, it is a single authenticated request. The price is optional; a flow launched with no price (or a price of 0) becomes a free agent whose endpoint never issues a payment challenge. A nonzero intended price still does not enable payment by itself.

POST /api/flows/<flowId>/launch
{
  "priceUsdc": 0.25,                       // optional; 0 = no payment challenge; omitted on relaunch = keep price
  "payoutAddress": "0xYourWallet...",      // optional; EVM address your payouts settle to
  "listed": true                           // optional; list in the public directory. Omitted: a first launch stays unlisted, a relaunch keeps the current listing
}

The response contains everything an integration needs:

{
  "agent":  { ... },                        // the published agent record
  "slug":   "lead-qualifier-<suffix>",       // stable across relaunches
  "urls": {
    "run":    "/api/agents/<id>/run",       // behavior follows current public call state
    "card":   "/api/agents/<slug>/.well-known/agent-card",
    "x402":   "/api/agents/<slug>/.well-known/x402",
    "a2a":    "/api/agents/<slug>/a2a",
    "public": "/a/<slug>",                  // human-readable page
    "webhook": "..."                        // only if the flow has a Webhook node
  },
  "schedule": { "cron": "...", "nextRunAt": ... },   // only if a Schedule node exists
  "payout":   { ... },
  "webhook":  { "url": "...", "secret": "..." },     // secret shown ONCE, save it
  "listed":   false                                  // whether it appears in public discovery
}

What launch checks before anything goes live

Launch validates the flow before any writes, so a failed launch never leaves a half-published agent behind. The checks, in order:

Shown once, kept forever

If the flow has a Webhook node, launch generates the HMAC signing secret server-side and returns it exactly once, in the launch response; it cannot be retrieved later. Save it wherever the third-party service that will call your webhook keeps its secrets. If it is lost, rotate it with POST /api/agents/<id>/webhook/rotate.

Relaunching an agent that already has a webhook endpoint deliberately does not rotate the secret; whatever external service is already signing requests keeps working. The signing scheme itself (HMAC-SHA256 over timestamp.body, 5-minute staleness window) is documented in the Webhook node reference, with a worked signing example.

Listing and settlement are both opt-in

The moment launch returns, the agent has a public page, AgentCard, A2A interface, and explicit call state. Anyone with the link can use them. It is private by default: it appears in the directory and the discovery feeds below only when you list it, with "listed": true at launch, from its page or your Workspace, or with POST /api/agents/<id>/listing and {"listed":true}. An unlisted agent stays out of the directory, catalog, root discovery documents, MCP tools, and sitemap, and its page is kept out of search results. An ordinary standalone service may expose a preview; a company or otherwise unready service may be unavailable. Payment-enabled services expose active x402 terms:

# a listed agent appears with its preview, payment-enabled, or unavailable state:
curl https://agents.suedeai.ai/api/catalog                 # catalog with payment readiness
open https://agents.suedeai.ai/agents                      # human directory
curl https://agents.suedeai.ai/.well-known/x402            # all states + enabled payment terms

Launch does not turn on real settlement. To opt an agent in, the owner sends POST /api/agents/<id>/settlement with {"live":true} (the launch response returns this URL as settlementEndpoint); the platform must also have live settlement switched on. Ordinary standalone services can remain preview-ready until settlement is enabled; company and payment-only services may instead be unavailable. Launch also does not freeze the flow; relaunch after editing to update the live agent. The slug, and therefore every URL above, stays the same across relaunches; a relaunch with a new priceUsdc changes the payment terms callers see on their next 402 challenge, if the service is payment-enabled.

What callers experience on the other side of this endpoint (the 402 flow, request/response shapes, rate limits) is documented in API for callers. What you earn per call is in Payments.

Launch also does not enable AP2 by itself. A payment-enabled, actively deployed service may be eligible for the experimental AP2 v0.2 merchant authorization profile, but it appears in discovery only when AP2_MODE is optional or required and the platform's signing key, issuer trust, and durable replay storage are ready. The advertised extension URI is https://github.com/google-agentic-commerce/ap2/v1. x402 remains the settlement rail; the AP2 layer is a gated authorization and merchant-receipt profile, not a claim that Suede operates every AP2 role.