eLearning.edu.pl API
ENPL

Rate limits and retries

Limits

Each integration client has a token bucket shared by all its credentials and tokens:

  • 20 requests per minute (one token every 3 seconds),
  • bursts up to 30 requests,
  • 5,000 requests per day (UTC day).

Your organisation may have higher limits agreed in its contract; your IT administrator can also set lower limits for a client (for example a test client). The token endpoint (POST /api/v1/oauth/token) has separate limits: 60 requests per minute per address and 10 issued tokens per minute per client.

Headers

Every response to an integration client reports the state of its limit:

Header Meaning
RateLimit-Limit Bucket capacity (burst).
RateLimit-Remaining Requests available right now (including the daily quota).
RateLimit-Reset Seconds until the bucket is full; after the daily quota is used — until midnight UTC.
RateLimit-Policy The policy, e.g. 20;w=60;burst=30, 5000;w=86400.
Retry-After Only on 429: seconds until the first allowed request.

When you get 429

429 RATE_LIMITED means the request was not executed and did not use your quota. Wait Retry-After seconds, then retry. Do not retry in a tight loop — repeated failed authentications (20 per minute) block the source address for 10 minutes (429 TOO_MANY_FAILED_AUTHENTICATIONS).

Retrying safely

  • Retry 429, 502, 503 and 504, and network errors, with exponential backoff and jitter (e.g. 1 s, 2 s, 4 s …, capped at 60 s), honouring Retry-After when present.
  • Do not retry other 4xx errors without changing the request.
  • POST /api/v1/users and POST /api/v1/enrollments reject duplicates with 409, so a retried create after a timeout is safe: treat 409 as "already exists" and look the resource up.
BASE_URL="${BASE_URL:-https://api.elearning.edu.pl}"

# --retry covers 408, 429, 500, 502, 503 and 504 and honours Retry-After; --retry-max-time caps the total wait.
curl --fail-with-body -sS --retry 5 --retry-max-time 120 \
  "$BASE_URL/api/v1/users?limit=1" \
  -H "X-Tenant-Code: $TENANT_CODE" \
  -H "X-API-Key: $API_KEY"

Bulk synchronisation

For an initial load of many thousands of people, spread the calls over time or ask your onboarding contact for a temporarily higher limit. For continuous provisioning from an identity provider, SCIM is usually a better fit.