Skip to main content

Overview

Webhooks allow your platform to receive real-time notifications when important events happen:
  • User connects their calendar
  • Meeting is scheduled
  • Meeting is rescheduled
  • Meeting is cancelled
  • User updates preferences

Setup

Configure your webhook URL in the platform settings or via API:

Request Body

Webhook Events

Syncline supports 10 webhook event types across 3 categories: User Calendar, Meeting, and Platform events.

Event Payload Structure

All webhook events follow this consistent structure:

User Calendar Events

user.calendar.connected

Fired when a user successfully connects their Google Calendar via OAuth. Multi-Platform Behavior: If the user is connected to multiple platforms (e.g., Boardy, Luma, Cal.com), ALL platforms receive this webhook.

user.calendar.disconnected

Fired when a user revokes calendar access or connection is deleted. Multi-Platform Behavior: ALL platforms that had this user connected receive this webhook.
Disconnect Reasons:
  • user_requested - User explicitly disconnected
  • token_expired - OAuth token could not be refreshed
  • revoked - User revoked access from Google

user.calendar.refresh_failed

Fired when OAuth token refresh fails. This is a critical event that indicates the user must re-authenticate via OAuth before any scheduling operations can proceed for this user.
Action Required: Your agent must prompt the user to re-authorize their calendar. We provide a ready-to-use OAuth URL and suggested messaging to make this easy.
When does this happen? Google OAuth refresh tokens can become invalid for several reasons: Payload:
Handling this webhook in your agent: The oauth_url is pre-built with your platform’s publishable key and the user’s email. You can send this URL directly to your user:
Proactive Token Refresh: Syncline automatically refreshes tokens in the background to prevent expiration. This webhook only fires when automatic refresh fails (typically because the user actively revoked access).

Meeting Events

meeting.scheduling.completed

Fired when an async scheduling job (from /v1/schedule/auto) completes successfully. Use the job_id to correlate with your original API request.

meeting.scheduling.failed

Fired when an async scheduling job fails (no availability, token expired, etc.).
Error Codes:
  • NO_AVAILABILITY - No overlapping free time found
  • CALENDAR_NOT_FOUND - Attendee hasn’t connected calendar
  • TOKEN_EXPIRED - Calendar token needs reauthorization
  • TIMEZONE_ERROR - Could not determine timezone
  • GOOGLE_API_ERROR - Google Calendar API error
  • USAGE_LIMIT_EXCEEDED - Monthly meeting limit reached
  • INTERNAL_ERROR - Unexpected server error

meeting.scheduled

Fired when a meeting is successfully created.

meeting.updated

Fired when a meeting is rescheduled or modified via PUT /v1/meetings/{id}.

meeting.cancelled

Fired when a meeting is cancelled via DELETE /v1/meetings/{id}.

Platform Events

platform.usage_warning

Fired when your platform reaches 80% of monthly usage quota.

platform.usage_limit_reached

Fired when your platform hits 100% of monthly usage quota.

Security

Webhook Signatures

Every webhook includes these headers for verification:
The signature is computed as HMAC-SHA256(timestamp:payload, secret) where:
  • timestamp is the Unix timestamp from X-Syncline-Timestamp header
  • payload is the raw request body
  • secret is your webhook secret
IMPORTANT: The webhook secret is shown ONLY ONCE in your developer dashboard when you configure webhooks. Store it securely - never commit it to your code repository.

Getting Your Webhook Secret

  1. Log in to your developer dashboard
  2. Go to Settings → Webhooks
  3. When you create/update your webhook URL, a secret is generated
  4. Copy and store this secret immediately - it won’t be shown again
  5. Store it as an environment variable (e.g., SYNCLINE_WEBHOOK_SECRET)

Verifying Webhooks - Node.js

Verifying Webhooks - Go

Verifying Webhooks - Python

Security Best Practices

Never commit your webhook secret to version control! Always use environment variables or a secrets manager.

1. Use Environment Variables

2. Validate Before Processing

3. Use HTTPS Only

Configure your webhook URL to use HTTPS, never HTTP:

4. Rate Limiting

Implement rate limiting to prevent abuse:

5. Secret Rotation

Rotate your webhook secret periodically:
  1. Go to dashboard → Settings → Webhooks
  2. Click “Regenerate Secret”
  3. Update your environment variable with the new secret
  4. Old secret remains valid for 24 hours (zero-downtime rotation)

Why This Is Safe

The verification code shown above is meant to be public. This is the same pattern used by:
  • Stripe webhooks
  • GitHub webhooks
  • Twilio webhooks
  • Every major API platform
Security comes from:
  • The secret (kept private in your environment)
  • HTTPS encryption (webhook payloads are encrypted in transit)
  • Signature verification (proves webhook came from Syncline)
What attackers CAN’T do:
  • Generate valid signatures without your secret
  • Intercept webhooks (HTTPS encryption)
  • Replay old webhooks (timestamp validation)

Webhook Management

Test Webhook

Send a test event to verify your webhook is working:
Response:

View Webhook Logs

See recent webhook deliveries and their status:
Response:

Retry Policy

If your webhook endpoint fails:
  1. Immediate retry after 1 second
  2. Second retry after 10 seconds
  3. Third retry after 60 seconds
After 3 failed attempts, the webhook delivery is marked as failed. You can review failed deliveries in the webhook logs.

Best Practices

Respond Quickly

Return a 200 OK response as soon as you receive the webhook. Don’t wait for processing to complete:

Handle Duplicates

Due to retries, you may receive the same webhook multiple times. Use the timestamp and event data to deduplicate:

Monitor Webhook Health

Regularly check webhook logs to ensure deliveries are succeeding. Set up alerts for high failure rates.

Example Integration

Update Webhook Settings

Configure webhook URL and events

View Webhook Logs

Monitor webhook deliveries