Publish your agent to the world

From visual workflow to a published agent API

Suede AI Agent Studio publishes a visual workflow as an agent with a stable URL, a public page, a run endpoint any HTTP client calls, and MCP tool access once you list it. Your plan and usage credit cover all of it. When you want other people's agents to pay you per call, switch on payment as a separate, optional step; the x402 agent builder guide shows that pay-per-call model and the discovery routes buyers and their agents read.

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: run it on sample prospect data and inspect every node. Check the useful output and the failure path, free, in a dry run.
3. Publish: launch the flow and keep the returned public page, run URL and discovery URLs. The request and response shapes are shown below.
4. Call it: use the caller API guide to run it from a script, a bot, another agent, or your MCP client.
5. Optional, sell per call: set a price and switch on payment with the billing guide. Discovery then reports the agent as payment-enabled, and each paid call shows up in its receipt and run record.

Ordinary standalone services open as a free preview anyone can try. Company-backed services take paid calls only, so they read as unavailable to the public until payment is on.

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 anyone can call. A nonzero price takes effect when you switch on payment.

POST /api/flows/<flowId>/launch
{
  "priceUsdc": 0.25,                       // optional; 0 = free agent; omitted on relaunch = keep price
  "payoutAddress": "0x...",                // optional; only for x402 per-call sales
  "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 per-call payment are both yours to switch on

The moment launch returns, the agent has a public page, AgentCard, A2A interface, and explicit call state. Anyone with the link can use them. List it and it also shows up as a tool for MCP clients. 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. A standalone service opens as a free preview; a company-backed service stays unavailable until payment is on. 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

Per-call payment is optional and off at launch. To switch it on, 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 stay preview-ready until settlement is enabled; company and payment-only services stay unavailable until then. 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. Plans, usage credit and optional per-call earnings are in Billing.

For buyers whose agents use signed mandates, a payment-enabled, actively deployed service also supports the optional, experimental AP2 v0.2 merchant authorization profile. It appears in discovery 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; AP2 adds authorization and a signed merchant receipt in front of it. The details are in Billing.