About
About Social Fetch
We build a unified API for public social data so engineering teams can stop maintaining scrapers and get back to shipping product. One integration, every network, predictable JSON.
Social Freak Ltd (company no. 14659411), registered in England and Wales, operates Social Fetch.
Every team that touches social media ends up writing the same thing: bespoke scrapers for each platform, maintained indefinitely by whoever drew the short straw. One platform update and someone is triaging incidents on a Saturday. We've been that team — at agencies running influencer pipelines, at startups building creator tools, at product companies that needed Reddit threads in a warehouse by Monday.
The pattern repeats: a PM asks for "just Instagram and TikTok," an engineer wires up two integrations, then marketing wants YouTube transcripts, then legal asks whether Facebook group posts are in scope. Six months later you're maintaining four scrapers, three different JSON shapes, and a spreadsheet of which endpoints still work after the last deploy.
Public social data should behave like any other API — consistent schemas, predictable errors, changelogs you can plan around. The data already exists. What's missing is a layer that normalises it, absorbs upstream churn, and lets your team move on.
Social Fetch is that layer. We run the fetch logic, rotate through upstream breakage, and return structured responses your pipeline can treat like any other HTTP dependency. You own deduplication, alerting, and business rules. We own the part that used to page someone at 2 a.m.
What we build
Not a scraper marketplace or a no-code dashboard — an API your backend calls directly.
REST API across 20 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
Most social-data vendors sell access. We sell predictable behaviour when access gets weird. Every route returns the same top-level shape: data plus meta, whether the lookup succeeded, returned not found, or hit an upstream wall.
meta.lookupStatus tells you explicitly whether the target exists — not an empty array you have to interpret. meta.requestId is on every response so you can log failures and we can trace the exact upstream attempt without a week of email tennis. Infrastructure failures (lookup_failed, 503) don't charge your balance — you pay for completed lookups, not for our scraper having a bad hour.
When a platform changes something upstream, we patch on our side and post to the changelog. You shouldn't discover breakage because your cron job returned zero rows. If we can't fix it silently, you'll hear about it before your dashboard goes flat.
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
We're a small UK team — engineering, support, and product in the same Slack. Nobody sits between you and the person who wrote the endpoint. When you email support, the reply usually comes from someone who can grep the logs for your requestId and tell you what happened upstream.
Docs come first, support second, sales last. We'd rather you never need to contact us because the docs answered the question. The API reference and playground cover most integration questions; the changelog covers most breakage. When you do write in, you get a direct reply — not a ticket number and a 72-hour SLA boilerplate.
We don't run an enterprise sales floor. If you need volume pricing, a security questionnaire, or a subprocessor list for procurement, email us with rough numbers and a timeline — we'll send specifics, not a calendar link to 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.