Facebook Marketplace match webhooks: pipe a buy box into your own stack

A Facebook Marketplace match webhook is a signed POST from Crawlbench to your HTTPS endpoint after a listing clears your buy box. Slack and Discord alerts are a different pipe: a human-readable ping into a channel. Use chat alerts when a person should read the deal. Use an outbound webhook when a bot, sheet, or CRM should receive the same match as structured data.

What is a match webhook, and what is a Slack alert?

Slack and Discord alerts paste a message people can read. A signed outbound webhook hands your system the match so your code can file it.

• Incoming channel alert. You paste a Slack or Discord incoming webhook into Crawlbench Alerts. Crawlbench posts a readable alert into that channel. Humans triage it. Setup lives in alert channels and the Slack alerts post.
• Signed outbound match webhook (Pro and above). Crawlbench POSTs JSON to an endpoint you own. Your bot, CRM, or script reads it. Settings is where you connect the URL. The payload uses the same fields you already read on a Matches row: the listing, the reasons it passed, and the comp when one exists.
• Read API (early access). A pull path for listings, monitors, and market rollups. Webhooks push on a new match. The read API is for when you need history or a rollup on your schedule. Tell Crawlbench which shape you need. It is not a feed you resell as market stats.

Both alert styles fire after the match gate. A listing that fails your excludes never POSTs and never pings the channel. Crawlbench never messages the seller through a webhook, an API call, or an alert, so your account stays safe.

What lands in the payload?

The payload is the desk row, not a second vocabulary.

You get listing identity and price, the filters the listing passed, and the ask-vs-comp when a sample exists. Each delivery is signed so you can verify it came from Crawlbench, and failed deliveries are retried. You do not need a private Facebook API, and this is not Graph access to someone’s account.

Do not treat the webhook as a license to auto-message sellers. A serious stack files the match, assigns a person, and lets that person write on Facebook. An endpoint that DMs strangers will get you blocked faster than a noisy buy box.

Timing matches the desk. Crawlbench sends the match the moment a listing clears your buy box, in every city on the monitor, to your webhook and your alert channels alike.

Which stacks is this actually for?

These are patterns, not case studies. No customer is named here.

• A Slack bot that files a CRM row, which is more than a channel incoming webhook. The Slack alerts post covers the human channel. This post covers the bot that runs after the POST.
• A sheet or Airtable appender for a buyer who wants a log they can sort.
• An internal triage queue or a dealer system that should see only rows that already cleared the buy box.
• A custom Discord bot that enriches a post instead of dumping raw text into a channel.

If your team still decides deals by reading Slack, stay on channel alerts. Wire an outbound endpoint when a second system must act on the same gate. Zapier-style “send matches onward” is the same idea. Prove the gate before you add another hop.

Why the buy box has to be clean first

A webhook amplifies whatever you approve. A wide keyword pile will POST junk into the CRM all afternoon.

Build the box the way the buy box excludes post describes: identity, a price band, and a short exclude list. Then create the monitor and read Matches. If you would message the rows yourself, the gate is clean enough to automate. If you would mute the channel, do not point a webhook at it yet.

Edit and rematch when the first hour is noisy. Change excludes and re-score the recent window instead of hoping the endpoint will filter what the monitor would not.

How do you try this without wiring Pro on day one?

Prove one clean buy box on a Day Pass: 24 hours, no card, one monitor. Open Matches. If the rows are message-worthy, upgrade to Pro or Scale for outbound webhooks. Features states the split: webhooks ship on Pro and above. The read API stays early access.

If you need several days at the desk before you trust an endpoint, the 3-day free trial is the longer prove-it window. Pick that instead of a Day Pass. Do not stack them into one offer. Either way, wire the webhook only after the gate is clean. Day Pass readers do not need API docs on minute one.

What should you check before you connect an endpoint?

Ask these before you paste a URL:

• Does the endpoint only accept matches that already cleared the buy box, or will it try to re-filter a firehose?
• Can you verify the signature and reject anything unsigned?
• What happens on a retry? Your handler should treat a repeated delivery as the same match, not a second lead.
• Who is allowed to message the seller? If the answer is “the webhook,” stop. A person messages on Facebook.
• Do you need history, or only the next match? History and rollups are the read API, which is early access. The webhook is the push.

FAQ covers account boundaries in plain language. Nothing in that path hands Facebook your password so a bot can post.

What not to expect

• Crawlbench never messages sellers for you, so your account stays safe.
• A webhook is not Facebook’s official Marketplace API.
• Channel alerts and outbound POSTs are not interchangeable. Link the Slack post for humans. Keep this URL for your stack.
• A signed payload will not fix a buy box that lets parts ads and salvage through.

Start with one lane you already know. When Matches looks like work you would do by hand, point Pro at your endpoint and let the same gate feed the CRM.