Batch updates vs single record API calls

Question

The current API documentation suggests that all write operations (POST, PATCH, DELETE) must be performed on individual records. However, for large-scale data synchronization scenarios — e.g., updating status on 10,000+ work orders nightly from an external ERP — this presents significant performance concerns.

Specifically, I am seeking clarification on the following:

Does the FieldPulse API expose any batch or bulk endpoints (e.g., /batch , /bulk , or JSON:API-style compound documents) that would allow multiple records to be modified in a single request? 
 If not, what is the recommended architecture for high-volume operations? I.e., should clients implement exponential backoff with jitter per RFC 7234 , or are there higher rate limits available for authenticated integration partners? 
 Are there any idempotency guarantees (e.g., Idempotency-Key headers per RFC 7230 ) to prevent duplicate records in the event of network partition during a long-running batch process?

I have reviewed API Rate Limits and Best Practices, but it does not address the batch semantics question directly. Any guidance on the intended pattern here would be appreciated.

Eli Torres (Staff) · Accepted Answer

Quick clarifications:

Multiple keys: Totally acceptable for legitimate architectural reasons (different services, env separation, etc.). What gets you in trouble is spinning up 50 keys just to blast through a limit — we have detection for that pattern. Your use case sounds legit.

Idempotency tracking: No public tracker yet, unfortunately. I can add you to the early access list for the RFC if you email me directly.

Nested resource modification: Yeah, that's a known inconsistency. Checklist responses updating work_order.modified_at was supposed to ship in 3.2 but got pulled due to perf concerns on large jobs. It's back in 3.4, currently in beta. Workaround is polling the checklist endpoint separately — not ideal, I know.

Eli Torres (Staff) · Answer

Hey Omar — yeah, this is a gap in the docs that we're actively working to address. Short version: no batch endpoints today, but there are some patterns that'll keep you out of trouble.

Right now every write is single-record. For your 10K nightly sync scenario, I'd recommend:

// Rough pattern we see working at scale
const BATCH_SIZE = 100; // concurrent in-flight
const RATE_LIMIT_RPS = 10; // conservative, burst to 20 if needed
const RETRIES = 3;

// implement token bucket + exponential backoff
// expect ~15-20 min for 10K records with this setup

The rate limit is per API key, not per account — so you can shard across multiple keys if you really need to move faster, though honestly I'd push back on whether you need all 10K in one batch. Incremental sync (only changed since last run) usually drops that by 90%+.

Re: idempotency — no Idempotency-Key header yet, but most POSTs return the record ID which you can store and use for PATCH deduplication. For creates specifically, we're looking at adding UUID client generation in Q4; there's an internal ticket you can reference if you need to track it ( ENG-4421 ).

I'll flag this thread when the batch RFC goes public. It's been discussed but not prioritized — your use case helps make that case.

Leo Nakamura · Answer

Workaround we've used: parallelize across multiple API keys as Eli mentioned, but also —

ETag on GET : Store last_modified from list endpoint, only sync records where modified_at > checkpoint 
 Connection pooling : Reuse TCP connections, TLS handshake overhead dominates at this volume 
 429 handling : Backoff header is Retry-After , not exponential by default

See API Rate Limiting Causing Incomplete Data Exports for a failure mode when this isn't handle'd.

No bulk endpoint on public roadmap as of 2025-09.