Data Freshness
For Each endpoint call, Renidly checks a 20-minute cache first — if the answer is already there, you get it for free in under a millisecond. If it isn't, the live fetch runs, the response is returned, and the appropriate credits are deducted.
How a single call resolves
| Outcome | Latency | Cost | When it happens |
|---|---|---|---|
| Cache hit | Sub-millisecond | 0 credits | Same input was looked up by anyone in the last 20 minutes. |
| Cache miss | 1–2 seconds | 1–5 credits (varies by endpoint) | No cache entry, or the previous entry has expired. |
Both outcomes return the exact same response shape— there's no flag in the body telling you which path ran. From your code's perspective every call is identical; the cache is transparent.
The exact per-endpoint cost on a cache miss is in Endpoint Costs — pulled live from our catalog, filtered to documented endpoints, refreshed every hour.
What sits in the cache
The cache is keyed on the full set of inputs for a call — endpoint, path parameters, query string, and request body all participate. Two calls share a cache entry only if every input matches byte-for-byte.
Cache entries are not per-workspace: if any account looked up the same input in the last 20 minutes, your call benefits from that hit. This is why early traffic sometimes feels billable and later traffic feels free — popular records tend to stay warm.
Maximising cache hits
Failed lookups are always free, but live lookups are not — and most workloads have natural duplication that can be steered into the cache window. A few patterns that pay off:
- Batch retries together. If a job processes the same identifiers every few minutes, run them in tight bursts so repeats land inside the 20-minute window.
- Deduplicate before the call. Coalesce identical pending requests on your side — if 500 users hit your form with the same handle in a minute, fire one call, not 500.
- Normalise inputs. The cache key matches byte-for-byte:
JANE-DOEandjane-doeare two entries. Lowercase, trim, and order query params consistently across your codebase. - Stage cold lookups. When backfilling a large list, warm popular identifiers first so downstream workers reading the same names get hits instead of misses.
Your own cache layer (beyond 20 minutes)
If your staleness tolerance exceeds 20 minutes — daily backfills, weekly CRM syncs, analytics pipelines — caching responses on your side cuts traffic even further.
- Key your cache on the canonical identifier returned in
data(entityId,id) — not the input handle, which can change. - Default client-side TTL: 24 hours for people, 7 days for organizations.
- Invalidate proactively on signals you control — a user updates their profile in your app, a CRM field changes, a deal closes.
Cost expectations at scale
For workloads with high duplication (the same handles queried repeatedly), the cache does most of the heavy lifting and your effective per-call cost trends well below the headline live price. For workloads with low duplication (unique identifiers every time), most calls miss the cache and you pay the live price on each one.
See Rate Limits & Credits for tier pricing — your per-credit cost drops as you climb tiers, so live-heavy workloads get cheaper at scale.