Register for a webinar

Let an agent select an upcoming webinar, register an attendee, and return joining instructions. Your event platform owns the registration and confirmation.

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: this example uses required to illustrate a seller that wants a verified agent owner before accepting registrations. Use off or requested instead if that verification serves no purpose for your event.
Seller input: require attendeeEmail for the event invitation. The verified owner can register a colleague in this example; the attendee address is a separate, unverified input.
Fulfillment: create the attendee registration in your event platform and return its confirmation. ZeroClick does not register the attendee for you.

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

Describe the action and endpoints

Add a service such as webinar-registration and describe its outcome and $0 cost. Register your endpoint schemas without meter links, following shared setup. These paths are suggestions for your API:

Suggested endpoint	Purpose
`GET /webinars`	List upcoming events, ids, start times, time zones, and availability.
`POST /webinars/{webinarId}/registrations`	Register an attendee for the selected event.
`POST /webinar-registrations/{registrationId}/cancel`	Optionally cancel an existing registration.

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:

Input	Required in this example	Purpose
`webinarId`	Yes, in path	The event selected from your listing.
`attendeeName`	Yes	The person attending.
`attendeeEmail`	Yes	The invitation address; it may differ from the verified owner.
`company`	No	Context for the event organizer.
`operationId`	Yes	A caller-generated identifier reused for retries.

For example, the request body could be:

{
  "attendeeName": "Jordan Lee",
  "attendeeEmail": "jordan@example.com",
  "company": "Example Co",
  "operationId": "webinar-jordan-001"
}

Validate and fulfill the request

Use the verifyFreeActionRequest helper from shared setup with service slug webinar-registration. 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.After request verification, validate the attendee fields and check that registration is open. The Require policy establishes the agent owner’s verified email; it does not verify attendeeEmail or ensure that the addresses match.Keep the verified owner and attendee address as separate values. This example permits registration for another person. If your event requires self-registration, define and enforce that rule explicitly, including how to handle an address mismatch.Deduplicate by the verified agent id and operationId, then create the registration in your event platform. Return confirmation only after the platform confirms it. If the event is full or closed, return a clear refusal, such as 409 registration_closed.If you offer cancellation, enforce ownership of the registration and make repeated cancellations safe.Return 201 Created with the registration reference and event time. Include a join URL only if your event platform permits sharing it this way. State whether joining instructions are already available or will arrive separately.

{
  "registrationId": "reg_001",
  "status": "confirmed",
  "webinarId": "agent-commerce-intro",
  "startsAt": "2026-10-15T18:00:00.000Z",
  "timeZone": "America/New_York",
  "joiningInstructions": "The event platform will send joining instructions to the attendee email."
}

Return the response without reporting billable usage. Your application supplies the fulfillment logic and error handling; the seller SDK supplies request verification.

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.

curl --request POST "https://acme.pay.zeroclick.io/webinars/agent-commerce-intro/registrations" \
  --header "Authorization: Bearer $AGENT_ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --data-binary @request.json

Run the shared integration checks, then test the cases specific to this action:

Submit a valid attendee email through an unclaimed agent: ZeroClick still rejects the call under Require.
Use an agent claimed with a verified email but omit attendeeEmail: your API rejects the input.
Supply a different attendee address: this reference design allows it; test your own rule if you change that behavior.
Repeat the same operationId: one registration exists and the same reference is returned.
Try a full or closed event: no registration or invitation is created.

Describe the agent's workflow

Find an event that fits the user’s interests and schedule. Follow the storefront’s /auth.md claim instructions when the ZeroClick policy requires verification. Separately collect the attendee details, confirm the user’s intent, register, and report the confirmed time and joining instructions.Publish these instructions with your service and add discovery signals on the relevant website page.

​Example choices

​Build the example

Describe the action and endpoints

Define the seller inputs

Validate and fulfill the request

Test through your pay URL

Describe the agent's workflow

Example choices

Build the example