Pulling exports
- Export the report
- Upload it somewhere
- Hope nothing was missed
Your warehouse is a day behind, your delivery partner learns about an order from a phone call, and when an upload fails nobody notices until the numbers do not match.
Webhooks · UAE & GCC
Restaurant Webhooks Your Developers Can Rely On
When an order is placed, a booking confirmed, a rider picks up or an ingredient runs low, Tahlib sends a signed HTTPS request to your own system within moments. If your server is down, it tries again — six attempts over two and a half hours — and every delivery is logged so nothing goes missing quietly.
- Orders, online payments, reservations, deliveries, menu and stock events
- Every request signed with HMAC-SHA256, so you know it came from Tahlib
- Six attempts with backoff, a delivery log, and one-click redelivery
An endpoint and its delivery log, as they ship.
More than a CSV export
Your systems hear about it when it happens
Most restaurant systems make you pull your own data: a nightly export, a script that scrapes a report, a spreadsheet somebody uploads on Monday.
Tahlib Webhooks
- Event happens
- Signed request
- Your endpoint
- Retry if it fails
- Logged
- Redeliver
Each event is pushed the moment it happens, signed so your server can prove where it came from. A failed delivery is retried on a schedule and recorded with the status your server returned, so a gap is visible and fixable rather than silent.
Your developers still build the integration. They stop building the plumbing under it.
How it works
From an endpoint URL to events arriving
About ten minutes for a developer who has handled a webhook before.
Add an endpoint
Give it a name and an HTTPS URL, and choose the events it should receive — orders, payments, reservations, deliveries, menu, inventory.
Save the signing secret
A 32-byte secret is shown once. Tahlib keeps only a hash of it, so store it on your side straight away.
Send a test
Fire a test event from the dashboard and see the status code and response time your server returned.
Verify each request
Recompute the HMAC-SHA256 signature from the timestamp and the raw body with your secret, and compare it with the header.
Answer with a 2xx
Anything else — an error, a redirect, or no answer within ten seconds — counts as a failure and is retried.
Watch the log
Every delivery with its event, status, HTTP code and attempt number. Filter by status or event, and redeliver any of them.
Changing, testing or redelivering is limited to the owner; the rest of the team can read the log.
When your server is down
Six attempts before anything is lost
A deploy, an outage, an expired certificate — none of them should cost you an order event. This is what happens to one that fails.
What you get
Webhooks built the way integrators expect
Grouped by the job, not by the screen it lives on.
Events
Seventeen events published today.
- Orders: created, updated, completed and cancelled
- Online payments: succeeded, failed and refunded
- Reservations: created, confirmed and cancelled
- Deliveries: assigned, picked up and delivered
- Menu items: created and updated
- Inventory: an ingredient crossing its low-stock level
- Customers: created through the API
Security
Proof that a request came from Tahlib.
- HMAC-SHA256 signature over the timestamp and the raw body
- Signature, event, delivery id, endpoint and timestamp headers on every request
- A body hash header for an extra integrity check
- Secret shown once and stored hashed; rotate it whenever you need to
- HTTPS endpoints only
Reliability
For the day your server is not there.
- Six attempts: immediately, then after 10 s, 30 s, 5 min, 30 min and 2 h
- Ten-second timeout per attempt; only a 2xx counts as delivered
- An endpoint that fails five deliveries in a row is switched off automatically, and the change audited
- Re-enabling an endpoint resets the count
The delivery log
Every attempt, kept.
- Time, event, status, HTTP code and attempt number per delivery
- The first 4 KB of your server’s response stored with each attempt
- Filter by status, event and date; test deliveries hidden unless you ask
- Redeliver any delivery with one click
Per-endpoint control
Different systems, different events.
- Each endpoint subscribes to its own set of events
- Change the events, the URL or the name at any time
- Disable and re-enable without losing the endpoint
- A test button, limited to five sends a minute
Signatures
Verify every request in a few lines
A webhook endpoint is a public URL. The signature is how your server tells Tahlib’s requests from anyone else’s.
What is signed
The request’s Unix timestamp and its raw body, joined by a dot, signed with HMAC-SHA256 using your endpoint’s secret.
Where it is
The X-Tahlib-Signature header carries the timestamp and the signature as t=… and v1=…, so your code has everything it needs in one place.
Replay protection
Because the timestamp is inside the signature, your server can reject anything older than a few minutes, even if someone captured a genuine request.
De-duplicating
Each event carries an id that stays the same across automatic retries, so a request your server already processed can be recognised and skipped.
Connected operations
Where the events come from
Webhooks carry what the rest of Tahlib records. Each product you use is another stream your systems can listen to.
- Orders
- Payments
- Bookings
- Deliveries
- Menu
- Stock
Orders
Created, updated, completed and cancelled — from the till and the QR menu.
Online Payments & Pay-at-Table
A guest’s online payment succeeded or failed, and a refund completed.
Reservations
A booking created, confirmed or cancelled.
Rider Dispatch
A delivery assigned to a rider, picked up and delivered.
Menu
A menu item created or changed, for systems that mirror your menu.
Inventory
An ingredient crossing its low-stock level, for reorder automation.
Products are switched on individually, each priced per branch. View all products
Where it fits
What teams build on it
Same events, different destination.
- Data warehouses
- Stream every order into your own warehouse as it happens, instead of loading yesterday’s export each morning.
- Accounting and ERP
- Hand completed orders to the middleware your accountant’s system already uses, without anyone retyping a total.
- Kitchen and ops alerts
- Post a message to your team chat when a large booking is confirmed or a key ingredient runs low.
- Delivery and logistics partners
- Tell your own delivery partner the moment a run is assigned, picked up and delivered.
- Groups with their own platform
- Mirror menu changes into a group website or app so it never drifts from what the branches sell.
Built here
The details that matter for UAE integrations
Written around how restaurant groups here actually connect systems.
Standard, not proprietary
JSON over HTTPS, HMAC-SHA256 signatures and plain retries — the same patterns your developer already knows from payment gateways.
Your data, pushed to you
Order and booking events go to the endpoint you choose, so the system of record for your reporting can be your own.
One endpoint per system
Your warehouse, your loyalty partner and your ops chat can each receive only the events they need.
Owner-controlled
Only the account owner can add endpoints, change them or rotate secrets, and every change is written to the audit log.
Questions, answered
What developers ask before they integrate
Which events are sent?
Seventeen: order created, updated, completed and cancelled; payment succeeded, failed and refunded; reservation created, confirmed and cancelled; delivery assigned, picked up and delivered; menu item created and updated; inventory low stock; and customer created, which fires when a customer is created through the API.
Are payment events available?
Yes, for payments guests make online through Online Payments & Pay-at-Table: payment succeeded when your provider confirms a payment, payment failed when one is declined, and payment refunded when a refund completes. A bill settled at the till fires order completed instead.
How do I verify a request?
Read t and v1 from the X-Tahlib-Signature header, compute HMAC-SHA256 of the timestamp, a dot and the raw request body using your endpoint’s secret, and compare the result with v1. Rejecting old timestamps protects against replays.
What happens if my endpoint is down?
Each delivery is attempted six times — immediately, then after 10 seconds, 30 seconds, 5 minutes, 30 minutes and 2 hours. After that it is marked failed and can be redelivered from the log. Five failed deliveries in a row switch the endpoint off until you re-enable it.
Could I receive the same event twice?
Yes, as with any webhook system — for example if your server processed a request but answered too slowly. The event id is the same across automatic retries, so de-duplicate on it. A manual redelivery is sent with a new id.
Are events delivered in order?
Not guaranteed. Retries can land after later events, so use the createdAt timestamp in each event when order matters.
Do orders from Talabat or Careem fire events?
Orders logged from delivery platforms do not send an order created event today.
Can I read data through an API with keys?
Not yet. API keys can be created in the dashboard, but no endpoint accepts them today, so integrations are push-only through webhooks for now.
What happens when I rotate the secret?
The new secret applies to the next request straight away, with no overlap period — update your server before or as you rotate.
Does it work in Arabic?
The webhook screens in the dashboard are in English today.
What does it cost?
It is priced per branch, per month, with a free trial — switched on and off from your dashboard. The pricing section above shows the current figure and what it drops to as you add branches.
Let your systems hear it first
Add an endpoint, send a test, and the next order is on its way to your server as it happens.
No card to start · nothing to install · cancel whenever