> ## Documentation Index
> Fetch the complete documentation index at: https://docs.farelint.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Technical evaluation

> Coverage, data fields, integration requirements and commercial scope.

Use this guide to assess Farelint for your application, starting with a defined airline and route.

## Start with the API

* [Recorded API response](https://docs.farelint.com/actual-response.md): four Ryanair OPO → STN options for two adults, with the original observation timestamp.
* [Quickstart](https://docs.farelint.com/quickstart.md), [authentication](https://docs.farelint.com/authentication.md) and [OpenAPI schema](https://farelint.com/openapi.json): request and response contracts.
* [Airline capabilities](https://docs.farelint.com/airlines.md): supported airport pairs, journey types, passenger counts, languages and currencies.
* [Jobs](https://docs.farelint.com/jobs.md), [webhooks](https://docs.farelint.com/webhooks.md) and [errors](https://docs.farelint.com/errors.md): request lifecycle and delivery handling.

## Coverage and data fields

Coverage is defined by the enabled request contexts on the [airlines page](https://docs.farelint.com/airlines.md), rather than every route operated by an airline. Check `GET /v1/airlines` for current capabilities and costs before integrating.

Responses include the request context, observation time, source reference, itinerary details, price basis and explicit unknown fields. Shortlists are bounded and are not exhaustive inventory. Farelint supplies fare observations; booking and ticket issuance are outside the current API.

## Freshness and history

Searches collect on demand. `observed_at` records collection time; `source_priced_at` is present only when known. A recent observation does not guarantee that the airline generated a new price at that instant. Check the result's timestamp and completeness before display.

Historical market datasets, seasonality indices and a managed recurring refresh service are not currently offered. See [historical data](https://docs.farelint.com/history.md), [monitoring](https://docs.farelint.com/monitoring.md) and [data quality](https://docs.farelint.com/data-quality.md).

## Integration and delivery

Use a server-side bearer key and a unique idempotency key for each intended search. Submit asynchronously, then poll the durable job or receive a signed completion webhook. Handle `completed`, `partial` and `failed` explicitly. Failed and partial jobs release their reserved credits.

Webhook delivery is at least once. Verify the signature, deduplicate event IDs and acknowledge promptly. Follow the [webhook guide](https://docs.farelint.com/webhooks.md) for registration, retries and delivery history. Evaluate latency and completion for your intended workload; any service-level requirements should be agreed for that scope.

## Commercial scope

[Monthly plans and airline rates](https://docs.farelint.com/credits.md) define API usage charges and request limits. Source weights vary by airline; synchronous delivery adds two credits. Plan concurrency limits are upper bounds, subject to service capacity and source availability.

Confirm intended storage, display, downstream use and redistribution in your commercial agreement. API usage pricing does not by itself establish a blanket data-redistribution license.

## Evaluation checklist

1. Choose a supported airline/route, travel dates, passenger context and currency.
2. Confirm required fields, price basis, timestamps and treatment of unknown values.
3. Repeat the agreed requests and measure completeness, freshness and latency for that workload.
4. Verify idempotency, failure handling and webhook delivery into your application.
5. Agree volume, commercial data use and any service requirements before expanding scope.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.