Skip to main content
Let an agent submit a sales inquiry on behalf of its user. Your API records the requirements and contact details, then returns a reference the agent can report to the user.
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.
Start with Overview and setup for the shared ZeroClick configuration, email policy, request guard, and testing guidance.

Example choices

  • ZeroClick policy: choose requested if the agent owner’s verified email is useful for attribution but should not block an inquiry.
  • Seller input: require contactEmail because 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.
The two email choices remain independent in every variant. Changing a ZeroClick plan policy does not add, remove, or verify an email field in your endpoint.

Build the example

1

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.
2

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:
3

Validate and fulfill the request

Use the 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.
Return the response without reporting billable usage. Your application supplies the fulfillment logic and error handling; the seller SDK supplies request verification.
4

Test through your pay URL

Use a staging integration. Save the example body as request.json, replace its values and the placeholder pay URL below, and get an agent token through your storefront’s /auth.md recipe.
Run the shared integration checks, then test the cases specific to this action:
  • 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.
5

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.