Overview
Webhooks let Mobaro push data to your system instead of you polling the API. When a record changes, Mobaro sends a JSON POST to a URL you control, for automation such as:
Syncing Users to HR or identity platforms
Sending Results to BI tools or data warehouses
Creating CMMS work orders from Assignments or Downtimes
Feeding RideOps Dispatches and Queue times into displays or analytics
At a glance |
|
Who can do this | Super Users create, edit and delete webhooks. Users with Organization › Administrate can view them. |
Where | Configuration › API › Webhooks |
Works on | Backend (web), Public API |
Availability | Managed availability — Mobaro enables webhooks for your organization; ask your CSM. |
Mobaro enables webhooks per organization. Until they're enabled, the Webhooks panel doesn't appear and no webhook sends anything. To have them enabled, ask your CSM or contact Mobaro Support with your organization name and use case.
The API tab appears if the Mobaro API or webhooks is enabled and also holds the API Keys panel, so you may see one panel without the other. See also What is a Mobaro Super User?.
What can trigger a webhook
Each webhook listens to one Resource and fires on the Events you select: Created, Updated or Deleted.
Resource | Events you can select |
Users, Locations, Results, Assignments, Notes, Downtimes | Created, Updated, Deleted |
Dispatches, Queue times (RideOps) | Updated, Deleted only |
⚠️ Heads-up: A new dispatch or queue-time entry arrives as an Updated event, so select Updated to receive new entries. The Configure Webhook dialog only offers Updated and Deleted for these resources, and the Mobaro API rejects Created for them.
Create a webhook
1. Open the Webhooks panel
Go to Configuration › API. The Webhooks panel lists each webhook's Enabled state, Name, Resource, Events and Created date.
2. Fill in the Configure Webhook dialog
Select the + button (tooltip Create). The Configure Webhook dialog opens:
Field | Description |
Webhook name | Identifies the webhook. Required. |
URL | The HTTPS address Mobaro sends data to. Required. |
Resource | What triggers the webhook. Required. Can't be changed after creation. |
Events | One or more of Created, Updated, Deleted. Required. |
Secret | Mobaro signs every request with it. You can only set it in the dialog when creating the webhook. See Verify the webhook signature. |
Regex | Only send notifications whose full JSON payload matches. See Webhook rules and limits. |
Additional headers | Select Add Header to add a Key and Value sent with every request, such as an authorization header. |
Is enabled | Whether the webhook sends data. On by default. |
3. Save the webhook
Select Save. Matching changes now send notifications to your URL.
To edit a webhook, select it and choose the pencil button (tooltip Update). You can change the name, URL, regex, events, headers and Is enabled. For a different Resource, create a new webhook. The Secret isn't shown when editing and can only be changed through the Mobaro API.
You can also list, create, update and delete webhooks with an API key; see the Mobaro API documentation.
Webhook rules and limits
Rule | Detail |
HTTPS only | The URL must be an absolute |
Headers | Key up to 256 characters, value up to 4,096, all together up to 8,192. Every header needs both a Key and a Value. |
Regex | Matched against the whole JSON payload, which has no spaces or line breaks (for example |
Response time | Respond within 5 seconds, or it counts as a failure and is retried. |
Success | Any 2xx is delivered. Anything else, or no response, is a failure. |
Concurrency | One request at a time per organization by default. For more throughput, contact Mobaro. |
Disable or delete a webhook
Turn off Is enabled to stop new notifications and keep the webhook's configuration. Changes made while it's disabled are not queued, so they won't be sent when you turn it back on.
Disabling or editing a webhook doesn't affect already queued notifications. They keep retrying with the URL, headers and secret the webhook had when they were created. To stop them, delete them from the notification list, or delete the webhook.
🛑 Critical: Deleting a webhook also deletes all of its pending notifications. It cannot be undone.
Webhook payload format
Each notification is a POST with a JSON body (Content-Type: application/json) and four fields:
Field | What it contains |
|
|
|
|
| When the notification was created (UTC). Same on every retry. |
| Snapshot of the record's key fields at event time. Always includes |
Example for an updated Location:
{
"event": "Updated",
"resource": "Locations",
"timestamp": "2026-09-24T09:14:27.5123456Z",
"data": {
"id": "locations/1234-A",
"created": "2024-03-02T08:00:00Z",
"updated": "2026-09-24T09:14:27.4981234Z",
"isDeleted": false,
"name": "Thunder Coaster",
"externalId": "TC-01",
"email": null,
"language": "en",
"scannerCode": null,
"rideOps": true,
"address": null,
"users": [],
"userGroups": ["usergroups/12-A"],
"properties": [],
"locationGroups": ["locationgroups/3-A"]
}
}ℹ️ Note: data is a snapshot, not a live copy. If the record changes again, a newer notification follows. For other fields, fetch the record from the Mobaro API with data.id, for example GET /api/customers/locations/{id}.
Fields in data vary by resource: a Results snapshot includes checklist, location, user, score and approval details; a Queue times snapshot includes location, source, time and queue time in minutes. Field order can vary, so read fields by name.
Detect deletions with event. isDeleted is usually true on a Deleted event, but a User removed from your organization who still belongs to another arrives with isDeleted: false.
Verify the webhook signature
With a Secret set, every request carries an X-Webhook-Signature header: the HMAC-SHA256 of the request body, keyed with your secret and Base64-encoded. To verify a request:
Read the raw request body. Don't parse and re-serialize the JSON first; that changes the bytes.
Compute HMAC-SHA256 of it with your secret and Base64-encode the result.
Compare with the header using a constant-time comparison. Reject the request if they differ.
Node.js
const crypto = require("crypto");
// rawBody = the exact bytes of the request body, before any JSON parsing
function isFromMobaro(rawBody, signatureHeader, secret) {
const expected = crypto.createHmac("sha256", secret).update(rawBody).digest("base64");
const received = signatureHeader || "";
return received.length === expected.length &&
crypto.timingSafeEqual(Buffer.from(received), Buffer.from(expected));
}Python
import base64, hashlib, hmac
def is_from_mobaro(raw_body: bytes, signature_header: str, secret: str) -> bool:
digest = hmac.new(secret.encode("utf-8"), raw_body, hashlib.sha256).digest()
expected = base64.b64encode(digest).decode("ascii")
return hmac.compare_digest(expected, signature_header or "")
Webhook delivery and retries
Mobaro queues a notification for each matching change and sends it within moments. If delivery fails, Mobaro retries automatically, waiting longer each time: seconds, then minutes, then hours. After about ten failures it retries once every 24 hours. There is no maximum number of attempts: it retries until your endpoint accepts it or someone deletes it.
Delivered notifications are removed from the queue, so the Webhook Notifications list shows only waiting or failed ones. To read it and retry straight away, see Monitoring webhook deliveries and retrying failed events.
⚠️ Heads-up: A failed notification waits for its next retry while newer ones are sent, so notifications can arrive out of order. Use data.updated or timestamp to ignore anything older than what you have.
Webhooks vs API polling
Use case | Best approach |
React quickly to changes | Webhooks |
Scheduled snapshots or exports | API polling / Power Automate |
Large historical datasets | API polling with |
For API errors and rate limits, see Handling errors, rate limits, and retry logic.
Best practices
Set a long, random Secret, keep it only on your server, and verify every signature.
After changing the secret through the Mobaro API, accept the old one for a while: queued notifications are still signed with it.
Respond with a 2xx within 5 seconds; do heavy work afterwards.
Make processing idempotent: the same notification can arrive twice, so key on
resource,event,data.idandtimestampto skip duplicates.Keep regex filters simple and test them; bad patterns fail silently.
During planned maintenance of your receiving system, disable the webhook to stop new events piling up, or leave it enabled if you need every change: failed deliveries retry once your endpoint is back.
Frequently asked questions
How do I get webhooks activated for our organization?
Ask your CSM or contact Mobaro Support. Mobaro enables webhooks per organization. Until they're enabled, the Webhooks panel doesn't appear under Configuration › API and no webhook sends anything.
How do I make a webhook trigger only for one assignee or User Group?
Filter on the ID, not the name: payloads identify users, User Groups and Locations by ID only. For example, usergroups/1234-A matches Assignment payloads with that group's ID in assignees. The regex runs against the whole JSON payload; invalid or slow patterns send nothing. See Understanding IDs in Mobaro.
Can the webhook payload include names instead of IDs?
No. Payloads carry IDs, for example an Assignment's target Location, assignees and creator. Look the names up through the Mobaro API with those IDs, or keep a lookup table on your side.
I can see the Webhooks panel, but saving fails. Why?
Creating, editing and deleting webhooks needs a Super User. Organization › Administrate only lets you view them.
Can I delete many webhooks at once?
Not in the backend: the Webhooks panel deletes one selected webhook at a time. To clean up many, list them with GET /api/customers/webhooks and delete each with DELETE /api/customers/webhooks/{id}. Deleting a webhook also deletes its pending notifications.