Flyte API

Keys are issued on request, not self-serve. Ask for one at /request-access. Tell us what you are building; we would rather know.

A key looks like flyte_sk_.... The prefix is there so that if one ever leaks into a repository or a log, whoever finds it can tell what it is.

The key is shown once and never again. We store only a hash, so we could not show it to you a second time even if you asked. Copy it when you get it. If you lose it, revoke it and take another.

Ten keys per account. Use a separate key per environment so you can revoke one without breaking the others. Once you are signed in you can list and revoke your own keys by their last four characters; revocation takes effect within a minute.

Send the key in an x-api-key header. HTTPS only; plain HTTP is redirected.

curl https://api.flyteai.io/api/environment \
  -H "x-api-key: flyte_sk_your_key_here"

Authorization: ApiKey flyte_sk_... works too, if your HTTP client insists on putting credentials there.

GET /api/health is the only endpoint that answers without a credential.

One endpoint, natural language. No date formats to get wrong and no airport codes to look up: “next Friday” and “Chicago” both work.

curl -X POST https://api.flyteai.io/api/process \
  -H "x-api-key: flyte_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "ORD to JFK on December 15th",
    "conversation_id": "your-own-id",
    "sender_id": "your-app"
  }'

conversation_id is yours to choose and is how multi-turn context is kept. Reuse it to refine a search (“make it business class”); use a new one to start over. Ids are not namespaced per key, so prefix yours with something of your own.

The response has four fields. response is prose written for a human to read, slot_summary is what the agent currently understands about the trip, and metadata.flightOffer is the same flight as structured data.

{
  "response": "... Flight Found! ... Total: USD 132.70 ...",
  "slot_summary": "From: ORD\nTo: JFK\nDeparture: December 15th, 2026\n...",
  "status": "success",
  "metadata": {
    "flightOffer": {
      "legs": [
        {
          "from": "ORD",
          "to": "JFK",
          "departAt": "2026-12-15T13:35:00",
          "arriveAt": "2026-12-15T17:05:00",
          "stops": 0,
          "via": [],
          "durationMinutes": 210,
          "segments": [
            {
              "from": "ORD",
              "to": "JFK",
              "departAt": "2026-12-15T13:35:00",
              "arriveAt": "2026-12-15T17:05:00",
              "carrier": "DL",
              "carrierName": "Delta Air Lines",
              "flightNumber": "5035",
              "cabin": "Y",
              "durationMinutes": 210
            }
          ]
        }
      ],
      "tripType": "one-way",
      "validatingCarrier": "DL",
      "validatingCarrierName": "Delta Air Lines",
      "price": {
        "total": 132.7,
        "currency": "USD",
        "baseFare": 108.7,
        "taxes": 24.0
      },
      "fareType": "Private",
      "refundable": false,
      "baggage": { "checked": null, "carryOn": null },
      "resultsCount": 8
    }
  }
}

Read metadata.flightOffer, not the prose. The wording of response has changed several times and will change again. metadata is null on turns that do not put a flight in front of you, such as a clarifying question.

A search is a live lookup and can take 30 to 120 seconds. Set your timeouts generously. If you would rather show progress than a spinner, POST /api/process/stream takes the same body and answers with newline-delimited JSON: a stage line as each step begins, a ping every 15 seconds of silence, then exactly one result or error line.

{"type":"stage","stage":"searching","origin":"ORD","destination":"JFK"}
{"type":"ping"}
{"type":"stage","stage":"found","count":8}
{"type":"result","slot_summary":"...","response":"...","metadata":{...}}

Flyte speaks MCP, so an AI assistant can search flights as a tool call. JSON-RPC 2.0 over HTTP POST, protocol revision 2025-06-18.

{
  "mcpServers": {
    "flyte": {
      "url": "https://api.flyteai.io/mcp",
      "headers": {
        "x-api-key": "flyte_sk_your_key_here",
        "Authorization": "Bearer flyte_sk_your_key_here"
      }
    }
  }
}

The server implements initialize, tools/list and tools/call, and advertises tools only: no resources, no prompts. There is exactly one tool.

{
  "name": "search_flights",
  "description": "Search live flight inventory using plain language...",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "The travel request in plain language, e.g. 'ORD to JFK on December 15th'."
      },
      "conversation_id": {
        "type": "string",
        "description": "Optional. Reuse the same id across calls to refine a search."
      }
    },
    "required": ["query"]
  }
}

A call, and what comes back:

curl -X POST https://api.flyteai.io/mcp \
  -H "x-api-key: flyte_sk_your_key_here" \
  -H "Authorization: Bearer flyte_sk_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "search_flights",
      "arguments": {
        "query": "ORD to JFK on December 15th",
        "conversation_id": "my-agent-session-1"
      }
    }
  }'

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Flight Found!\n\nOUTBOUND - Tue, Dec 15, 2026\nORD to JFK\nDelta Air Lines DL 5035\n1:35 PM ORD - 5:05 PM JFK\n3h 30m - Direct\n\nCabin: Economy (Y class)\nRefundable: No\nBase Fare: USD 108.70\nTaxes & Fees: USD 24.00\nTotal: USD 132.70\n\n8 flights available - Showing best price"
      }
    ],
    "isError": false
  }
}

Two things to plan for. The tool returns text, not structured fields. If your agent needs a decimal price or a carrier code to work with, call the REST endpoint and read metadata.flightOffer instead. And the text may go on to ask for passenger details, because the same assistant powers the chat product on flyteai.io; over MCP there is nothing to send them to. Worth a line in your system prompt telling the model not to collect them.

Omitting conversation_id makes every call from your key share a single conversation. Pass your own id for anything concurrent.

When a search fails you get a normal successful result with isError: true and an explanation in the text, rather than a JSON-RPC error. The call worked; the search did not, and a model can read the difference.

When a conversation reaches payment, the response metadata has content_type: "payment_request". With the rail on it also carries paymentRails: ["base", "solana"] and a solana block. The amount is fixed by the server when the request opens. Send exactly amountAtomic of mint to escrowTokenAccount, signed by the traveller's own wallet.

"solana": {
  "network": "solana",
  "mint": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
  "escrowAddress": "<escrow owner>",
  "escrowTokenAccount": "<escrow USDC token account>",
  "amount": "412.60",
  "amountAtomic": 412600000,
  "decimals": 6,
  "claimEndpoint": "/api/payment-success/solana/start"
}

Once the transfer is sent, claim it. The traveller must be signed in: send their Flyte session as the bearer token and the identity token from their wallet sign-in in the body. The Solana wallet must be linked to the same account as the wallet that started the conversation.

curl -X POST https://api.flyteai.io/api/payment-success/solana/start \
  -H "x-api-key: flyte_sk_your_key_here" \
  -H "Authorization: Bearer <flyte session>" \
  -H "Content-Type: application/json" \
  -d '{"conversation_id": "conv-123",
       "signature": "<base58 transaction signature>",
       "payer": "<traveller's Solana address>",
       "identity_token": "<sign-in identity token>"}'

# 202 {"status": "pending", "payment_reference": "sol_..."}

Then poll GET /api/payment-status with conversation_id and tx_hash=<payment_reference> until the status is not pending. Only booked means a ticket. A payment is checked only once the transaction is finalized, which takes around 15 seconds. A wrong token, the wrong recipient or a transfer from another wallet is not a payment. A wrong amount is refunded to the wallet it came from. If the trip was already paid on any rail, the second payment is refunded.

400 malformed signature or address, 401 identity token not valid, 403 wallet not linked to this account or a different Solana wallet is already paying, 409 no payment requested or this signature was already used. Every refusal happens before the signature is claimed, so it can be presented again once fixed.

POST /api/process and POST /api/process/stream allow 30 requests per minute. POST /api/reset-conversation allows 10. Every limited response carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset; read them rather than guessing.

Limits are counted per IP address, not per key. If you are behind a shared egress address you are sharing a budget with whoever else is there.

POST /mcp is not rate limited today. Please do not treat that as an invitation: every call is a live inventory search, and an agent in a retry loop is the thing most likely to get a key revoked.

• 401: key missing, malformed, revoked or expired. On MCP, also a missing bearer token
• 422: the request body did not validate
• 429: rate limited. Back off; do not loop
• 500: the search failed. Usually transient; retry once, then stop

Over MCP, protocol mistakes come back inside a 200 as JSON-RPC errors: -32700 for unparseable JSON, -32600 if jsonrpc is not "2.0", -32601 for an unknown method, and -32602 for an unknown tool name or a missing query.

• Booking is not available through the API or MCP. Search returns real, live fares; nothing here issues a ticket or moves money.
• Adult passengers only. Our certification with the inventory provider covers the adult passenger type. Search will not warn you about a trip involving children. The check happens later, in the booking flow on flyteai.io, which refuses it.
• Fares move. A result is a quote at a moment, not a held price. Re-search rather than caching results, and never show a stored price as though it were still live.
• Baggage allowances are often absent. The baggage fields come back null more often than not. Do not present them as authoritative.