Testing With The Simulation Endpoints
Because Flight Protection payouts are triggered by real-world flight data, Sitata provides two developer endpoints so you can exercise your integration — your webhook receivers, your relay logic, and your claims UI — without waiting for an actual flight to be disrupted.
warning
These are developer utility endpoints, not part of the versioned /api/v2 surface. They are enabled only in Sitata's non-production (development and staging) environments — in production the pages show a "not available" notice and the endpoints are disabled. Point them at your staging integration.
Note that POST /dev_flight_protect/simulate runs the real claim pipeline in that environment: it creates real claims, issues payouts, fires real webhooks, and sends notifications to the traveller on the subscription. Use a dedicated test subscription, and treat the authentication_token you use here as sensitive.
Both endpoints authenticate with an authentication_token parameter that resolves to your company.
1. Simulate A Disruption — POST /dev_flight_protect/simulate
Runs the end-to-end claim-creation pipeline against one of your subscriptions, as though the flight had actually been disrupted.
| Parameter | Required | Description |
|---|---|---|
authentication_token | Yes | Resolves to your company. |
subscription_id | Yes | The Flight Protection subscription to trigger against. Must belong to your company. |
event | Yes | The disruption to simulate: flight_delayed, cancellation, diversion, or missed_connection. |
air_segment_id | No | The specific covered flight segment to trigger. |
include_lounge | No | Set to "true" to also simulate a lounge-access benefit. |
For convenience the simulator bypasses two guards — the "disruption must occur after registration" grace period and the minimum delay threshold — so you do not have to construct a perfectly-timed scenario. All other guards still apply: the subscription must belong to you and be active, the relevant coverage toggle must be enabled, and the one-claim-per-trip-per-event rule is enforced. If a payout would exceed a configured cap, you receive the corresponding payout-capped event (1020/1021) instead of a claim, exactly as in production.
Use this endpoint to verify the full flow: claim creation (1009), the customer-facing message relay, and — because it produces a real claim in pending_bank_info status — your claims / payout collection experience.
2. Simulate Webhook Payloads — POST /dev_notifications
Fires webhook and notification payloads populated with fake data. Nothing is created in the database and no payout is made, so this is the safer choice for wiring up and load-testing your webhook receivers.
| Parameter | Required | Description |
|---|---|---|
authentication_token | Yes | Resolves to your company. |
type | Yes | The (JSON-encoded) event type to emit. |
| (event-specific) | No | Additional parameters for the chosen event. |
It can emit fake versions of every Flight Protection webhook (1000–1021) and every claim event (600–607), letting you confirm that your endpoint parses each payload, verifies the signature, and routes each event correctly — all without touching a real subscription.
tip
A good testing sequence: use /dev_notifications first to shake out payload parsing and signature verification against every event type, then use /dev_flight_protect/simulate against a throwaway test subscription for a true end-to-end run including a real payout and your claims UI.