e-copedia hjælpecenter

This guide explains how rate limiting works on the e-conomic REST API, what to expect when you hit a limit, and how to build integrations that handle it gracefully.

Why Rate Limiting Exists

Our goal is to provide a stable, reliable, and performant platform for all integrators and partners. The primary cause of service disruptions is typically not malicious intent, but rather accidental runaway scripts or integration bugs that request large datasets at rapid rates, which can overwhelm our infrastructure. Rate limiting protects the platform for everyone.

How It Works: The Token Bucket Algorithm

Requests are limited using a token bucket algorithm:

• Your application receives a separate token bucket for each agreement it serves, defining its burst capacity (e.g., 2,000 tokens).

• Each bucket is steadily refilled at a fixed rate over time (e.g., 30 tokens per second), which defines the sustained throughput rate.

• Each API request consumes tokens — the number consumed depends on the endpoint (called the "call cost").

• If your bucket runs out of tokens, further requests are rejected with an HTTP 429 Too Many Requests response until the bucket refills.

Call Costs

Not all API requests cost the same number of tokens. Each endpoint has an assigned cost proportional to its system load.
​
Some examples:

Each response includes an X-CallCost header that tells you exactly how many tokens the last request consumed. Monitor this header to understand how quickly your integration is spending its token budget.

Response Headers

The API provides the following headers to help you manage your rate limit budget:

When You Hit the Limit: HTTP 429

If your integration exceeds its token budget, the API returns:

The Retry-After header specifies exactly how long to wait before retrying. Even after hitting a limit, the bucket refills steadily, so requests will start going through again within seconds.

Best Practices for Your Integration

1. Make Requests Sequentially

Ensure your application sends requests one at a time, sequentially, rather than firing multiple requests in parallel. Concurrent requests from the same app can rapidly exhaust your token bucket and make it much harder to predict and manage your remaining budget.

2. Implement Robust Error Handling

Never assume an API call will succeed. Your code should gracefully handle different types of failures, especially:

• Client Errors (4xx): Check for 429 Too Many Requests. This is the specific signal that you have exhausted your token budget.

• Server Errors (5xx): Our servers may still have transient issues.

• Network Timeouts: The request may not reach us at all.

3. Respect Rate Limits with Exponential Backoff

If you receive a 429 Too Many Requests error, do not immediately retry in a tight loop. This will only drain your refilling tokens and contribute to load.

The best practice is to implement exponential backoff — waiting progressively longer intervals before retrying:

1. Receive a 429 error.

2. Wait 1 second, then retry.

3. Still 429? Wait 2 seconds, then retry.

4. Still 429? Wait 4 seconds, then retry.

5. …and so on, up to a maximum wait time.

This strategy is more effective, uses your tokens efficiently, and ensures your integration can gracefully recover from high-load situations.

Summary

Support

If you have any questions, please reach out to the API support for immediate assistance. If you are concerned about being rate-limited, we assure you that we will be monitoring the system to ensure the bucket size is large enough to handle the normal load. As always, if you are in doubt, please contact our API support.