API Limitations

Rate Limiting

The FlightLogger GraphQL API is available to customers who have access to the FlightLogger API Module. Access to the API is therefore limited to users whose organization has this module enabled.

To ensure stable performance and prevent misuse, the API is subject to rate limiting, which restricts how many API requests can be made within a certain period of time. If an excessive number of requests are made, additional requests may be temporarily blocked.

Rate limiting refers to the process of restricting API requests based on a user’s usage. The FlightLogger GraphQL API uses a relatively lenient rate-limiting policy designed primarily to discourage excessive or abusive use of the API. Under normal and well-designed integrations, you should not experience rate limiting.

If a client exceeds the allowed request rate, the API will respond with an HTTP 429 – Too Many Requests status code. The response will include a JSON payload explaining that the request was denied. Importantly, the response will also contain a Retry-After header, which indicates how many seconds you must wait before making another request.

Please note that rate-limited requests (those returning HTTP 429) also count toward the rate limit. This means that immediately retrying a failed request may cause the client to remain rate limited. Instead, clients should respect the Retry-After header and wait the specified time before making new requests.

While FlightLogger users may create and use multiple API keys simultaneously (see the Getting Started article), rate limiting is based on users, not keys. This means using multiple API keys does not increase the amount of requests that can be made by the user.

Being rate limited incurs no long-term penalty for the rate limited user, within reason.

Complexity & Depth Limitations

In addition to rate limiting, the GraphQL queries sent to the API have a few semantic restrictions placed upon them, namely complexity and depth.

Depth restriction dictates the maximum depth of the GraphQL queries accepted by the API. Depth is the concept of nested layers selected in the types and fields of the GraphQL schema. Every level of nesting constitutes an increase in depth. Example query:

bookings { <- depth 1
  registration { <- depth 2
    pic { <- depth 3
      callSign  <- depth 4, etc...
    }
  }
}

The depth restriction should not be encountered in regular use-cases, but rather, exists to discourage selecting circular dependencies, example:

booking {
  registration {
    booking {
      registration {
        ...
      }
    }    
  }
}

Complexity restriction dictates to total amount of fields a query may select. Each field in the schema has a complexity which, when selected in a query, will count towards to total complexity of a query. If the sum of all the complexities of the fields selected in a query exceed the maximum allowed complexity, the query will be rejected.

Prevention

In the case of both depth and complexity limitations, these can be worked around by preferably re-working/re-thinking the strategy with which the API is used, otherwise by splitting the query up in multiple requests.