General

Social Media Monitoring Webhooks: Get Notified the Moment Someone Posts (2026)

Get a signed webhook the moment a new tweet, subreddit post, TikTok video, or Instagram post appears — no cron job, no polling, no diffing snapshots yourself.

Social FetchUpdated

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

LayerYou ownSocial Fetch provides
What to watchPlatform, account/subreddit/hashtag, scheduleGET /v1/monitors/sources — every watchable operation and its fastest interval
Polling & diffingScheduled fetch, snapshot diff, dedup, baseline check on creation
DeliveryAn HTTPS endpoint (or nothing — pull-only monitors work too)Signed POST, 8-attempt retry ladder, manual redelivery, 30-day event retention
VerificationChecking the signature before trusting the bodyA 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:

Request
bash
Request
json

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:

Request
bash
Request
json

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:

Request
typescript

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 profiletwitter.profile.tweets.list, params: { handle: "elonmusk" }.
  • New tweets matching a searchtwitter.search.list, params: { query: "\"social fetch\"" } — same query syntax as GET /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.

Reddit

  • New posts in a subredditreddit.subreddit.posts.list, params: { subreddit: "programming" }. A leading r/ or a full subreddit URL is fine — it's normalized either way.
  • New posts matching a search, scoped to a subredditreddit.subreddit.search.list, params: { subreddit: "programming", query: "rust" } (query optional — 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-widereddit.search.list, params: { query: "rust lang" }.

Instagram

  • New posts from a profileinstagram.profile.posts.list, params: { handle: "natgeo" }.
  • New reels from a profileinstagram.profile.reels.list, params: { handle: "natgeo" }.
  • New posts on a hashtaginstagram.search.hashtag.list, params: { hashtag: "travel" } (no #).

TikTok

  • New videos from a profiletiktok.profile.videos.list, params: { handle: "khaby.lame" }.
  • New videos matching a searchtiktok.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:

IntervalChecks/day@ 1 credit/check@ 2 credits/check
1 min1,4401,440/day · 43,200/mo2,880/day · 86,400/mo
5 min288288/day · 8,640/mo576/day · 17,280/mo
15 min9696/day · 2,880/mo192/day · 5,760/mo
1 hour2424/day · 720/mo48/day · 1,440/mo
6 hours44/day · 120/mo8/day · 240/mo
24 hours11/day · 30/mo2/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:

MonitorsPolling search endpoints yourself
Best for"Tell me when this account / this subreddit posts again""Scan the open firehose for anyone mentioning a keyword"
You writeA webhook handlerThe cron job, snapshot storage, dedup, and diffing logic
DeliveryPushed to you (or pulled via the events API)You pull on your own schedule
Good fitCompetitor content tracking, lead-gen on a subreddit, "alert me when they post" integrationsBrand/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