Understand FieldCamp API rate limits, the 60 RPM sliding window, throttling headers, and how to handle 429 errors in production integrations.

The FieldCamp API rate limits keep every workspace fast and predictable by capping how many requests each API key can make per minute. We use a sliding window throttle and surface the current state on every response so your integration can pace itself without guesswork. This guide covers the hard cap, the response headers, the 429 retry pattern, and the design choices that keep field service integrations healthy at scale.

If you are still wiring up your first request, work through the API quickstart and the authentication guide first, then come back to tune for throughput.

The default FieldCamp API rate limit

FieldCamp enforces a default limit of 60 requests per minute per API key using a sliding window counter. Unlike a fixed-window quota that resets on the minute, a sliding window evaluates the trailing 60 seconds on every call, so you cannot stack bursts on either side of the clock boundary. The limit is evaluated before any business logic runs, so a throttled call never partially mutates your data.

Limits apply to the API key, not the workspace. If your business runs multiple integrations against the same FieldCamp account — a nightly accounting sync, a customer portal, and an internal dashboard, for example — issue each one its own API key so a noisy script in one workload cannot starve the others. Webhook deliveries from FieldCamp to your server (see the webhook events catalog) and interactive dashboard sessions are tracked separately and do not consume your API budget. For the full request lifecycle see the API overview.

The 60 RPM ceiling applies to authenticated REST calls. Validation failures (4xx) still count against the window because they reach the limiter; only requests rejected by the limiter itself (429) are free.

Rate limit response headers you should read

Every FieldCamp API response — successful or throttled — carries throttling metadata in the HTTP headers. Reading these is the cheapest way to stay polite without hard-coding sleep timers in your client.

Header	Meaning
`X-RateLimit-Limit`	The ceiling for the current key, currently `60` requests per minute.
`X-RateLimit-Remaining`	How many requests you can still make inside the trailing 60-second window.
`X-RateLimit-Reset`	Seconds until your oldest counted request ages out and capacity returns.
`Retry-After`	Only sent on 429 responses. Seconds to wait before retrying.

Log X-RateLimit-Remaining alongside your request ID for every call. When something breaks at 3 a.m., the first question is "were we throttled?" and these headers answer it before you open a support ticket.

What a 429 Too Many Requests response looks like

When the sliding window shows more than 60 requests in the last 60 seconds, the API returns HTTP 429 Too Many Requests. The body follows the same envelope as other API errors, so any error parsing layer you already wrote will pick it up.

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 14
Retry-After: 14

{
  "error": {
    "code": "rate_limit_exceeded",
    "message": "API rate limit exceeded. Retry after 14 seconds.",
    "retry_after": 14,
    "request_id": "req_01HZX..."
  }
}

The request is not queued, partially processed, or charged against your daily budget. You must retry it yourself after waiting at least the Retry-After interval.

Handling 429 errors with backoff and jitter

The right way to recover from a 429 is to back off, not to retry tighter. Combine the headers with an exponential strategy so a single throttled minute does not snowball into a thundering herd when the window opens.

Inspect the response headers

Parse Retry-After first, then fall back to X-RateLimit-Reset if the header is missing. Treat both as integer seconds and never retry sooner than the value tells you to.

Add jitter

Sleep for Retry-After seconds plus a random 50 to 250 ms of jitter. Jitter avoids synchronized retries from multiple workers hammering the API at the exact same instant.

Retry idempotent requests safely

GETs are always safe to retry. For POSTs, PATCHes, and DELETEs, attach an idempotency key so duplicate retries do not create duplicate jobs, invoices, or clients.

Escalate after repeated failures

If you see three consecutive 429s, pause the worker, alert your team, and audit the script. Repeated throttling is usually an N+1 loop or a missing pagination cursor, not a sign that you need a higher limit.

Never retry a 429 immediately. Tight retry loops keep the sliding window saturated and prolong the throttle, which is the single most common reason an integration spirals from a 1-minute blip into an hour-long outage.

Design integrations that stay under the limit

A handful of patterns will keep nearly any FieldCamp integration comfortably below 60 requests per minute, even for workspaces with thousands of jobs and visits.

Batch your reads. Use list endpoints with pagination instead of looping single-record GETs. The jobs resource and the clients resource both support filtering and limit parameters that let you pull up to 100 records in a single call.
Cache slowly changing data. Tax rates from the taxes resource, users from the users resource, team rosters, and the company profile rarely change during a shift. Cache them locally for 5 to 15 minutes.
Use webhooks for change notifications. Instead of polling a job every 30 seconds for status, subscribe to webhooks so FieldCamp pushes the change to you the instant it happens. This is the single biggest lever for reducing API call volume.
Coalesce updates. If your dispatch board changes three fields on the same visit in a short period, debounce the writes and send one PATCH to the visits resource instead of three.
Separate read and write keys. A dedicated key for reporting workloads prevents a runaway analytics query from blocking dispatcher writes from another part of your stack.

Monitor remaining capacity proactively

Treat X-RateLimit-Remaining as a live gauge, not just a debugging breadcrumb. Log it on every request, emit it as a metric to your observability stack, and set an alert when the rolling minimum drops below 10. That is the early signal that some job is misbehaving — long before customers feel the impact.

For long-running scripts, check the header in code and sleep proactively when the remaining count falls below a safety threshold (5 is a reasonable default). A two-second pause is cheaper than absorbing a 429 round trip plus the inevitable retry, and it keeps headroom for any critical write that arrives mid-loop.

Requesting a higher rate limit

The default 60 RPM fits the vast majority of integrations. If you are building a one-time migration, a bulk import, or a high-volume reporting pipeline and you have already applied caching plus webhooks, contact FieldCamp support with your use case, the API key you want raised, and the peak QPS you expect. We approve temporary lifts for migrations and permanent lifts for production integrations on a case-by-case basis. While you wait for an answer, point your migration at off-peak hours and chunk the workload into 50-request bursts followed by a 60-second pause.

When the cap is adjusted globally, the change is announced in the API changelog with at least 30 days of notice for any reduction.

Test your retry logic before you ship

Before promoting an integration to production, intentionally trip the limit in a sandbox to confirm your client handles 429 correctly. The safest way is to spam a cheap GET against /v1/company-info in a tight loop and watch the code path. Verify that:

Your code reads Retry-After from the response rather than a hard-coded constant.
Your queue does not duplicate the request when it eventually succeeds.
Logs include the request ID so you can correlate the throttled call with the eventual success.
Webhook handlers continue to process inbound events while the outbound retry is sleeping.

FieldCamp API Rate Limits and Throttling Headers