Reliability for live social fetches
Social Fetch runs live upstream lookups across 17 platforms (137 marketplace operations). We maintain the scrapers. You get a requestId, typed outcomes, and measured uptime — not a contractual SLA we cannot control.
Live fetch, not a shared cache
Every marketplace lookup hits the platform (or our extraction path) at request time. There is no shared response cache that serves yesterday's profile as if it were fresh. That is why average latency sits around ~3.2s on live fetches — slower than a static CDN hit — that is what you are buying.
When Instagram or TikTok changes markup, your pipeline does not invent empty rows. We fix the adapter. Your code keeps reading the same field names.
What we mean by reliability
99.8% uptime is a rolling 90-day measurement across the public API — the share of time the service answered health and served traffic. It is not a contractual SLA, not a guarantee against upstream platform outages, and not a promise that every handle resolves to found.
A completed lookup that returns not_found or private is still a successful HTTP response with a billed attempt when the docs say so. Infrastructure failures on our side do not charge credits. Those are different outcomes; the envelope makes them explicit.
Terms of Service do not invent availability commitments unless we sign something separate. If you need a paper SLA, talk to us — do not reverse-engineer marketing percentages into a contract.
Current measured status
Rolling public numbers we publish on the marketing site. For a liveness probe, call GET /health on the API (docs linked below).
99.8%
Uptime
Measured across the public API over the last 90 days
~3.2s
90-day avg response
Rolling mean latency on live upstream fetches — no cache in front
137
API endpoints
Marketplace operations on one key
17
Platforms
OpenAPI marketplace tags
What you get when something breaks
requestId on every response
Paste meta.requestId into support and we can trace the upstream attempt. No guessing which call failed at 2am.
lookupStatus before you parse
found, not_found, private, and related outcomes sit in data — not as an empty array you have to interpret.
No charge when we break
Infrastructure failures do not touch your balance. You pay for completed lookup attempts, not our scraper having a bad hour.
Health for monitors
GET /health is unauthenticated liveness. Point uptime checks there; do not page yourself on a single not_found profile.
Docs and status checks
- Health check
GET /health — liveness probe, no auth, no credits.
- Errors and outcomes
Success vs error envelopes, lookupStatus, and when to retry.
FAQ
Do you publish a contractual uptime SLA?
No. The 99.8% figure is a rolling 90-day measurement on the public API, not a contractual guarantee. Platform outages and upstream blocks sit outside any percentage we publish. Custom availability terms require a separate agreement.
Where do I check if the API is up?
Call GET /health on api.socialfetch.dev (documented under Health check). For support on a bad response, send meta.requestId to support@socialfetch.dev.
Why is average latency around 3 seconds?
Live fetches against social platforms take longer than reading a shared cache. The published ~3.2s figure is a rolling mean on those live lookups — not a CDN hit.
Are not_found responses failures?
HTTP 200 with lookupStatus not_found (or private) means the lookup completed and the domain outcome is explicit. That is different from a 5xx or infrastructure error. Billing follows the operation docs — completed attempts may still charge.
What happens when a platform changes its HTML?
We update the adapter. Your client keeps the same OpenAPI field names. You should not need to rewrite parsers for every DOM shift.
Does reliability cover all 17 platforms?
The uptime measurement is for the public API service. Individual platforms can still return not_found, private, or temporary upstream errors. Coverage is the same catalog as the rest of the product — 17 marketplace platforms and 137 operations.
Start with 100 free credits
No card. Call a live profile route, keep the requestId, and see the envelope yourself.