Rate limits

Rate limits

The Partner API v2 applies per-key rate limiting using a sliding window.

How it works

• Limits are partitioned by API key — not by customer. If you hold separate keys for production and BI sync, each gets its own independent budget. (This is why per-environment keys are recommended in Authentication.)

• Limits are also partitioned per product: Bolagsanalys and Fastighetsbenchmark each have their own independent sliding window. Spending your Bolagsanalys budget does not eat into your Fastighetsbenchmark budget, and vice versa — they throttle separately even on the same key.

• Two windows are enforced together (per product):

  • a short per-second window (burst protection), and
  • a longer per-minute window (sustained throughput).

• Both must pass; whichever is tighter for your traffic pattern is the one you feel.

When you're limited

Exceeding a window returns 429 Too Many Requests with an RFC 7807 body (Errors (RFC 7807)) and two signals:

HTTP/1.1 429 Too Many Requests
Retry-After: 2
Content-Type: application/problem+json

{
  "type": "https://httpstatuses.io/429",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "Rate limit exceeded.",
  "extensions": { "rateLimitRemaining": 0, "traceId": "00-..." }
}

• Retry-After (header) — seconds to wait before retrying.
• extensions.rateLimitRemaining — requests left in the current window.

Recommended client behavior

• Honor Retry-After. Sleep for that many seconds, then retry.
• Back off exponentially on repeated 429s (e.g. 1s, 2s, 4s, capped), with a little jitter so parallel workers don't resynchronize.
• Use ?count=false on /comp-data bulk sync to halve the per-request cost (Query conventions), and conditional requests (ETags) to skip unchanged pages (Data freshness).
• Page at a steady rate rather than firing all pages at once.

Concrete limits

Your account is assigned a tier, and each tier carries a per-second and a per-minute ceiling per product. The default ladder is:

Tier	Per second	Per minute
Standard	20	600
HighVolume	60	2000
Enterprise	200	6000

These ceilings apply separately to each product — e.g. on the Standard tier you get 20/600 against Bolagsanalys and an independent 20/600 against Fastighetsbenchmark.

Writes (every method except GET, HEAD and OPTIONS) also count against a separate per-minute write limit of 60 per API key and product, the same on every tier (since 2.3.0). A write can start recalculation of many values, so it is limited harder than a read. Exceeding it gives the same 429 + Retry-After as above. Send many property units in one POST /comp-uploads rather than one request each.

Note: The numbers above are per-environment configuration, not a frozen contract. They are the standing defaults; your Sedis contact confirms (and can raise) the ceilings that apply to your account. The mechanism described above (sliding window, per key, per product, 429 + Retry-After + rateLimitRemaining) is stable regardless of the tier numbers.

Note: Looser limits can be granted at any time without breaking your integration — raising a ceiling is a non-breaking change (see API stability and versioning policy).