eResource Scheduler API Rate Limiting Policy

1. Overview

The eResource Scheduler (eRS Cloud) REST API limits how many requests each account can make in a given time window. Limits differ by type of call: reads, searches, writes and reports each have their own budget, with a per-second burst allowance on top of a per-minute ceiling.

Rate limits exist to keep the service fast and available for every customer. They protect against runaway scripts, accidental loops and traffic spikes, and they give integration developers predictable numbers to design against.

This policy applies to the SaaS API at https://app.eresourcescheduler.cloud/rest.

2. Scope and definitions

Limits are counted on every authenticated request to /rest/v1/*, including requests that fail with a 4xx error.

3. Rate limits by endpoint category

Limits are counted per account, across all access tokens and OAuth applications. A request is allowed only if it is within the per-second and per-minute limit of its category, and within the concurrency limits below.

Reading the table. The per-second limit is the burst: for Read, up to 10 GET requests can be sent in the same second. Sending at that speed continuously would use the 200-per-minute allowance in 20 seconds, after which further Read requests wait until the rolling minute frees up.

4. How limits are applied

Each category has two limits that work together: a per-second limit that caps short bursts, and a per-minute limit that caps total volume. A request is accepted only when it is within both, and within the concurrency limits.

In practice, for the Read category:

1. Up to 10 Read requests are accepted in any one second.
2. No more than 200 Read requests are accepted in any rolling minute.
3. Read, Search, Write and Report are counted separately, so heavy reading does not use up your Write allowance.

Other rules:

• Per account. All access tokens and OAuth applications on an account share the same limits. Spreading traffic over several tokens does not increase them.
• OAuth applications. Requests made with a token issued to an OAuth app count against the account that authorised it.
• Failed requests count. Requests returning 400, 401, 403, 404 or 409 use quota, so fix errors rather than retrying them in a loop.
• Requests over the limit. Requests that exceed a limit may be rejected or delayed. Continuing to send requests after exceeding a limit may trigger a temporary block (section 6).
• Concurrency. If 10 requests from your account are already being processed, further requests may be rejected or delayed until one finishes.

5. Best practices for integrations

These practices keep your integration within the limits and resilient to temporary errors.

• Back off and retry. If a request fails with a server error or times out, wait 1, 2, 4, 8 then 16 seconds (plus a random 0–1 second) before retrying, and stop after 5 attempts.
• Pace your requests. Keep each integration under the per-second limit for its category instead of sending large bursts.
• Retry only what is safe. GET requests can be retried freely. Retry POST requests only after checking the record was not created, to avoid duplicates.
• Search instead of scanning. Use filters on the Search endpoints (for example, on dates or tags) to fetch only the records you need rather than listing everything.
• Cache reference data. Resource types, project types, field profiles and calendars change rarely; refresh them once a day, not on every call.
• Spread scheduled jobs. Avoid starting large syncs exactly on the hour, when many integrations run at once.
• Run reports sparingly. Request utilization for the date range you need and store the result; don't poll the Report category.
• Prefer webhooks to polling. Where webhooks cover your use case, they replace repeated GET calls entirely.
• Use one token per integration. Separate tokens make it easier to see which system is using your account's quota.

6. Fair use and enforcement

Term 2.6 of the Terms of Service prohibits excessive API calls, scraping, system probing and attempts to bypass technical limits. Alongside the limits in section 3, eRS Cloud may:

1. temporarily block a token for up to 15 minutes if it keeps sending requests after exceeding its limits;
2. lower limits for a token or account whose traffic degrades the service for other customers;
3. suspend API access for abuse, such as rotating tokens to evade limits, under terms 2.6 and 8.7.

We will contact the account owner by email before or promptly after any action beyond automatic throttling, except where immediate action is needed to protect the service.

Logging and privacy

To enforce these limits we record request metadata such as the token, account, endpoint, time and IP address. This data is used for security, support and abuse prevention, and is handled as described in the Privacy Policy and term 3.3 of the Terms of Service.

7. Changes to this policy and contact

Limits may be adjusted as the platform grows and usage patterns change. We will give at least 7 days' notice by email to account owners before lowering any published limit, in line with term 15 of the Terms of Service. Increases to limits may take effect without notice. In an emergency affecting service stability, temporary limits may be applied immediately.

Related documents

• eRS Cloud REST API documentation
• Terms of Service – eResource Scheduler (SaaS Version)
• Privacy Policy – eResource Scheduler (SaaS Version)