Skip to main content

Claims & Payouts

Flight Protection claims are automatic. When a covered disruption qualifies, Sitata creates the claim, sets the payout to the product's fixed amount, and moves it straight to the point where it only needs the customer's payout details. There is no assessment step and no claim form for the common cases.

The Automatic Claim Lifecycle

  1. A covered disruption is detected and passes the coverage checks.
  2. Sitata creates the claim automatically, already accepted, with the payout amount set, and places it in pending_bank_info status — it is waiting only for the customer's bank/payout details. A flight_protect.claim_created webhook (1009) is delivered.
  3. The customer supplies their payout details (see below).
  4. The payout is issued, the claim moves to payment_issued, and a flight_protect.claim_payment_issued webhook (1010) is delivered.

Each claim links to everything you need: the subscription_id (the policy), the air_segment_id and trip_id (the specific flight), and a human_id — the human-friendly reference to show your customer and to load the claim in a UI.

info

There is no PNR / booking-locator field on Sitata's side. Bridge a claim back to your own records using the external_id you set on the trip (and traveller), which is echoed in every webhook payload.

Collecting Payout Details From Your Customer

A claim in pending_bank_info needs the customer to provide where the payout should go. You have two options.

Option A — Sitata's hosted claim page

The flight_protect.claim_created (1009) webhook includes a claim_info_url — a Sitata-hosted, whitelabel-branded page (keyed by the claim's human_id and the traveller's language) where your customer can review the claim and submit their bank/payout details. The simplest integration is to relay this link to your customer.

Option B — Embed the Claims Widget in your portal

For a fully in-portal experience, embed the Claims Widget directly in your own site. It gives your customer the complete claims experience — a list of their claims, status tracking, live support chat, and the bank/payout-details form (powered by Wise) that satisfies the pending_bank_info step — all under your branding.

Because the widget scopes to the customer's subscription (policy), you can deep-link straight to the right place:

  • Pre-authenticate the customer with a userToken so they skip the login step.
  • Pass a subscriptionId to start/open the claim under a specific policy, or a claimId to open a specific existing claim.
<div id="claims-app"></div>
<script>
  window.document.addEventListener("sitata:claimsReady", function () {
    var el = document.getElementById("claims-app");
    var widget = new window.Sitata.claims(el, {
      orgId: "YOUR_ORG_ID",
      token: "YOUR_PUBLIC_TOKEN",
      isB2B: true,
      userToken: "THIS_CUSTOMERS_TOKEN",
      subscriptionId: "THE_FLIGHT_PROTECT_SUBSCRIPTION_ID"
    });
    widget.run();
  });
</script>
<script async src="https://www.sitata.com/widgets/claims.js"></script>

See the Claims Widget guide for the full embed, configuration, and deep-linking reference.

tip

Whichever option you choose, subscribe to the claim webhooks (1009, 1010, and the 600–607 claim-status events) so your systems always reflect the true state of a payout — including the 604 "claim paid" event.