---
title: "How to package your product into a service an agent can buy | ZeroClick"
url: https://zeroclick.ai/resources/package-agent-services
fetched_at: 2026-10-02T11:08:17.901Z
---

# 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/cslffz2br7t2/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/cslffz2br7t2/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/cslffz2br7t2/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/cslffz2br7t2/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/cslffz2br7t2/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/cslffz2br7t2/SKILL.md) or [full direct workflow reference](https://agents.zeroclick.ai/zcj/cslffz2br7t2/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 package your product into a service an agent can buy

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

**Contents**
- [Choose a result, not a feature list](#choose-a-result-not-a-feature-list)
- [Write the input and output contract](#write-the-input-and-output-contract)
- [Decide what the buyer is paying for](#decide-what-the-buyer-is-paying-for)
- [Separate access from fulfillment](#separate-access-from-fulfillment)
- [Make failure behavior part of the offer](#make-failure-behavior-part-of-the-offer)
- [Give the buyer a clear starting point](#give-the-buyer-a-clear-starting-point)
- [Check one complete purchase-to-result path](#check-one-complete-purchase-to-result-path)
- [Prepare the first service for review](#prepare-the-first-service-for-review)

Start with one useful result that a buyer can describe, request, and check. "Access our platform" is too vague for a first offer. "Search a product catalog using these constraints" or "enrich this company domain" gives the buyer a concrete input and an output it can use.

Keep the service narrow enough to explain, but complete enough to solve its intended part of the task. The smallest endpoint in your codebase is not always the smallest useful purchase.

## Choose a result, not a feature list

Write a one-sentence offer before choosing a price:

> Given this input, return this result, within these limits.

For product search, that might mean returning candidate offers for a query with explicit price, currency, and merchant constraints. For company enrichment, it might mean returning available company fields for a supplied domain.

Search and enrichment have different inputs and success criteria. [Affiliate.com's Product API](https://guides.affiliate.com/api-reference/products/search) describes search inputs and product records. [ByteMine's OpenAPI](https://www.bytemine.ai/openapi.json) distinguishes company and contact operations. Use the actual contract to decide what can be promised.

Ask three questions:

- Can the buyer supply the necessary input without a long consultation?
- Can your system deliver an interpretable result repeatedly?
- Can the buyer tell a useful result from an unresolved or failed request?

If one answer is no, improve the offer or its prerequisites before adding a payment step.

## Write the input and output contract

A buyer should not need to reverse-engineer what a paid call means. Specify required inputs, optional constraints, and the meaning of missing output.

| Contract decision | Product-search example | Company-enrichment example |
|---|---|---|
| Required starting point | Query or supported identifier | Company domain or another documented input |
| Scope | Currency, budget, and permitted merchants | Intended company identity and requested information |
| Useful result | Candidate products with offer context | Available fields attached to the matched company |
| Unresolved result | No candidates meet the request | No confident company match |
| Important boundary | A listed price is not delivered cost | A domain match does not establish every corporate relationship |

Do not promise facts the response does not contain. If a product record has no delivery eligibility, do not sell the call as "find a product that ships to this address." If enrichment lacks a requested field, return that absence clearly rather than inviting a model to fill it in.

Include one realistic request and one response example in the service documentation. Label invented examples and retain important empty or partial cases.

## Decide what the buyer is paying for

Choose a billing unit that the buyer can predict and you can measure. A request, returned record, processing unit, or access period can imply very different economics.

ZeroClick separates the [service from its meters](https://docs.zeroclick.ai/concepts/stores-services-meters): the service is the purchasable capability; a meter records a billable quantity. Prices belong to plans, not to the meter name alone.

For a first search offer, decide whether the charge covers one bounded request or a quantity of returned results. Explain what happens when the search returns no matches. For variable work, define a maximum before starting rather than surprising the buyer with an unbounded amount.

The [plans and pricing reference](https://docs.zeroclick.ai/concepts/plans-and-pricing) covers per-call, prepaid, and subscription choices. Start with the mode that fits how the service is consumed. Offering every mode immediately is not a product requirement.

Test your proposed price against expensive but valid requests, not only the easiest example. A low average processing cost can conceal an unprofitable tail. The [API pricing guide](https://zeroclick.ai/resources/price-an-api-for-agents) develops this into a billable unit, spending ceiling, and worked pricing example.

## Separate access from fulfillment

Payment, permission, and fulfillment are separate checks. A paid request must still satisfy your access policy, and your product must deliver the promised result.

For proxied API requests, ZeroClick's [integration contract](https://docs.zeroclick.ai/integrate/overview) covers signed forwarding, allowance checks, and usage settlement. Your backend verifies the forwarded request, checks permission to perform the declared work, executes it, and reports actual usage through the supported integration.

If the purchase instead creates a durable account or API key, use the separate account-provisioning path described in the documentation. Do not describe buying a subscription and buying a single data call as the same implementation.

Keep the fulfillment boundary explicit in customer-facing copy. Buying a product-data search does not purchase the consumer product it returns. Buying an enrichment result does not authorize an outreach campaign.

## Make failure behavior part of the offer

An agent needs to decide whether to fix its input, retry, change the task, or stop.

| Situation | Useful behavior |
|---|---|
| Missing or invalid required input | Explain the field that needs correction |
| Valid request, no matching result | Return a documented empty or unresolved outcome |
| Partially available information | Preserve missing fields and explain the partial result |
| Service temporarily unavailable | Return a failure the buyer can distinguish from "no match" |
| Work would exceed the allowed amount | Stop or request a higher approved bound |
| Buyer repeats a request | Apply and document the intended retry/idempotency behavior |

Write the chosen behavior beside the input/output example, then test that your service follows it.

Do not return a successful-looking response when fulfillment failed. Follow the documented settlement rules rather than independently improvising how failed calls are billed.

## Give the buyer a clear starting point

A service description should answer four questions quickly: what it does, what input it needs, what it returns, and what it costs or consumes.

Use the service documentation for exact schemas and examples. Use guides for procedures that combine several calls or require a destination such as a spreadsheet or CRM. A guide should help someone use the service. It should not be required just to discover the required request field.

The storefront publishes the current catalog and machine-readable access instructions. Keep that commercial description aligned with your API and documentation when changing names, limits, or pricing.

## Check one complete purchase-to-result path

Before expanding the catalog, test the offer as a buyer would:

1. Find the service and identify its intended use.
2. Inspect the request and expected result.
3. Understand the price or allowance and approve the bounded work.
4. Complete the documented access flow.
5. Receive the promised result or a clearly classified failure.
6. Use the output in the next step without guessing what its fields mean.

Retain an empty-result case and a failure case alongside the successful example. This checks whether the offer is usable, not just whether its payment page loads.

A product-search result might next enter an offer-comparison workflow. An enrichment result might become a proposed CRM update. Neither needs to be presented as a whole end-to-end agent product if you sell only the bounded data step.

## Prepare the first service for review

Bring the service sentence, input/output example, chosen billing unit, limits, failure behavior, and current fulfillment endpoint to a [ZeroClick walkthrough](https://zeroclick.ai/get-demo). For implementation, start with the [seller quickstart](https://docs.zeroclick.ai/quickstart).

Expand when another service has a distinct buyer job or commercial contract. Do not split one useful operation into several confusing purchases merely to make the catalog look larger.

## Keep reading

1. [How to price an API for AI agents](https://zeroclick.ai/resources/price-an-api-for-agents)
2. [ZeroClick docs: concepts / stores, services, meters](https://docs.zeroclick.ai/concepts/stores-services-meters)

## More in Packaging and pricing

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

- [What makes a product agent-purchasable?](https://zeroclick.ai/resources/what-makes-a-product-agent-purchasable) — ZeroClick Team, September 15, 2026
- [How to price an API for AI agents](https://zeroclick.ai/resources/price-an-api-for-agents) — ZeroClick Team, September 15, 2026
- [How to choose an integration for selling your API to AI agents](https://zeroclick.ai/resources/choose-a-zeroclick-integration) — ZeroClick Team, September 15, 2026