> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zeroclick.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Capture a lead
> A reference flow for collecting a sales inquiry, saving it to a CRM, and returning next steps.
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](/examples/free-actions) 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](/examples/free-actions#choose-your-email-requirements) 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
Add a service such as `sales-inquiry` and describe its outcome and \$0 cost. Register your endpoint schemas without meter links, following [shared setup](/examples/free-actions). These paths are suggestions for your API:
| Suggested endpoint | Purpose |
| ---------------------------------- | ------------------------------------------------------ |
| `POST /sales/inquiries` | Record an inquiry and return its reference. |
| `GET /sales/inquiries/{inquiryId}` | Optionally let the originating agent check its status. |
These endpoints belong to your upstream API and are called through your pay URL. They are not built-in ZeroClick API operations.
This reference design uses the following inputs. Adapt their names and required status to your product:
| Input | Required in this example | Purpose |
| -------------- | ------------------------ | -------------------------------------------------------------------- |
| `name` | Yes | The contact person's name. |
| `contactEmail` | Yes | Where the sales team should follow up; user-supplied and unverified. |
| `company` | No | Company context, if relevant to qualification. |
| `requirements` | Yes | What the user wants to discuss or buy. |
| `operationId` | Yes | A caller-generated identifier reused when retrying this inquiry. |
For example, the request body could be:
```json theme={null}
{
"name": "Casey Reed",
"contactEmail": "casey@example.com",
"company": "Example Co",
"requirements": "We need a quote for 50 seats and SSO.",
"operationId": "inquiry-casey-001"
}
```
Use the `verifyFreeActionRequest` helper from [shared setup](/examples/free-actions#verify-the-request-and-identify-the-agent) 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.
```json theme={null}
{
"inquiryId": "inq_001",
"status": "received",
"nextStep": "Our sales team will email the contact address within two business days."
}
```
Return the response without reporting billable usage. Your application supplies the fulfillment logic and error handling; the seller SDK supplies request verification.
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.
```sh theme={null}
curl --request POST "https://acme.pay.zeroclick.io/sales/inquiries" \
--header "Authorization: Bearer $AGENT_ACCESS_TOKEN" \
--header "Content-Type: application/json" \
--data-binary @request.json
```
Run the [shared integration checks](/examples/free-actions#test-the-integration), 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.
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](/website/enable-agent-traffic) on the relevant website page.