public-api-docs

Technical considerations

Rate Limiting

We are using AWS Web Application Firewall to protect our platform, against Denial-of-service attacks, by implementing rate limit rules.

The general rate limit is aggregated by Source IP address with a limit of 3,000 requests / 5 minutes. Some endpoints, for example vehicle discovery and sign-in, have lower limits.

Rate-limit response

A request that exceeds a firewall rate limit is answered with:

{
  "errorCode": "RATE_LIMITED",
  "userMessage": "Too many requests. Please try again later.",
  "httpStatus": 429
}

The rate-limit response is returned by the firewall before the request reaches the API, so the body is always the same and contains no traceId.

When you receive it, stop or slow down the requests from that client and retry later with a backoff, waiting at least the Retry-After value. Retrying immediately keeps the rate above the limit and extends the block. See also the Fair use policy.

Some endpoints also answer 429 themselves, with their own error code and without the RATE_LIMITED body, for example AUTH227 on email sign-in. Handle these as the API reference of the endpoint describes.

How the limit is measured

AWS WAF rate limiting is designed to control high request rates and protect your application’s availability in the most efficient and effective way possible. It’s not intended for precise request-rate limiting.

Polling of resources

Most of our first-level entities like:

Health checks

We provide a health check endpoint for our services, which can be used to monitor the health of our services.

It is currently a work in progress to provide a more detailed health check in the future, which will include the health of the database and the health of other subsystems.

Following an example on how the health endpoint can be invoked:

production http { "method": "GET", "url": "/health/ping", "baseUrl": "https://go.api.gourban.services/v1", }