---
title: "How to price an API for AI agents | ZeroClick"
url: https://zeroclick.ai/resources/price-an-api-for-agents
fetched_at: 2026-10-02T20:31:45.623Z
---

# 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/c0rsw7wx1zrz/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/c0rsw7wx1zrz/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/c0rsw7wx1zrz/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/c0rsw7wx1zrz/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/c0rsw7wx1zrz/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/c0rsw7wx1zrz/SKILL.md) or [full direct workflow reference](https://agents.zeroclick.ai/zcj/c0rsw7wx1zrz/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 price an API for AI agents

[ZeroClick Team](https://x.com/zeroclick) · September 15, 2026 · 7 min read · Packaging and pricing

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

Start with a unit the buyer can understand before a call and your system can measure afterward. Then put a bound on the work. A cheap request with unpredictable total usage is harder to buy - and harder to operate - than an offer with a clear maximum.

This guide helps an API seller produce a first pricing contract: the billable unit, a starting rate, the spending limit, and the rules for empty results and failed requests. The extraction example uses illustrative prices; choose your launch rate from your own costs and buyer evidence.

If you have not decided what result the buyer receives, start with [packaging your first service](https://zeroclick.ai/resources/package-agent-services). Pricing cannot make an ambiguous offer precise.

**Contents**
- [Choose what a paid unit means](#choose-what-a-paid-unit-means)
- [Price the expensive valid request, too](#price-the-expensive-valid-request-too)
- [Make the maximum visible before work starts](#make-the-maximum-visible-before-work-starts)
- [Choose how the buyer funds usage](#choose-how-the-buyer-funds-usage)
- [Decide what happens when the answer is empty](#decide-what-happens-when-the-answer-is-empty)
- [Review the contract with one customer-sized workload](#review-the-contract-with-one-customer-sized-workload)
- [Move from a price to an implementation](#move-from-a-price-to-an-implementation)

## Choose what a paid unit means

Imagine a document-extraction API. A customer sends a file and asks for a structured table. Here are three different products you could sell:

| Unit | What the buyer can predict | What you must define |
|---|---|---|
| One request | Cost of an attempt within a stated file-size limit | Whether an empty extraction is still a successful, billable response |
| One processed page | Cost from document length, within a supported range | Whether blank, unsupported, and repeated pages count |
| One returned record | Cost from the amount of output | What makes a record billable and how you cap the number returned |

Start with pages when document length is the main driver of processing cost. A fixed request price is simpler when files have a tight size limit. Per-record pricing makes sense only when both sides can agree on the record definition; do not quietly substitute "attempted record" for "usable record."

Choose one unit and publish its meaning beside the price. ZeroClick's catalog separates the [service and its meter](https://docs.zeroclick.ai/concepts/stores-services-meters), so the billable measurement need not be the name of the API route.

## Price the expensive valid request, too

Use your own cost observations. Include upstream APIs or models, compute, storage, and the expected cost of retrying work. Separate variable delivery cost from fixed engineering and support costs; neither disappears because a buyer is an agent.

Suppose an illustrative ten-page extraction costs $0.08 to deliver, including the retries you budgeted for. At a price of $0.20, the contribution before other fees and fixed costs is $0.12, or 60% of revenue. If a difficult but permitted input costs $0.17, that same price leaves just $0.03, or 15%.

That is a reason to inspect the workload, not proof you should charge $0.20. You might narrow the accepted file types, cap document size, change the unit, or separate expensive processing into a different offer. Do not average an unbounded expensive case into a reassuring mean.

Before selecting a rate, record a normal case, an expensive valid case, and a failure case. If you do not have those observations, keep the rate provisional and limit the launch volume.

## Make the maximum visible before work starts

For a worked pricing example, suppose you choose **$0.02 per processed page**, with a **50-page limit per request**. The largest authorized charge in this example is $1.00.

| Request | Authorized maximum | Actual usage | Charge under this proposed contract |
|---|---|---|---|
| Known 10-page document | $0.20 | 10 pages | $0.20 |
| Unknown length, bounded at 50 pages | $1.00 | 37 pages | $0.74 |
| Document would exceed the supported limit | No work beyond the bound | Stop at the boundary | Follow the stated rejection or partial-delivery policy; never silently increase the limit |

The product must enforce the limit, not merely display it. For variable work in ZeroClick, the [ceiling-charge contract](https://docs.zeroclick.ai/integrate/charge-up-to-a-maximum) lets you declare a maximum and settle reported actual usage. It also explains which payment paths can authorize a ceiling. If you know the quantity in advance, use the exact quantity instead of making the buyer authorize an unnecessarily large reserve.

Avoid mixing a maximum with a minimum. "Up to $1" should not mean "we always charge $1." If partial delivery is possible, define whether the customer receives a useful partial result and what is billed.

## Choose how the buyer funds usage

Choose a billing mode after the unit and bound are clear:

- **Per-call payment:** a useful starting point for occasional purchases when the buyer wants to evaluate each request.
- **Prepaid credit:** useful when buyers expect repeat usage and want to fund a balance rather than approve each purchase separately.
- **Subscription:** useful for recurring access with explicitly defined coverage.
- **Subscription plus usage:** useful when a recurring fee includes a stated usage budget and additional work remains metered.

ZeroClick documents these modes, their inclusion rules, and monetary precision in [plans and pricing](https://docs.zeroclick.ai/concepts/plans-and-pricing). Do not assume "subscription" means unlimited processing or that every price format is valid on every payment path. Treat the plan's coverage as part of the offer, not fine print discovered after payment.

## Decide what happens when the answer is empty

A valid search with no matches is not the same event as an outage. An extraction that finds no rows may still have completed the specified work. Choose the policy based on the unit you promised:

| Situation | Decision to make before launch |
|---|---|
| Invalid input | Reject before doing paid work where possible; identify what needs correction |
| Valid input, empty result | Say whether successful processing is billable even when the result is empty |
| Partial result | Define the useful partial output, its status, and the billable quantity |
| Service failure | Return a recognizable failure and follow the payment system's settlement rules |
| Timeout followed by retry | Define how to check the first attempt before starting or billing a second |

Do not encode these cases as identical successful responses. With ZeroClick, follow [usage settlement](https://docs.zeroclick.ai/integrate/settle-usage), including when and how to report actual quantities. A payment receipt is not a substitute for knowing what your API delivered.

## Review the contract with one customer-sized workload

Before broad release, check whether a buyer can answer: What will this request cost at most? What counts toward usage? What happens if the output is empty? Can I safely retry?

Then reconcile your service logs against the billed quantities for the same attempts. For our extraction example, a successful review would account for the submitted file, accepted page limit, pages processed, returned result, and charged amount. A mismatch belongs in the implementation backlog, not in an explanatory paragraph on the pricing page.

Watch completed useful results and repeat use alongside revenue. A lower price that produces more retries or more confusing empty results may not improve the customer's task - or your economics.

## Move from a price to an implementation

The example leaves you with a concrete starting offer: $0.02 per processed page, at most 50 pages per request, actual-usage settlement, and a stated empty-result policy. Resolve one remaining choice before implementation: reject an oversized file before processing, or return and bill a useful partial result within the cap.

Test that contract against your normal, expensive, and failure cases, then implement it using the [seller integration documentation](https://docs.zeroclick.ai/integrate/overview).

If payment infrastructure is still an open choice, read [x402 for API sellers](https://zeroclick.ai/resources/x402-for-api-sellers) or [MPP for API sellers](https://zeroclick.ai/resources/mpp-for-api-sellers). For account requirements, card payment, and the work ZeroClick handles, use the [seller FAQ](https://zeroclick.ai/faq).

## Keep reading

1. [How to package your product into a service an agent can buy](https://zeroclick.ai/resources/package-agent-services)
2. [x402 for API sellers: what it handles and what you still need to build](https://zeroclick.ai/resources/x402-for-api-sellers)
3. [MPP for API sellers: payment methods, sessions, and implementation choices](https://zeroclick.ai/resources/mpp-for-api-sellers)
4. [ZeroClick docs: concepts / stores, services, meters](https://docs.zeroclick.ai/concepts/stores-services-meters)

## More in Packaging and pricing

- [What makes a product agent-purchasable?](https://zeroclick.ai/resources/what-makes-a-product-agent-purchasable) — A product is agent-purchasable when an authorized agent can understand an offer, obtain the required access, and receive a usable result.
- [How to package your product into a service an agent can buy](https://zeroclick.ai/resources/package-agent-services) — Start with one useful result that a buyer can describe, request, and check.
- [How to choose an integration for selling your API to AI agents](https://zeroclick.ai/resources/choose-a-zeroclick-integration) — Start with what the buyer must have after paying. One response, a job result, and a reusable API key require different implementations.

[All resources](https://zeroclick.ai/resources#packaging-and-pricing)