Skip to content
Driive Help Center home
Driive Help Center home

Webhooks

Webhooks let Driive push real-time notifications to your server whenever something happens — a new lead arrives as a service request, an appointment is confirmed, a customer's details change, an issue lands in your Inbox. Instead of repeatedly checking the API for changes, your system receives an HTTP POST with the event details the moment they occur.

Capturing new leads? New leads arrive as service requests and fire service_request.created — not appointment.created. If you're migrating an existing integration, see the Service request webhook migration guide.


Why use webhooks?

  • Real-time sync — Keep external systems up to date the moment data changes in Driive
  • No polling required — Eliminate the need for scheduled API calls that check for updates
  • Trigger automations — Fire workflows in Zapier, Make, n8n, or your own backend when events happen
  • Reduce API usage — Webhooks push data to you, so you only call the API when you need additional details

Creating a webhook

Webhooks are managed at Setup > Developer > Webhooks (visible to admins).

  1. Navigate to Setup > Developer > Webhooks.
  2. Click New webhook.
  3. Enter a Label — a descriptive name for the webhook (e.g., "CRM Sync", "Slack Notifications", "Zapier Trigger").
  4. Enter the URL — the endpoint on your server that will receive the webhook payloads. It must be a publicly accessible HTTPS URL.
  5. Select the Events you want to subscribe to. Events are grouped by entity — Appointments, Service Requests, Customers, and Issues. For each group you can either check All [group] events (a wildcard subscription like appointment.*) or pick individual events. If you check every individual event in a group, Driive automatically promotes your selection to the wildcard, so you'll also receive any events added to that group in the future.
  6. Click Create webhook.

Copy your signing secret — it's shown once

After creating the webhook, Driive shows a confirmation dialog: "Your webhook has been created. Copy the signing secret below - you won't be able to see it again."

The Signing Secret field is masked by default — use the eye button to reveal it and the copy button to copy it. You'll use this secret to verify that incoming payloads are genuinely from Driive.

Important: The signing secret is displayed only once, at creation. Store it securely (in a password manager or your secrets store). If you lose it, you can generate a new one at any time by rotating the secret via the API — the old secret stops working immediately.


Available events

You can subscribe to any combination of these events:

GroupEventFires when
Appointmentsappointment.createdA new appointment is created
Appointmentsappointment.updatedAn appointment is modified
Appointmentsappointment.confirmedAn appointment is confirmed with a time slot
Appointmentsappointment.cancelledAn appointment is cancelled
Appointmentsappointment.rescheduledAn appointment is rescheduled
Service Requestsservice_request.createdA new service request is created
Service Requestsservice_request.updatedA service request is modified
Customerscustomer.createdA new customer is created
Customerscustomer.updatedA customer's details change
Issuesissue.createdA new issue appears in the Inbox

Each group also has a wildcard subscription — appointment.*, service_request.*, customer.*, and issue.* — that matches every event in the group.

For payload structures, field references, and examples, see Webhook Events and Security.


Managing your webhooks

The Webhooks page lists every webhook in a table:

ColumnDescription
NameThe label you gave the webhook
URLThe destination endpoint
EventsBadges for the subscribed events (hover the +N badge to see the full list)
ActiveA toggle that turns delivery on or off
StatusThe endpoint's delivery health — see below

The Status column tells you at a glance whether deliveries are getting through:

  • Healthy — the most recent delivery succeeded. Hover to see when the webhook was last triggered.
  • Failing — recent deliveries have failed. Click the badge to see the last error message, the number of consecutive failures, and when the last failure happened.
  • Never triggered — the webhook hasn't matched any events yet.

Note: Driive never disables a webhook automatically, even after repeated failures. A failing endpoint keeps receiving new events (and retries) until you fix it or switch its Active toggle off.

Enabling and disabling a webhook

Use the Active toggle in the table to temporarily stop deliveries without deleting the webhook. This is handy during server maintenance or while debugging — flip it back on when you're ready to receive events again.

Editing a webhook

  1. Click the menu at the end of the webhook's row and choose Edit.
  2. Update the label, URL, or subscribed events.
  3. Save your changes.

Changes take effect immediately — the next matching event is delivered to the new URL or event selection. Editing a webhook does not change its signing secret.

Deleting a webhook

  1. Click the menu at the end of the webhook's row and choose Delete.
  2. Confirm in the Delete Webhook? dialog.

Deletion cannot be undone, and the webhook stops receiving events immediately. If you think you might need it again, disable it with the Active toggle instead.


How delivery works

When an event you're subscribed to occurs, Driive sends an HTTP POST to your URL:

  • The body is a JSON envelope — { id, type, previousData, data, createdAt } — signed with your webhook's secret via the X-Webhook-Signature header.
  • Your endpoint has 30 seconds to respond. Any 2xx status code counts as success; anything else (including a timeout) counts as a failure.
  • Failed deliveries are retried automatically — up to 5 retry attempts with exponential backoff — before being given up on.
  • Delivery health is reflected in the Status column on the Webhooks page.

The full details — payload schemas, signature verification code, headers, and retry behavior — are in Webhook Events and Security.


What happens next

Once your webhook is set up and receiving events, you'll want to understand the payloads and how to verify they're authentic: