About
About Social Fetch
Unified API for public social data — one integration, every network, predictable JSON.
Social Freak Ltd (company no. 14659411), registered in England and Wales, operates Social Fetch.
Teams that touch social data end up maintaining bespoke scrapers per platform — one upstream change and someone is triaging on a Saturday. We've been that team at agencies, startups, and product companies that needed data in a warehouse by Monday.
The pattern repeats: Instagram and TikTok first, then YouTube transcripts, then Facebook groups. Six months later you're on four scrapers and three JSON shapes.
Public social data should behave like any other API — consistent schemas, predictable errors, changelogs you can plan around.
Social Fetch runs the fetch logic and returns structured responses your pipeline can treat like any HTTP dependency. You own deduplication, alerting, and business rules. We own the scraper maintenance.
What we build
Not a scraper marketplace or a no-code dashboard — an API your backend calls directly.
REST API across 23 networks
Profiles, posts, comments, search, reels, transcripts, and ad-library lookups. TikTok, Instagram, YouTube, Reddit, Facebook, X, LinkedIn, GitHub, and more — same auth header, same response envelope.
Normalised JSON, not raw HTML
We absorb DOM shifts, auth cookie churn, and per-platform quirks upstream. Your code sees typed fields and pagination cursors, not a scraper that broke because someone renamed a CSS class.
Ask endpoint and MCP tools
Natural-language lookups for quick exploration, plus Model Context Protocol integration so Cursor, VS Code, and Claude can call documented endpoints without you pasting curl into chat.
Docs, playground, and TypeScript SDK
OpenAPI spec, interactive playground, and a typed client if you want one. None of them are required — plain HTTP works fine.
Reliability is the product
We sell predictable behaviour when access gets weird. Every route returns data plus meta — success, not found, or upstream failure.
meta.lookupStatus says whether the target exists. meta.requestId is on every response for support traces. lookup_failed and 503 don't charge — you pay for completed lookups.
When a platform changes upstream, we patch and post to the changelog. You shouldn't discover breakage because a cron returned zero rows.
What we optimise for
Things you'll notice when you integrate, read the docs, or open a support ticket.
Clarity over cleverness
Every field is documented. Every error has a code. You should know what a field means six months from now without reading source.
Operational clarity
When platforms change upstream, we tell you what changed, when, and what to update. No silent breakage.
Developer-led roadmap
Features get built when real teams hit real walls. We read support threads before sprint planning.
Stable contracts
Schema changes are versioned, documented, and announced. You pick when to migrate—not us.
Security and scope
We work with publicly available data. If a use case is in a grey area, email us before building—not after.
No artificial friction
No rate limits, no per-minute caps, no lock-in subscriptions. Pay for credits; use them when you need them.
How we work
Small UK team — engineering, support, and product in one Slack. Support replies usually come from someone who can grep your requestId.
Docs first, support second, sales last. The API reference and playground cover most questions; the changelog covers most breakage.
No enterprise sales floor. For volume pricing, security questionnaires, or subprocessors, email rough numbers and a timeline — we send specifics, not a discovery call.
Want to collaborate, challenge a use case, or ask whether something is in scope? Email us—we reply to every message. If you're ready to build, start with the quickstart.