Cycle API
CycleStatusChangelog
  • Cycle API
  • Introduction
    • About Cycle
    • Data model
  • The graphql API
    • How to start
    • Authentication
    • Node interface
    • Pagination
    • Webhooks
    • Limitations
    • Graphql Schema
    • Examples
  • Company
    • Company Attribute
    • List Company attributes by product
    • Create a company
    • Update a company attribute value
  • Practical use case: the feedback form
    • Create a feedback
    • Advanced: use your properties
Powered by GitBook
On this page
  • Rate limitation
  • Complexity limitation
  1. The graphql API

Limitations

We use rate-limit and complexity-limit to avoid a single person using too many api ressources.

PreviousWebhooksNextCompany Attribute

Last updated 1 year ago

Rate limitation

We use the algorithm. The leaky bucket algorithm makes use of a queue that accepts and processes requests in a first-in, first-out (FIFO) manner. As requests get queued up, they are processed at a constant rate. This means that even when the server is hit with a burst of traffic, the outgoing responses are still sent out at the same rate. Once the queue is filled up, the server will drop any more incoming requests until space is freed up for more.

To keep track of the remaining amount, we sent back 4 HTTP response headers for each request:

Header
Description

Ratelimit-Limit

The maximum number of API requests you're permitted to make per hour.

Ratelimit-Policy

The number of requests allowed for a given number of seconds.

Ratelimit-Remaining

The number of API requests remaining in the current rate limit window.

Ratelimit-Reset

The time before the rate limit window resets in .

You can make up to 2000 requests per hour. The limitation is IP based but we may change it to user based in the future.

Complexity limitation

Work in progress...

leaky bucket
UTC epoch seconds