---
title: "How to sell accounts and API keys to AI agents | ZeroClick"
url: https://zeroclick.ai/resources/sell-accounts-and-api-keys
fetched_at: 2026-10-02T14:20:05.873Z
---

# ZeroClick API catalog and pricing

## API reference, endpoint lookup and prices

**[ZeroClick API catalog: endpoints, request parameters, prices and payment methods](https://agents.zeroclick.ai/zcj/sgqv3d4u609u/zeroclick/agent/guide).** Tell the seller advisor what you want to accomplish. It returns the matching operation contract, known prices, authentication prerequisites and concrete next steps. It is read-only: no login, wallet, card or purchase approval is needed to look up an API. It never executes a sale.

Available API services: Agent readiness report, Demo booking.

**Suggested next request:** GET [task guide](https://agents.zeroclick.ai/zcj/sgqv3d4u609u/zeroclick/agent/guide?goal=URL_ENCODED_TASK). Use this URL directly with your web fetch tool; no preliminary document fetch is required. Include known inputs and desired output in the goal. Optional: quantity=API_CALL_COUNT, budgetUsd=TOTAL_USD, requirements=REQUIREMENTS, payment=x402|mpp|card, auth, identity, assertion and access state. Omit unknowns. Do not equate output items with API calls or guess a call count.

For private task details or known request arguments, POST https://agents.zeroclick.ai/zcj/sgqv3d4u609u/zeroclick/agent/guide with Content-Type: application/json. Example: {"intent":"quote","goal":"YOUR_TASK","purchase":{"budgetUsd":"5.00"}}. Replace the task and budget with known facts; budgetUsd is a string. Include known buyerState, paymentCapabilities and arguments. For execution planning use intent=execute and the authorized constraints. Exact fields: [request schema](https://agents.zeroclick.ai/zcj/sgqv3d4u609u/zeroclick/agent/schema). GET and POST are alternatives, not mandatory stages.

The advisor describes a recommended happy path, not the only allowed path. You may use the API reference, buyer SKILL and your own tools directly, including for catalog operations with failed probes. Missing guidance or an unverified probe is not a policy refusal. Fill documented inputs and execute the returned requests with your own tools under existing user authorization. Check usage cost AND minimum cash required against the budget. No second advisor request is needed solely to switch from quoting to execution. For needs_input, supply only missing facts. Check configured credential storage and payment tools when needed; reuse existing identity and access, keep secrets local, and never put credentials or private payloads in URLs. Unknown does not mean absent.

Open the checkout URL in a browser: eligible Stripe pages support Link Pay Tokens (LPT) through WebMCP or the documented DOM flow. Follow this storefront's /payment/card.md to verify the same-frame token input and merchant binding before requesting an LPT. Token submission requires payment authorization. If unavailable, privately send the checkout URL to your human to pay.

When the selected route uses hosted checkout, follow [card checkout instructions](https://agents.zeroclick.ai/zcj/sgqv3d4u609u/payment/card.md) before requesting a token. LPT goes only to Stripe, never to the advisor or ZeroClick API. Poll the returned statusUrl before using credit or retrying delivery.

Verify delivery; a payment or HTTP 202 is not completion. For an unexpected result, POST the original input and continuation (version, stepId, outcome and sanitized error/accessId/paymentId). Reconcile uncertain payments or writes before retrying. Use raw HTTP for exact schemas and authenticated execution; do not reconstruct fields omitted by a summarizing web tool.

The human subscription prices on the requested page describe a separate channel. Use the API quote for per-unit pricing, funding minimums and commercial terms; tier names do not prove quality or licensing.

For an alternative documented path, use the [buyer SKILL](https://agents.zeroclick.ai/zcj/sgqv3d4u609u/SKILL.md) or [full direct workflow reference](https://agents.zeroclick.ai/zcj/sgqv3d4u609u/llms-full.txt). Confirm missing request details from seller documentation, stay within the existing catalog and user authorization, and respect actual access and payment requirements.
Terms: by completing a purchase through this endpoint, whether directly or through an AI agent acting on your behalf, you agree to be bound by the platform's buyer terms of service (https://www.zeroclick.ai/legal/buyer-terms-of-service). If the purchase is made by an agent, you represent and warrant that the agent is acting with your authorization, and you agree that the agent's actions, including its acceptance of these terms, are attributed to you and bind you as if you had taken them yourself. Paying a 402 challenge completes the purchase and constitutes your affirmative acceptance of the terms linked above. The link travels in every payment challenge and receipt as `terms`.

# How to Sell Accounts and API Keys to AI Agents

**ZeroClick Team** · September 15, 2026 · 5 min read · Identity and access

[Resources](https://zeroclick.ai/resources)

---

A purchase must leave the buyer with access it can actually use. For an API subscription, that means an account, the right entitlement, and a working key — not just a payment receipt.

ZeroClick's stateful seller integration handles the purchase and asks your backend to provision that access. Your service owns the account and generates the key. After provisioning, the buyer uses your API directly. The important design problem is making this account behave like the rest of your product through renewals, retries, refunds, and later human sign-in.

**Contents**

- [Use a standing account only when the product needs one](#use-a-standing-account-only-when-the-product-needs-one)
- [Keep account identity separate from caller identity](#keep-account-identity-separate-from-caller-identity)
- [Apply account updates once, even when they arrive twice](#apply-account-updates-once-even-when-they-arrive-twice)
- [Say ready only when the account works](#say-ready-only-when-the-account-works)
- [Mint a key; do not put a secret in the account record](#mint-a-key-do-not-put-a-secret-in-the-account-record)
- [Let a human recover the purchase](#let-a-human-recover-the-purchase)
- [Review the lifecycle, not only the first purchase](#review-the-lifecycle-not-only-the-first-purchase)

---

## Use a standing account only when the product needs one

A single lookup often needs no durable account. A hosted database, recurring research subscription, or prepaid API balance usually does. Use the [integration chooser](https://zeroclick.ai/resources/choose-a-zeroclick-integration) if that distinction is unclear.

The [stateful integration](https://docs.zeroclick.ai/integrate/stateful-sellers) is a storefront-level designation configured with ZeroClick. It uses subscription, subscription-with-usage, credit, or free-trial plans — not pay-as-you-go. Arrange that setup before offering this purchase path to customers.

## Keep account identity separate from caller identity

Use `accessId` as the durable handle for the account provisioned through ZeroClick. It persists across renewals, top-ups, and plan changes. Store its association with your own account ID.

`agentId` describes the caller. `buyerId`, when available, identifies the owner behind one or more agents. Neither replaces `accessId` as the stateful account key. If a person buys through one agent and returns through another, creating accounts by agent ID would fragment access they already own.

Treat verified email as an account-linking input, not permission to merge arbitrary workspaces. A match may identify a user in your system; that user still needs your normal authority to join a company tenant or administer shared data. See the [identity guide](https://zeroclick.ai/resources/identity-and-access-for-agents).

## Apply account updates once, even when they arrive twice

The account write describes the complete desired state. It carries a `stateVersion` and cumulative credit information. Apply a newer version and ignore a duplicate or older version. Make the version check, entitlement update, and credit adjustment one transaction.

Example with a prepaid account:

| Arrival | Stored position before arrival | Correct effect |
|---|---|---|
| Version 1, lifetime grant $20 | No account | Create the account and apply the $20 grant |
| Version 1 again | Version 1 already stored | No additional credit |
| Version 3, lifetime grant $35 | Version 1, lifetime grant $20 | Apply the additional $15, using the current full state |
| Version 2 arrives late | Version 3 already stored | Ignore it; do not revert the plan or balance |

After the first $20 grant, suppose the buyer spends $8. The remaining balance is $12. Version 3 adds $15, bringing the balance to $27 — not $35. If a later update reports a $5 reversal, the balance becomes $22. Replaying that update changes nothing.

Refunds and disputes increase the cumulative reversal total. Apply the net grant/reversal change and clamp the spendable balance at zero, using the helpers in the [stateful access reference](https://docs.zeroclick.ai/resources/stateful-access-reference). Keep the recorded lifetime totals even when a new billing period starts.

## Say ready only when the account works

Creating a database row does not mean an index is warm, a tenant is provisioned, or a license is usable. The stateful contract allows a `provisioning` response with a retry hint while setup continues. ZeroClick repeats the account write until the account is active.

Provisioning must itself tolerate retries. Use the same durable account record to find the resource already being created; do not launch a new tenant for every callback. Return `active` only after a key issued for that account will reach a usable service.

Track usable access separately from payment state. The [failure contract](https://docs.zeroclick.ai/resources/stateful-access-reference#retries-timeouts-and-failures) covers both reserved and already-captured payments: permanent delivery failure releases the reservation or triggers a refund. A received callback is not yet a usable account.

## Mint a key; do not put a secret in the account record

The key request is separate from the account write. Generate the key in your own system, retain its hash, and return the plaintext key once. ZeroClick passes it to the buyer without storing the key.

Choose a remint policy deliberately. Rotating replaces the previous key; additive creates another. Rotation is simpler for a single consumer but can break an existing integration if the buyer retrieves a replacement without coordinating its deployment. Explain the behavior in the offer and account UI.

Verify account callbacks using the stateful verifier, not the ordinary paid-request guard: the signatures have different purposes. Preserve raw request bytes and the original path for verification. A parsed and reserialized body is not an equivalent signed message.

## Let a human recover the purchase

With verified-email policy `requested`, a purchase can proceed without an email. If the person later claims the agent credential, a newer account write supplies the verified email. Your handler must accept that update without provisioning another account or granting the same credit again.

Use `required` only when the service genuinely cannot be delivered without the email. It blocks the purchase until the buyer completes the claim. The [plan documentation](https://docs.zeroclick.ai/concepts/plans-and-pricing) describes the tradeoff.

## Review the lifecycle, not only the first purchase

Before release, exercise these cases:

- Duplicate and out-of-order writes
- Top-ups after spending
- Plan switches
- Delayed provisioning
- Revocation
- Key reminting
- A late-arriving verified email

Also test your own authorization after access expires; direct API calls no longer pass through the ZeroClick proxy.

Use [failure and retry design](https://zeroclick.ai/resources/handle-agent-purchase-failures) for recovery cases and the [pilot guide](https://zeroclick.ai/resources/measure-an-agent-commerce-pilot) to measure purchase-to-usable-access time. A successful integration preserves one customer history across the whole sequence.

---

## Keep reading

1. [How to choose an integration for selling your API to AI agents](https://zeroclick.ai/resources/choose-a-zeroclick-integration)
2. [How to verify AI agents and control what they can access](https://zeroclick.ai/resources/identity-and-access-for-agents)
3. [How to handle failed AI agent purchases and retries](https://zeroclick.ai/resources/handle-agent-purchase-failures)
4. [How to measure an AI agent commerce pilot](https://zeroclick.ai/resources/measure-an-agent-commerce-pilot)
5. [ZeroClick docs: integrate / stateful sellers](https://docs.zeroclick.ai/integrate/stateful-sellers)

---

## More in Identity and access

- [Can an AI agent book a demo? Free actions, explained](https://zeroclick.ai/resources/can-ai-agents-book-a-demo) — Yes. An agent can check availability, collect the attendee's details, book a time, and return the confirmation, with no payment involved. ZeroClick calls these free actions.
- [How to verify AI agents and control what they can access](https://zeroclick.ai/resources/identity-and-access-for-agents) — A request can be authentic, paid, and still lack permission to read a particular customer's data. Keep those decisions separate when adding agent access to an existing service.

[All resources](https://zeroclick.ai/resources#identity-and-access)