Webhooks

Receive real-time notifications when bookings change using signed webhook deliveries.

Events

Event	When it fires
`BOOKING_CREATED`	A new booking is created
`BOOKING_UPDATED`	A booking's attendee details are updated
`BOOKING_CANCELLED`	A booking is cancelled
`BOOKING_RESCHEDULED`	A booking is moved to a new time
`BOOKING_COMPLETED`	A booking is marked completed
`BOOKING_NO_SHOW`	A booking is marked no-show
`ASSIGNMENT_CHANGED`	The assigned team member changes

Scopes

Two scopes cover webhook access:

Scope	What it allows
`webhooks:read`	GET webhooks, delivery history, delivery stats — read-only
`webhooks:manage`	All of the above plus create, update, delete, test, rotate-secret

Give monitoring or reporting integrations webhooks:read. Give management tooling webhooks:manage.

Create a webhook

Requires webhooks:manage.

curl -X POST https://api.slatis.com/v1/webhooks \
  -H "Authorization: Bearer sk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://your-app.com/webhooks/slatis",
    "events": ["BOOKING_CREATED", "BOOKING_CANCELLED"],
    "description": "CRM integration"
  }'

The secret field is returned only in this response — it will never be shown again. Store it immediately in a secret manager (e.g. environment variable, Vault, AWS Secrets Manager).

Payload structure

{
  "event": "BOOKING_CREATED",
  "timestamp": "2026-05-01T14:05:00.000Z",
  "webhook_id": "wh_01abc",
  "data": {
    "id": "bkg_01xyz",
    "status": "SCHEDULED",
    "start_time": "2026-05-01T14:00:00.000Z",
    "attendee": { "name": "Jane Smith", "email": "jane@example.com" }
  }
}

Every delivery includes a signature header for verification — see Webhook Signatures.

URL requirements

Webhook URLs must be publicly reachable HTTPS endpoints. The following are rejected:

Private IP ranges (10.x.x.x, 172.16–31.x.x, 192.168.x.x)
Loopback addresses (127.0.0.1, ::1, localhost)
Link-local addresses (169.254.x.x, fe80::/10)
Non-HTTPS schemes

This validation applies to both create and update operations.

Delivery guarantees

Timeout: 5 seconds per attempt
Retries: Up to 5 attempts with exponential backoff — ~1s, 5s, 25s, 125s, 625s
Success: Any 2xx response code
Auto-disable: After 10 consecutive failures, is_active flips to false and the failure_reason is recorded

Re-enable a disabled webhook once your endpoint is healthy:

curl -X PATCH https://api.slatis.com/v1/webhooks/{id} \
  -H "Authorization: Bearer sk_live_xxx" \
  -H "Content-Type: application/json" \
  -d '{ "is_active": true }'

Your endpoint should return 200 quickly and process the payload asynchronously. If your handler takes longer than 5 seconds, Slatis will treat it as a failure and retry. See the CRM integration guide for the recommended pattern.

Test delivery

Send a test BOOKING_CREATED event to verify your endpoint is reachable:

curl -X POST https://api.slatis.com/v1/webhooks/{id}/test \
  -H "Authorization: Bearer sk_live_xxx"

Rate-limited to 1 request per minute per webhook.

Delivery history

Inspect past delivery attempts with status, duration, and error detail:

curl "https://api.slatis.com/v1/webhooks/{id}/deliveries?limit=20&success=false" \
  -H "Authorization: Bearer sk_live_xxx"

Prop	Type	Default
`limit`	`integer`	`20`
`offset`	`integer`	`0`
`success`	`boolean`	-
`event_type`	`string`	-

Rotate the signing secret

Generate a new HMAC secret without deleting and recreating the webhook. The new secret takes effect immediately — existing in-flight deliveries with the old secret will fail signature verification.

curl -X POST https://api.slatis.com/v1/webhooks/{id}/rotate-secret \
  -H "Authorization: Bearer sk_live_xxx"

{
  "success": true,
  "webhook": {
    "id": "wh_01abc",
    "secret": "whsec_new_xxxxxxxxxxxx",
    "rotated_at": "2026-05-01T14:05:00.000Z"
  }
}

Store the new secret immediately. It is shown only once. All deliveries after rotation use the new secret — update your verification logic before rotating.

On this page