ClientLoop
Webhooks

Trigger automations when document requests change.

The moment a request changes, ClientLoop pushes a signed event to your endpoint — in seconds. No polling. Send once; react in real time.

Why webhooks

Polling is slow. Webhooks are instant.

Polling the API for document status wastes calls and leaves your systems a step behind. Webhooks flip it — ClientLoop pushes the update to you.

PollingCall the API every few minutesUsually nothing changedAlways a step behind
WebhooksA request changesEvent fires, signedYour server, in seconds
Example: submission to Slack

From a client's submission to a Slack alert — no polling in between.

Request createdManual or via API
request.createdWebhook fires
Your serverEvent received
Client submitsFiles uploaded
request.submittedWebhook fires
Team notifiedSlack alert sent
Events

What you can do with ClientLoop webhooks

Every meaningful state change in a document request emits an event. Subscribe to the ones your workflow needs.

request.created

Fired when a new document request is created, whether manually or via API.

request.submitted

Fired when a client uploads all requested documents and submits.

request.changes_requested

Fired when an admin marks a submission as needing specific changes.

request.approved

Fired when an admin approves a submission.

request.rejected

Fired when a submission is rejected.

request.completed

Fired when a request workflow is fully closed out.

document.uploaded

Fired when a client uploads a file against a request.

comment.created

Fired when a message is posted on a request thread.

reminder.sent

Fired when an automated reminder is sent to a client.

Payload shape

One JSON body, every time

Here's an illustrative request.submitted payload:

{
  "event": "request.submitted",
  "workspaceId": "ws_1a2b3c",
  "requestId": "req_9f2a",
  "clientId": "client_9f2a",
  "timestamp": "2026-01-15T10:32:00Z",
  "data": { "status": "submitted" }
}

Exact payload fields per event type are confirmed when webhooks are configured for your workspace.

Example flows

Automation flows you can build today

Wire document events straight into the tools your team already uses.

  1. 01request.submitted

    Post a Slack notification to the reviewing team

  2. 02request.approved

    Update the CRM record and mark onboarding complete

  3. 03request.changes_requested

    Email the client with the specific feedback

  4. 04request.submitted

    Create a task in Asana, Notion or Jira for the reviewer

  5. 05request.completed

    Trigger the next step in your onboarding workflow

Example: approval to CRM update

Approve in the dashboard; your CRM updates itself, seconds later.

Admin approvesIn the ClientLoop dashboard
request.approved firesSigned, sent within seconds
Your handler receives POST
CRM record updatedOnboarding marked complete
Reliable delivery

Built for production workflows.

Every attempt is signed, logged and retried — so your systems stay in sync.

  • Delivered within seconds of a status change
  • Signed with HMAC-SHA256 — verify it’s really us
  • Automatic retries with exponential backoff
  • Every attempt logged — retry any failure in one click
Security

Secure by default. Verify every payload.

How delivery works

  • HTTP POST to your endpoint, JSON body
  • Respond 200 to acknowledge; a non-200 or timeout is logged, ready to retry
  • Set your endpoint URL in workspace settings or via the API

Signed & safe

  • Every payload sent over HTTPS
  • HMAC-SHA256 signature on the X-ClientLoop-Signature header
  • Secrets live in your settings, never in the payload
  • Send a one-click test event before you go live
Verify a signature
  1. 1 Read the X-ClientLoop-Signature header.
  2. 2 Compute an HMAC-SHA256 digest of the raw body with your signing secret.
  3. 3 Compare the two with a constant-time check before you trust it.
Who uses this

Built for developers and ops teams

Backend developersOperations engineersn8n usersZapier power usersPlatform teamsCompliance automationCRM integrators
FAQ

Common questions

How do I set up a webhook in ClientLoop?

You configure a webhook endpoint URL in your ClientLoop workspace settings. Once configured, ClientLoop will send a POST request to that URL for each event that occurs in your workspace. Webhook configuration is available on the Pro plan.

What does a webhook payload look like?

Each payload is a JSON object containing the event type, a timestamp, workspace ID, request ID, client details and relevant status information — see the example payload above the FAQ for the general shape. Exact payload fields per event type are confirmed when webhooks are configured for your workspace.

How do I verify that a webhook came from ClientLoop?

Each webhook delivery includes an HMAC-SHA256 signature in the request headers, computed using your webhook secret. You compare the header signature against your own computed hash to confirm authenticity before processing the payload.

What happens if my endpoint is temporarily unavailable?

ClientLoop retries failed webhook deliveries automatically using exponential backoff. If your endpoint remains unavailable for an extended period, we'll notify you. It's good practice to build idempotent webhook handlers so duplicate deliveries don't cause issues.

Can I use webhooks with Zapier or n8n?

Yes. Zapier's "Webhooks by Zapier" trigger can receive ClientLoop webhook events. n8n's webhook node can also receive them. Both let you connect document workflow events to other tools without writing custom server code.

Stop polling. Start reacting.

Wire ClientLoop events into your stack and build document workflows that update the moment something changes.