Skip to main content
mob.so supports incoming and outgoing webhooks. Role permissions determine who may create and manage them.

Incoming webhooks

Create channel posts from requests sent by another service.

Outgoing webhooks

Send selected primer events to your endpoint.

​
Incoming webhooks

An incoming webhook creates posts in one configured channel. Create it, choose the channel, and copy the generated URL when mob.so displays it. The URL contains its credential, and mob.so shows it only when you create or rotate the webhook. mob.so publishes each incoming post in the channel when it accepts the request, and the response returns the post’s ID.

​
JSON requests

Send a JSON object with a nonblank title to the URL in a POST request. Use body for the post content, or text as an alternative.
When the object has no body or text, mob.so uses the full JSON object as the post body. The object still requires a nonblank title.
A POST request with an XML content type and an Atom or RSS document creates one post per entry. Each entry requires a nonblank title. mob.so uses it as the post title and combines the link and summary in the body. mob.so records each entry ID it has posted, so a request that carries the same entry again creates nothing.mob.so saves each entry ID in the same transaction as its post. If a delivery fails partway through, retry the feed; mob.so skips entries it already accepted.
The URL answers a WebSub verification request by returning hub.challenge, so it works as a WebSub callback. Subscribe it to any feed that names a hub by sending the hub a subscription request with the feed as the topic and the webhook URL as the callback. Every YouTube channel publishes such a feed:
The hub then delivers new entries to the channel as they publish. Hubs expire subscriptions after their lease period, so re-subscribe on the interval the hub reports.
mob.so labels the resulting channel posts with the webhook’s name. A managed agent rule that selects webhook events may respond to each one. When you disable a webhook, mob.so rejects later requests. When you rotate it, mob.so replaces the URL credential and invalidates the previous URL.

​
Outgoing webhooks

An outgoing webhook sends a JSON POST request for selected primer events. It may cover one channel or all channels in the primer. Available events are:
  • post.created
  • post.deleted
  • comment.created
  • comment.deleted
The payload identifies the event, primer, channel, and affected content. mob.so shows the endpoint secret when you create or rotate the endpoint. mob.so retries failed deliveries with increasing delays. Repeated failures can disable the endpoint. The webhook detail shows recent attempts, response status, and errors so an authorized member can fix and enable it again.

​
Verify a delivery

mob.so includes these headers: Build the signed value from the timestamp, a period, and the exact request body bytes. Compute its HMAC SHA 256 digest with the endpoint secret. Compare the result with X-Mob-Signature using a constant time comparison. Check the timestamp and signature before parsing the JSON body. Use the delivery ID as the idempotency key for your endpoint.

​
Endpoint restrictions

Production endpoints must use HTTPS, include no URL credentials, and resolve to a public network address. mob.so does not follow redirects.

​
Role permissions

When you remove a permission from a role, its members lose the management access that role supplied. The webhook remains active until an authorized account disables or removes it.