Employment Hero Webhook Receiver
Verify, dedupe, and route inbound Employment Hero webhooks into your sync queue without ever blocking the delivery.
Store price is USD 132 all-in: installing this also pulls the 3 paid ERP Heritage modules it depends on.
Why this module
Employment Hero Webhook Receiver
Verified before anything is written
Each delivery is checked against the connection secret with a constant-time HMAC SHA-256 comparison. A mis-signed or unsigned event returns 401 and creates no row, so the public endpoint cannot be turned into a flood of junk events. The secret is encrypted at rest and gated to system administrators.
A duplicate or a slow sync never breaks delivery
Events are unique on connection and external event id at the database level, so a replayed delivery is acknowledged and ignored. Verified work is handed to the queue, so the endpoint returns fast. A failing dispatch retries, then dead-letters with a chatter message and a To Do activity on the connection.
Fetch the one record that changed
When a subscription names the path to the changed entity id and the job has a detail endpoint, dispatch pulls just that record. A retry re-fetches the single record, never re-paginating the whole list. Same-entity deliveries are queued on a per-entity ordered channel so they process in order.
Day in the life
An employee update arrives while a nightly sync is still running.
Employment Hero posts an employee.updated event to the connection endpoint. The receiver verifies the HMAC signature in constant time, confirms it has not seen this external event id before, records the event, and returns 200 in milliseconds while the queue takes over. The subscription for that event type names data.id as the changed entity, so dispatch fetches only that one employee from the detail endpoint and maps it, while the connection's updated_at path stops an out-of-order delivery from overwriting a newer record. The detail call briefly fails, so the queue retries the single targeted fetch rather than re-pulling the whole employee list. The second attempt succeeds, the event is marked processed, and the nightly sync was never blocked.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
A duplicate delivery is caught two ways: a pre-check by connection and external event id, and a database uniqueness constraint behind a savepoint that answers 200 idempotently even when two deliveries race to create the same event.
An unsigned or mis-signed POST is rejected with a 401 before any write. Verification happens before create, so the public endpoint cannot be used to flood the event table, and the rejection is logged rather than stored.
A dispatch whose downstream sync fails raises rather than being marked done, so the queue records the failure and runs its retry and dead-letter machinery instead of swallowing the error.
A poison delivery that exhausts its retries posts a chatter message and raises a To Do activity on the connection, so a failed event surfaces to an administrator instead of vanishing silently.
When a subscription names the changed entity id path and the job has a detail endpoint, dispatch fetches only that record, and a retry re-fetches the single record rather than re-paginating the entire list.
When the connection declares a webhook entity path, deliveries for one record are queued on a per-entity ordered channel so they process in order and never concurrently. Config validation refuses targeting unless the connection ordering path matches.
An active subscription is refused at config time unless its sync job tracks an updated-at timestamp, so an out-of-order webhook delivery cannot overwrite a newer record.
An event type marked as a delete archives or unlinks the linked record without calling the detail endpoint, and a detail 404 for a targeted record is treated as a clean deletion rather than a failure or dead-letter.
The body is capped at one megabyte by the declared content length and the actual bytes before reading or hashing, so a hostile sender cannot make the worker buffer and HMAC an unbounded payload.
Each event carries the company of its connection through a stored related field, and subscriptions belong to a company, so webhook traffic stays scoped per company.
What is inside
Built to do the job, end to end.
- Inbound endpoint with token routing. A public route at /eh_hero/webhook/<token> resolves the connection by its random path token and returns 404 for an unknown token. It always returns a response and never leaks a traceback to the sender, answering with a 500 on any unexpected error.
- Per-connection identity, encrypted secret. A button generates a fresh path token and a secret, and shows the full webhook URL to copy into Employment Hero. The secret is encrypted at rest, decrypted only for system administrators, with a shipped migration that encrypts any legacy plaintext secret and drops the old column.
- Event log and subscriptions. Every verified delivery is recorded with its type, external id, signature result, payload, and processed flag for a full audit trail. Subscriptions map an event type to a sync job, can be scoped to one connection or left global, and can be disabled without deletion.
- Queue-decoupled dispatch. Verified events are enqueued for the drain to dispatch, so the HTTP endpoint returns quickly. Dispatch runs the subscribed sync jobs through the synchronisation orchestrator and propagates real failures so the queue can retry and dead-letter them.
Honest about the edges
What this does not do, so nothing surprises you.
- Inbound only. This module receives Employment Hero webhooks and drives pull synchronisation. It does not push data back to Employment Hero and does not send outbound webhooks.
- Not two-way sync. There is no bidirectional reconciliation and no field-level merge. Out-of-order deliveries are guarded by a stale-overwrite timestamp check, not by conflict resolution.
- Requires the rest of the suite. It depends on the Employment Hero base, sync, and queue modules, and uses their connection, sync jobs, mappings, orchestrator, and asynchronous queue to do its work.
- Signature scheme is HMAC SHA-256 over the raw body, read from the Employment Hero signature header or a fallback signature header. A provider that signs differently would need the verification adapted.
- The actual data mapping and field synchronisation are performed by the sync jobs you configure in the sync module. This module verifies, dedupes, routes, and orders deliveries. It does not define the mappings itself.
- Bodies larger than one megabyte are rejected with a 413 before processing.
Employment Hero webhook Odoo, Odoo 17 webhook receiver, HMAC signature verification Odoo, Employment Hero integration Odoo 17, inbound webhook Odoo Community, webhook replay protection, idempotent webhook handler Odoo, Employment Hero sync queue, Odoo webhook retry dead letter, Employment Hero employee sync, Odoo HR integration webhook, real-time HR sync Odoo
Need this fitted to the way you work?
ERP Heritage delivers end to end Odoo work: Odoo Implementation, Customization and Development, Integration, Migration, Consultation, Support and Training. We help teams put this module into production, shape it to their process, and keep it running.
We work with businesses across Australia (Melbourne, Sydney, Brisbane, Perth, Adelaide, Canberra) and the Middle East (Dubai, Abu Dhabi, Riyadh, Jeddah, Doha, Kuwait City, Muscat). Start a conversation at erpheritage.com.au or email info@erpheritage.com.au.
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Modules teams pair with this one.
Premium ERP Heritage modules that extend the same stack, each built to the same engineering bar.
Sync attendance clock events from the Employment Hero people platform into the stock Odoo Attendances app, keyed...
The Singapore country pack for the ERP Heritage Employment Hero integration
The complete ERP Heritage Employment Hero integration in one install
Sync timesheet entries from the Employment Hero people and payroll platform into the standard Odoo Timesheets app...
Real-time fiscalisation of customer invoices and credit notes with the Mauritius Revenue Authority e-Invoicing (E...
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
Discuss (mail)
|
| Community Apps Dependencies | Show |
| Lines of code | 4465 |
| Technical Name |
eh_hero_webhook |
| License | OPL-1 |
| Website | https://www.erpheritage.com.au/ |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module