Rate Limiting Strategies for FileMaker API Integrations
BeginnerImplement client-side rate limiting, backoff on 429 responses, and server-side throttling to keep FileMaker integrations within safe operational limits.
What you'll learn
- How to implement a token bucket rate limiter for FM API calls
- How to handle rate limit errors (if a gateway enforces them) with backoff
- How to limit concurrent in-flight requests to FM
- How to prioritize requests when the rate limit is reached
FileMaker Server does not expose explicit rate limits in the Data API, but it has practical limits: concurrent session counts, database connection overhead, and CPU for find operations. Clients that hammer the API degrade performance for all users and can trigger connection exhaustion. A client-side token bucket and server-side session pool prevent this.
1/4
1
Token bucket rate limiter
A token bucket allows bursts up to the bucket capacity, then limits to refill rate. This lets occasional peaks through while preventing sustained overload.
FileMaker Script
class TokenBucket {
private tokens: number;
private lastRefill: number;
constructor(
private readonly capacity: number, // max burst
private readonly refillPerSec: number // steady-state rate
) {
this.tokens = capacity;
this.lastRefill = Date.now();
}
tryConsume(): boolean {
const now = Date.now();
const elapsed = (now - this.lastRefill) / 1000;
this.tokens = Math.min(this.capacity, this.tokens + elapsed * this.refillPerSec);
this.lastRefill = now;
if (this.tokens >= 1) { this.tokens--; return true; }
return false;
}
}
const fmBucket = new TokenBucket(10, 2); // burst 10, 2 req/sec steady stateError Handling Patterns for FileMaker API IntegrationsSecurity Hardening for FileMaker API Integrations
Sign in to track your progress and pick up where you left off.
Sign in to FM Dojo