Notifications & Webhooks

The entire Flight Protection lifecycle is delivered to your servers through Sitata's webhook system. Webhook event types share the same integer values as Sitata's Notification Types, so once you understand one you understand the other.

Create A Webhook

Register a webhook endpoint and subscribe to the Flight Protection events (and, typically, the claim events):

POST /api/v2/org/:company_id/webhook_endpoints

{
  "webhook_endpoint": {
    "enabled": true,
    "url": "https://www.your-company.co/webhooks/sitata",
    "enabled_events": [1000, 1001, 1009, 1010, 1012, 1013, 1014, 1015, 1020, 1021, 604]
  }
}

Leaving enabled_events empty or null subscribes to all supported events. See the full Webhook Event Types list for everything available.

Verify the signature

Every delivery includes a Sitata-Signature: t=<timestamp>,v1=<signature> header. The signature is an HMAC-SHA256 of the string "<timestamp>.<raw request body>", keyed by the endpoint's signing_secret. Recompute it and compare before trusting a payload. The body itself is { "event": <Integer>, "payload": { ... } }.

Flight Protection Event Types

These events cover the Flight Protection lifecycle. The full authoritative list, including payload details, lives in the API reference.

Event	Name	Fires when
1000	Trip Registered	A trip's flights are registered and coverage is bound (a certificate is issued).
1001	Trip Limit Reached	The subscription's annual trip allowance is exhausted.
1002	Flight Delayed	A covered flight is delayed.
1003	Flight Cancelled	A covered flight is cancelled.
1004	Flight Diverted	A covered flight is diverted.
1005	Missed Connection	A covered connection is missed.
1006 / 1007	Baggage Delayed / Lost	A covered baggage disruption occurs.
1008	Lounge Access Available	The customer qualifies for lounge access.
1009	Claim Created	A payout claim is created automatically for a disruption.
1010	Claim Payment Issued	A claim payout is issued to the customer.
1011	Certificate Issued	The warranty certificate for a registration is issued.
1012	Claim Blocked	An automatic claim was blocked.
1013	Registration Blocked	A trip registration was blocked.
1014	Subscription Deactivated	A Flight Protection subscription was deactivated.
1015	Policy Voided	A Flight Protection policy was voided.
1016	Pre-existing Disruption	A disruption already existed at registration time.
1020	Payout Capped (per-trip)	A payout would exceed the per-trip cap; no claim is created.
1021	Payout Capped (annual)	A payout would exceed the annual cap; no claim is created.

Claim status changes are delivered as claim events 600–607 (submitted, evaluating, accepted, denied, paid 604, reopened, bank-info-requested, withdrawn), with the full claim object in the payload. See Claims.

Every Flight Protection payload carries the identifiers you need to reconcile the event: claim_id, claim_human_id, subscription_id, air_segment_id, and trip_id, plus your own external_ids. For the capped-payout events (1020/1021) no claim exists, so reconcile by (trip_id, air_segment_id, trigger_event) for a per-trip cap or (subscription_id, trigger_event) for the annual cap.

info

Traveller-facing vs. partner-facing. Most 10xx events are webhook-only — they exist to keep your systems in sync. A subset (1002, 1003, 1004, 1005, 1008, 1010) also generate a customer-facing notification (email / SMS / push) that Sitata would normally deliver to the traveller directly.

Whitelabel: Relaying To Your Customers

If your organization holds the Whitelabel package configuration, Sitata does not deliver those customer-facing messages to your travellers directly. Instead, for every notification that would have been sent, Sitata fires an additional notification.suppressed webhook so that you can deliver the message under your own brand.

The suppressed event's event integer is the original notification type (for example 1002 for a flight delay), its event_name is the literal string "notification.suppressed", and its payload contains the full notification (type, title, body, data, created_at) plus a PII-free user object (id, external_id, email, first_name, last_name). Match the external_id back to your own customer record and relay the message however you choose.

So, for a whitelabel partner, a single flight delay produces two webhooks:

1. flight_protect.flight_delayed (1002) — the machine-readable event, with claim/flight identifiers, for your systems.
2. notification.suppressed (event = 1002) — the customer-facing copy (title/body) for you to re-send under your brand.

tip

This is the same relay mechanism used for travel alerts. If you have already set up whitelabel delivery for Travel Alerts or anonymous travellers, Flight Protection events flow through the exact same pipeline — you only need to subscribe to the additional event types.

To learn how the resulting payouts are surfaced to your customers, continue to Claims.