This is a reference example, not a required API design or a drop-in implementation. Adapt the endpoints, fields, responses, and fulfillment steps to your product. Only the linked ZeroClick integration requirements are platform contracts.
Example choices
- ZeroClick policy: choose
requestedif the agent owner’s verified email is useful for attribution but should not block an inquiry. - Seller input: require
contactEmailbecause this example promises a sales follow-up. Your schema enforces that requirement even when ZeroClick has no verified email to share. - Fulfillment: create an inquiry in your CRM or support system. Acknowledging the inquiry does not mean a quote has been prepared.
Build the example
Describe the action and endpoints
Add a service such as
sales-inquiry and describe its outcome and $0 cost. Register your endpoint schemas without meter links, following shared setup. These paths are suggestions for your API:These endpoints belong to your upstream API and are called through your pay URL. They are not built-in ZeroClick API operations.
Define the seller inputs
This reference design uses the following inputs. Adapt their names and required status to your product:
For example, the request body could be:
Validate and fulfill the request
Use the Return the response without reporting billable usage. Your application supplies the fulfillment logic and error handling; the seller SDK supplies request verification.
verifyFreeActionRequest helper from shared setup with service slug sales-inquiry. Return a guard denial immediately, then parse and validate your input. Return 400 for malformed or missing fields before creating any records or sending messages.Validate the required contact details and requirements before writing to your CRM. Save contactEmail as the follow-up address. If ZeroClick supplies zc-buyer-email, store it separately as the verified agent-owner email; do not silently replace the requested contact.Deduplicate by the verified agent id and operationId. Persist the operation key with the inquiry so a repeated submission returns the same record. If your CRM writes asynchronously, return an accepted status with a reference only after you have durably queued the work.For an optional status endpoint, verify the caller and enforce ownership of the inquiry before returning its details.Use 201 Created once the inquiry is saved, or 202 Accepted when it has been durably queued. Promise a response time only if your team can meet it.Test through your pay URL
Use a staging integration. Save the example body as Run the shared integration checks, then test the cases specific to this action:
request.json, replace its values and the placeholder pay URL below, and get an agent token through your storefront’s /auth.md recipe.- Omit
contactEmail: your API rejects the body even with ZeroClick policy Off or Request. - Submit through an unclaimed agent with Request: the inquiry succeeds without a verified buyer email.
- Repeat the same
operationId: the CRM has one inquiry and the response has the same reference. - Simulate a CRM outage: return an error or a durable queued state, never claim the inquiry was saved when it was lost.
Describe the agent's workflow
Ask the user what they need and where sales should respond. Confirm that they want to submit the inquiry, send it once, then report the reference and next step. Adapt this flow for a quote request or a waitlist by changing the fields and fulfillment.Publish these instructions with your service and add discovery signals on the relevant website page.