About Social Fetch

Teams that touch social data end up maintaining bespoke scrapers per platform — one platform 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.

We sell predictable behaviour when access gets weird. Every route returns data plus meta — success, not found, or a failed lookup.

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, we patch and post to the changelog. You shouldn't discover breakage because a cron returned zero rows.

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, see Enterprise and email rough numbers and a timeline — we send specifics, not a discovery call.