Anyone who needs to connect RabbitWork to an ERP, an automation, or a data warehouse already knew the path: poll the API every so often to find out whether an hour had changed, whether the week had been approved, whether a project had closed. Tokens on one screen, the webhook on another, usage limits somewhere else. Integrating was possible. It was not a flow.
Webhooks and the API panel in the same place exist so the other side reacts when the event happens — not when someone remembers to pull the data.
This post is for the people who run the integration: the account admin, the systems team, the agency that already asked “when it is logged, it should land in our ERP.” It is not a weekly gain for someone who only logs hours. If that is not your day, the rest of RabbitWork stays the same.
The problem with asking the API over and over
Polling works until volume grows. Then it becomes delay (the ERP sits minutes behind), cost (a request for nothing), and a hole (someone turns the job off and nobody notices).
The other symptom is operational. The token the intern created last year still works. Nobody knows how many webhooks are active. A delivery fails and the detail disappears on a screen only a technician can find.
Anyone who has already connected a spreadsheet to Zapier recognizes the pattern: the automation “works” until the day the destination rejects it and the team finds out at close.
There is also the access risk. A token shared in Slack, a webhook pointing at a test environment nobody shut down, an old secret that still works. An integration without a single panel becomes debt — and integration debt shows up at the worst moment, when the invoice should already have gone out.
What was built
On the Ultimate plan, the admin registers the URL, chooses the events, and follows every delivery attempt — including when the destination rejects it. The steps are in how to use webhooks.
The same area holds API tokens, plan usage, and history. Creating, revoking, and seeing who still has access stops being a hunt across three menus. The path in the product: Settings > Integrations.
The delivery detail was left readable on purpose: payload, HTTP response, error. Whoever looks after the integration finds out faster why a send failed, without opening a ticket.
Integrations, webhooks, and API screen
Too many events become noise. The honest recommendation is the same as in help: choose only what that integration needs. An hour logged, a week changing status, whatever the ERP actually consumes.
Before and after for people who integrate
Before: a job asks every 15 minutes whether something changed. An orphan token. An invisible failure. Two screens for the same account.
After: the destination receives the POST the moment the hour comes in or the week changes status. The admin sees the limit and the history in the same panel. Revoking access is one click, not a search.
The person logging hours does not change the ritual. The effect is indirect: the system the team already uses updates on its own.
What this opens
An invoice that starts from an approved hour can be created in the ERP without exporting a CSV at month end. Slack or internal email can notify the approval queue. The data warehouse stops sitting a day behind.
Webhooks and the unified panel arrived in August 2026, in the same block as approval. The context is in the Changelog. Without Ultimate, the path is still export and the API on request.
If your operation already asks “when the hour comes in, the other system needs to know,” this is the place. It is worth seeing the panel in RabbitWork at rabbitwork.io.
