Twitter, Reddit, TikTok, and Instagram do not push webhooks for public content. Social Fetch Monitors poll a source on your schedule, diff against the last snapshot, and deliver a signed webhook (or capture to a test inbox) when something new appears.
You'll need an API key — Monitors require one, they're not reachable anonymously — and about five minutes. Everything below uses real request and response shapes; swap in your own handle, subreddit, or hashtag as you go.
Why polling doesn't have to be your problem anymore
The DIY pattern — cron, snapshot, diff, dedupe, alert — is real and useful; our polling guide walks through it. It is also code you own: retry logic, storage, cursor bookkeeping, and the 2 a.m. page when the cron stopped firing days ago.
A monitor is that pipeline, hosted. You describe what to watch and how often; Social Fetch owns scheduling, diffing, delivery retries, and observability. You get a signed POST whenever something is genuinely new.
How it works
| Layer | You own | Social Fetch provides |
|---|---|---|
| What to watch | Platform, account/subreddit/hashtag, schedule | GET /v1/monitors/sources — every watchable operation and its fastest interval |
| Polling & diffing | — | Scheduled fetch, snapshot diff, dedup, baseline check on creation |
| Delivery | An HTTPS endpoint (or nothing — pull-only monitors work too) | Signed POST, 8-attempt retry ladder, manual redelivery, 30-day event retention |
| Verification | Checking the signature before trusting the body | A signing secret per endpoint + @socialfetch/sdk/webhooks |
Step 1: create a test inbox
You don't need a live endpoint to see this work. A sink endpoint behaves like a real one — signed, logged deliveries — except instead of an outbound HTTP call, the request is captured for you to inspect:
secret is only ever returned on creation or an explicit rotation — store it now. (Prefer clicking through? The dashboard wizard creates a test inbox in one click and shows you this exact JSON without a terminal.)
Step 2: create a monitor
Point it at a source, a schedule, and the endpoint from step 1:
Creation runs a synchronous baseline check — it charges one poll, records what's already there so you don't get an event for content that predates the monitor, and returns a preview of what it saw. From here, checks run on schedule automatically; POST /v1/monitors/{id}/trigger (itself free) runs one on demand if you don't want to wait.
Step 3: verify the signature
Every delivery arrives with a socialfetch-signature: t={unix},v1={hex hmac} header. Verify it before you trust the body — anyone can guess an endpoint URL, only Social Fetch (or someone holding your secret) can produce a valid signature for it:
The one rule that trips people up: read the raw body before any JSON-parsing middleware touches it, or the signature won't match a re-serialized object. Full framework examples (Next.js, Hono, Express's raw-body gotcha) live in Receiving & verifying webhooks.
A non-2xx response gets retried 8 times over roughly 21 hours, then waits for manual redelivery — build your handler idempotent against socialfetch-event-id (constant across retries) rather than socialfetch-delivery-id (unique per attempt). Details in Delivery, retries & idempotency.
Monitoring each platform
Ten watchable operations across four platforms today. Every one takes operationId + a small params object — here's what each needs.
Twitter/X
- New tweets from a profile —
twitter.profile.tweets.list,params: { handle: "elonmusk" }. - New tweets matching a search —
twitter.search.list,params: { query: "\"social fetch\"" }— same query syntax asGET /v1/twitter/search.
Twitter/X gets its own deep dive, with the full Nitter/RSS-bridge/enterprise-tier comparison, at the Twitter/X webhook API use case.
- New posts in a subreddit —
reddit.subreddit.posts.list,params: { subreddit: "programming" }. A leadingr/or a full subreddit URL is fine — it's normalized either way. - New posts matching a search, scoped to a subreddit —
reddit.subreddit.search.list,params: { subreddit: "programming", query: "rust" }(queryoptional — omit it to watch every new post in the subreddit that matches nothing in particular, same as the posts feed). - New posts matching a search, site-wide —
reddit.search.list,params: { query: "rust lang" }.
- New posts from a profile —
instagram.profile.posts.list,params: { handle: "natgeo" }. - New reels from a profile —
instagram.profile.reels.list,params: { handle: "natgeo" }. - New posts on a hashtag —
instagram.search.hashtag.list,params: { hashtag: "travel" }(no#).
TikTok
- New videos from a profile —
tiktok.profile.videos.list,params: { handle: "khaby.lame" }. - New videos matching a search —
tiktok.search.videos.list,params: { query: "cat videos" }.
GET /v1/monitors/sources returns this same list live, plus each source's defaultIntervalMinutes, minIntervalMinutes, and a sample event — check it before hardcoding an operationId, new sources land there first.
Picking a schedule
Every source can be polled as fast as once a minute. Cost scales linearly with frequency, not with what the poll finds — a check that returns nothing new still bills, same as one that returns ten items, because the upstream fetch happened either way:
| Interval | Checks/day | @ 1 credit/check | @ 2 credits/check |
|---|---|---|---|
| 1 min | 1,440 | 1,440/day · 43,200/mo | 2,880/day · 86,400/mo |
| 5 min | 288 | 288/day · 8,640/mo | 576/day · 17,280/mo |
| 15 min | 96 | 96/day · 2,880/mo | 192/day · 5,760/mo |
| 1 hour | 24 | 24/day · 720/mo | 48/day · 1,440/mo |
| 6 hours | 4 | 4/day · 120/mo | 8/day · 240/mo |
| 24 hours | 1 | 1/day · 30/mo | 2/day · 60/mo |
Every response includes a live costPreview for the exact schedule you picked, and POST /v1/monitors?dryRun=true returns one without creating anything — validate a schedule's real cost before committing to it. Set spendCapCredits on create (or patch it later) to cap a single monitor's monthly spend; it skips further checks for the month once it hits the cap, rather than draining your whole balance. Full math in Billing for monitors.
One endpoint, many monitors
The signing secret belongs to the webhook endpoint, not the monitor. Watching 50 accounts doesn't mean juggling 50 secrets — create one endpoint, point all 50 monitors at it, and verify every delivery with the same key. Reach for a second endpoint only when you actually want a second, independently-rotatable secret (a different service, a different environment) — not as the default per-monitor behavior.
Monitors vs. polling search yourself
Both are on the table; they answer different questions:
| Monitors | Polling search endpoints yourself | |
|---|---|---|
| Best for | "Tell me when this account / this subreddit posts again" | "Scan the open firehose for anyone mentioning a keyword" |
| You write | A webhook handler | The cron job, snapshot storage, dedup, and diffing logic |
| Delivery | Pushed to you (or pulled via the events API) | You pull on your own schedule |
| Good fit | Competitor content tracking, lead-gen on a subreddit, "alert me when they post" integrations | Brand/crisis keyword monitoring, campaign hashtag rollups, anything spanning accounts you don't already know |
If your job is open-ended keyword or competitor listening across accounts you can't enumerate up front, the polling guide and the social monitoring API use case are the better starting points — you can still run both from the same account and API key.
What you can build
- Competitor tracker — Slack ping the moment a competitor's account posts, before their audience does.
- Auto-repost / cross-post pipeline — new TikTok from a creator triggers a repost job to your own channels.
- Subreddit lead-gen — a webhook per relevant subreddit, routed into your CRM as a new lead the moment someone posts.
- Support/PR early warning — watch your own brand's mentions on a search-type source and alert before a thread grows.
- Content archiving — every new post from an account written straight into your own database, no scheduled export job.
Next steps: Monitoring quickstart (full API walkthrough) · Receiving & verifying webhooks · Dashboard wizard · Twitter/X webhook API · Social media monitoring use case · Pricing