DOCS · INTEGRATION · PREVIEW

Integration.

A prediction-market platform integrates Aviax in roughly a sprint of webhook plumbing. Two endpoints. One subscription. The platform's existing contract factory and settlement engine do everything else.

Overview

Aviax exposes two surfaces:

REST query. Pull upcoming flight schedules and the contract definitions Aviax will mint. Use this to pre-list markets ahead of departure or to validate the schema before subscribing to events.

Webhook subscribe. Aviax pushes mint, interim-update, and resolution events to a URL the platform owns. The platform's listener acks the event and triggers downstream actions: contract creation, orderbook updates, on-chain settlement.

REST query

Polls return upcoming flights and their planned contracts. Useful for cold-start ingestion or for platforms that prefer scheduled batch syncs over event subscription.

Request (preview)

GET https://api.aviax.io/v0/flights?window=24h®ion=NA
Authorization: Bearer <pilot-token>

200 OK
{
  "flights": [
    {
      "flight_id": "UAL1283-2026-05-07",
      "scheduled_departure": "2026-05-07T14:23:00Z",
      "scheduled_arrival":   "2026-05-07T18:11:00Z",
      "origin": "KJFK",
      "destination": "KLAX",
      "carrier": "UAL",
      "contracts": [
        { "tier": "delayed_15min", "settlement_window_close": "2026-05-07T18:41:00Z" },
        { "tier": "delayed_30min", "settlement_window_close": "2026-05-07T18:41:00Z" },
        { "tier": "delayed_60min", "settlement_window_close": "2026-05-07T18:41:00Z" },
        { "tier": "cancelled",     "settlement_window_close": "2026-05-07T18:41:00Z" },
        { "tier": "diverted",      "settlement_window_close": "2026-05-07T18:41:00Z" }
      ]
    }
  ],
  "next_cursor": "..."
}

Webhook subscribe

mint — fired at scheduled departure. The platform creates the five binary contracts and posts them to the orderbook.

update — fired when a delay threshold has crossed. Optional; some platforms ignore these and resolve only at settlement-window close. Useful for live-pricing platforms.

resolution — fired at settlement-window close. The contract is marked resolved against the deterministic outcome record.

Webhook payload (resolution)

POST <your-url>
Content-Type: application/json
X-Aviax-Signature: ed25519:...

{
  "event": "resolution",
  "flight_id": "UAL1283-2026-05-07",
  "outcomes": {
    "delayed_15min": true,
    "delayed_30min": true,
    "delayed_60min": false,
    "cancelled":     false,
    "diverted":      false
  },
  "settlement_window_close": "2026-05-07T18:41:00Z",
  "signal_attestation": "ed25519:..."
}

Signature verification

Every webhook request carries an X-Aviax-Signature header containing an ed25519 signature over the canonical request body. The platform verifies the signature using Aviax's public key (provided out-of-band at pilot setup) before acting on the event.

Reject any webhook whose signature fails. This guards against tampering between Aviax's signing infrastructure and the platform's settlement engine, and is the platform's primary defense against spoofed settlement signals.

Error modes and retry

Aviax retries failed webhook deliveries with exponential backoff for up to 24 hours. The platform should respond 2xx within 5 seconds; longer responses are treated as failures and retried. Idempotency: every event includes a stable event_id — the platform should dedupe on it.

If a webhook delivery permanently fails, Aviax surfaces it on a status page and via alert email to the pilot's primary contact. Platforms can also poll the REST query endpoint for any flights that should have resolved but didn't.

Authentication

Pilot tokens for the REST endpoint are issued at pilot setup. Tokens are scoped per-platform and per-environment (sandbox / production). Webhook authenticity is cryptographic, not token-based — see signature verification above.

Request pilot access