Reliability you can check, not just claims
We co-located compute with the data, refund what doesn't come back, cache repeats for zero credits, and expose a live status endpoint. Every number on this page is a real production measurement.
What makes an API reliable enough to build on?
Three things, all measurable: it stays fast when you burst it, it never charges you for data it didn't return, and it tells you the truth when something is off. Here is how SocialCrawl does each one, with the production numbers behind it.
Fast under load
Co-located compute and upstream keep-alive killed the at-scale slowdown.
No charge for nothing
Empty pages refund automatically; cached repeats cost zero credits.
Honest when it drifts
Partial-data warnings and a live status endpoint, no support ticket needed.
The numbers behind the speed
Before and after a 25-way concurrent burst, measured on production. Root cause: compute ran in US-East while the database and cache live in London, so every call paid a transatlantic hop. We moved compute to London and added upstream HTTP keep-alive.
Re-verified live 2026-06-30 on a lighter single-machine probe: warm database path 31ms, upstream burst inflation 1.36x, zero 429s.
Repeat a call and it costs nothing
Within the cache window, an identical request serves from cache for zero credits and returns roughly 4 to 20 times faster. The response carries X-Credits-Used: 0 and cached: true so you can see it happened.
Need a guaranteed-fresh, billed pull? Send Cache-Control: no-cache. Force-refresh, per-endpoint TTL overrides, and cache-key versioning all ship today.
See how credits workCache windows
- Profiles
- 15 min
- Posts
- 10 min
- Comments
- 5 min
- Search
- 2 min
- Analytics
- 30 min
When something drifts, the response says so
Two channels keep you honest about data quality without opening a support ticket.
Partial-data warnings
If an upstream field stops resolving or a computed field gets clamped, the response adds data._warnings, an array naming exactly which paths failed. Success and credit semantics are unaffected, and when everything resolves the key is absent entirely.
Live status endpoint
GET /v1/status returns per-platform health from the circuit breaker (operational, degraded, or down), the current upstream-version mix so you can watch for provider drift, and an updated_at timestamp.
What you can rely on
The policies behind the numbers.
Automatic refunds
Empty pages are refunded automatically, so you are never charged for data that didn't come back. Cached repeats within the window cost 0 credits.
Schema stability
Changes are additive-first: new endpoints and fields rather than mutations to existing ones. The unified envelope and ext passthrough make additive the default, and breaking changes come with advance notice.
Pagination hygiene
An empty page ends pagination cleanly instead of looping, a non-advancing cursor is caught, and cross-page duplicates are removed on our side. You just keep passing the opaque next_cursor.
A known ceiling
Each key gets 50 concurrent requests today, with a hard 429 over the limit rather than silent queuing. It is a limit you can design around, published rather than hidden.
“Every figure here is a production measurement you can reproduce against your own key.”
Frequently asked questions
Can't find what you're looking for? Talk to our team or ask the AI agent below
Reliability you can curl
Hit the live status endpoint, then build against a key that refunds what it can't return.
curl https://www.socialcrawl.dev/v1/status