When your social data vendor gets acquired or repriced

Your social data vendor changed ownership, price, or support status. The pipeline still has to run on Monday.

You already call social data in production for listening, creator pulls, or embedded lookups, and now you have to move. Not a one-off trial scrape.

What usually breaks

A forced migration is not just a new API key.

Auth changes. Field names change. Pagination changes. Rate limits and credit semantics change. Schedules and alerts you built on top of the old client have to be re-pointed. Miss one and you spend the week debugging envelopes instead of shipping product.

Write down the routes you actually call before you rewrite anything.

What continuous coverage means here

Social Fetch is a narrow social media scraping API. Continuous coverage means scrapers we maintain, live lookups rather than a cached index, and consistent fields across the platforms you use. Layout changes stay on our side.

It does not mean a listening UI. It does not mean we are a scraping platform where you build and babysit your own scrapers. Apify and Bright Data are broad web-scraping infrastructure; social is a corner of what they do. We do one thing.

Docs: Brand monitoring recipe, competitor profile tracking on the same recipes index, and the Capability matrix / /llms-endpoints.txt for the full route list.

Migration checklist

1. List the production routes you call today (profile, search, comments, transcripts, ads — whatever is live).
2. Map each to a Social Fetch operation via the Capability matrix or /llms-endpoints.txt. Prefer typed routes once you know them.
3. Replay one real production lookup with a new key. Check lookupStatus before you trust the payload. Keep meta.requestId if something looks wrong.
4. Budget credits for the schedule you already run. Metering is per completed lookup, including not_found / private on HTTP 200 where documented.
5. Run old and new in parallel for a week before cutover. Compare fields you depend on, not just HTTP 200.

If you use an AI assistant against the API, the hosted MCP server is at https://api.socialfetch.dev/mcp (OAuth by default; x-api-key when the client never prompts). Same credits as REST.

Fit and non-fit

Fit: recurring public social lookups you already depend on profiles, posts, comments, search, transcripts, metrics — and you want scrapers maintained for you.

Non-fit: general web, ecommerce, or price monitoring as the core job; private or login-gated data; expecting a full analyst listening product without building your own UI.

Billing under a load that does not stop

Lookups use credits. 100 free credits on signup. PAYG packs never expire. If the workload never ends, a subscription allowance usually fits better than repeated one-off packs.

Check current pack and plan figures on Pricing before you put numbers in internal runbooks.

Start

Create a key, call whoami, then replay one production lookup path with free credits. Wire the same call on the schedule you already use.

socialfetch.dev · Docs · MCP