Employment Hero Webhook Receiver
Verify, dedupe, and route inbound people-platform webhooks into background sync jobs, safely and out of band.
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 it touches anything
Every delivery is checked against the connection secret with a constant-time HMAC SHA-256 comparison before a single row is written. The endpoint is public, so an unsigned or mis-signed POST is rejected with a 401 and logged, never recorded and never acted on. The secret is encrypted at rest and readable only by system administrators.
A duplicate delivery is a no-op
Events are keyed by connection and external event id, enforced both by a pre-check and a database unique constraint, with a savepoint to settle concurrent deliveries that race to create the same row. A repeat or replayed delivery is acknowledged with 200 and ignored, so a platform retry never double-applies.
The endpoint answers in milliseconds
A verified event is recorded and parked on the asynchronous queue, then dispatched to its subscribed sync job by the drain. The HTTP handler returns 200 immediately, so a slow downstream sync never blocks delivery, and a failed dispatch retries with exponential backoff and dead-letters with an alert rather than vanishing.
Day in the life
An employee record changes upstream and lands in Odoo without a poll.
Someone updates an employee in the Employment Hero platform. A webhook hits the per connection URL, and the receiver verifies the HMAC SHA-256 signature in constant time before writing anything. The delivery is new, so it is recorded and queued, and the endpoint returns 200 in milliseconds. The drain picks it up, matches the subscription for that event type, and because the subscription names the path to the changed record, it fetches just that one employee from the detail endpoint instead of re-pulling the whole list. The stale-overwrite guard compares the source timestamp so an out-of-order delivery cannot clobber a newer record, and the per entity ordered channel keeps two deliveries for the same person from racing. The mapping writes the change into Odoo. A second, replayed copy of the same webhook arrives moments later, is recognised by its external event id, and is acknowledged and dropped. Nothing double-applies, nothing blocks, and if the downstream sync had failed it would have retried with backoff and raised a To Do on the connection rather than going quiet.
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 on connection plus external event id, and a database unique constraint behind it. Concurrent duplicates that both pass the pre-check race into a savepoint, the constraint catches the loser, and the endpoint answers 200 duplicate either way. The same webhook delivered twice applies once.
Verification uses a constant-time HMAC SHA-256 comparison and runs before any write. A missing secret or missing signature is always invalid. An unsigned or mis-signed POST is rejected with 401 and logged, so the public endpoint cannot be used to flood the event table with junk rows.
A dispatch whose downstream sync fails raises rather than being marked done, so the queue records the failure and retries with exponential backoff up to the configured limit. After the last attempt the job dead-letters and posts a chatter message plus a To Do activity on the connection, so a poison delivery is visible instead of silently dropped.
When the connection declares where the changed entity id sits, deliveries for one record are queued on a per entity ordered channel and processed strictly in arrival order, one at a time, while unrelated entities stay parallel. Two updates for the same employee can never be applied concurrently or out of order.
A subscription can name the path to the changed record id. The dispatch then fetches just that one entity from the detail endpoint, and a retry re-fetches the same single record rather than re-paginating the entire list endpoint. Cheaper deliveries and retries that stay cheap.
A delete event type archives or unlinks the linked Odoo record without any API call, and a detail 404 on a targeted fetch is treated as an upstream deletion. A delete for an entity that was never synced locally is a clean skip, not a failure and not a dead letter.
An active subscription must use a sync job that tracks a source timestamp, refused at save time if it does not, so an out-of-order delivery cannot overwrite a newer record. When targeting is set, the targeting path and the connection ordering path are forced to agree, so the ordering key and the targeted id are always the same value.
What is inside
Built to do the job, end to end.
- Per connection endpoint, secret, and URL. Each connection generates a random path token and a shared secret from the user interface, and exposes the ready-made webhook URL to paste into the people platform. The secret is encrypted at rest and gated to system administrators, matching the rest of the credential surface.
- Recorded event log with audit trail. Every verified delivery is stored with its event type, external event id, received timestamp, signature-valid flag, raw JSON payload, and processed state, scoped to the owning company. The log is the audit trail for what arrived and what was done with it.
- Subscriptions: event type to sync job. A subscription binds an Employment Hero event type to a sync job, scoped to one connection or left global to match any. Optional fields name the path to the changed entity id for targeted fetch, the event types that mean a delete, and an active toggle to disable a route without deleting it.
- Queue-backed dispatch with backoff. Dispatch runs through the asynchronous queue from the companion queue module: ordered or shared channels, exponential backoff retry up to a configurable limit, and a dead-letter state with an administrator alert when retries are exhausted.
- Multi-company aware. Events carry the owning company from their connection, subscriptions belong to a company, and record rules scope the data, so a multi-company database keeps each company's webhook traffic and routing separate.
- Tested and migration-safe. Ships with unit and full HTTP end-to-end tests covering signature verification, replay, routing, targeted fetch, delete handling, ordering constraints, and dead-letter alerting. A shipped migration encrypts any legacy plaintext secret and drops the old column.
Honest about the edges
What this does not do, so nothing surprises you.
- This is an inbound receiver only. It accepts and routes webhooks from the people platform into Odoo. It does not send outbound webhooks and it is not a two-way sync engine.
- It does not register or subscribe webhooks on the platform side for you. You generate the URL and secret here and configure them in the Employment Hero platform yourself.
- It routes verified events to synchronisation jobs but does not itself map or write business records. The actual field mapping and record sync live in the companion sync module it depends on.
- Asynchronous dispatch, retry, and dead-lettering depend on the companion queue module and its drain running on a schedule, which must be enabled for events to be processed.
- Signature verification expects an HMAC SHA-256 hex digest over the raw request body, read from the Employment Hero signature header. Other signature schemes are not configurable.
- Targeted single-record fetch and clean delete handling apply when a subscription declares the entity id path and the sync job exposes a detail endpoint. Without those, a matching event runs the job's normal list sync.
- Requires the Employment Hero base, sync, and queue modules from this suite. It is not a standalone connector and does not include platform credentials.
Employment Hero webhook Odoo, Odoo 19 HR webhook receiver, HMAC SHA-256 webhook verification, idempotent webhook replay protection, webhook event routing Odoo, queue retry dead letter Odoo, near real time HR sync Odoo, per entity webhook ordering, targeted single record fetch, multi company webhook Odoo Community
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