| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
Discuss (mail)
|
| Lines of code | 1996 |
| Technical Name |
eh_hero_base |
| License | OPL-1 |
| Website | https://www.erpheritage.com.au/ |
| Versions | 16.0 17.0 18.0 19.0 |
Employment Hero Connector Core
The transport and configuration layer every Employment Hero integration on Odoo 17 builds on.
Why this module
Employment Hero Connector Core
One transport, every Employment Hero API
Connection records carry base URL, credentials and rate budget per company. Sync jobs call an endpoint code and the connection owns auth, transport, rate limiting and logging, so no module writes its own HTTP client.
Endpoints are data, not code
Every API path is a registry record. The base catalogue ships with Payroll, HR platform and ATS endpoints, and integrators add their own from the interface with no upgrade. Pagination style is set per endpoint.
Encrypted secrets, redacting audit
OAuth tokens are encrypted at rest with Fernet and credential fields are restricted to system administrators. Every call is logged with credentials and known personal identifiers redacted, then garbage collected on a schedule.
Day in the life
A day with the connector core
An integrator adds a connection for a company, authorises the HR platform through the OAuth2 flow, and the token lands encrypted in the database. A nightly sync job in a domain module calls an endpoint code; the connection picks the right auth, spends one rate token from a cluster wide budget, follows pagination to the last page and logs each call with secrets stripped. A 429 or a 5xx is retried with backoff and jitter rather than hammering the API. When the access token nears expiry a single worker refreshes it under a lock so parallel jobs never race the rotating refresh token. The administrator opens the API log to read status, timing and a correlation id for any call, and old rows are purged on a weekly cron.
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 call can carry an idempotency key that is reused across every retry attempt and sent as an Idempotency-Key header, so a write resent after a timeout is deduplicated by the vendor instead of creating a second record.
Only transient failures are retried: 5xx, connection errors, timeouts and 429. Each retry waits exponential backoff plus random jitter, and a server Retry-After is honoured but clamped to five minutes so a hostile or buggy header cannot park a worker for hours.
A database backed token bucket meters one shared budget per rate group across all workers, against the database clock, so an N worker deployment does not multiply the configured rate into a 429 storm. A single worker host can opt back to the lighter in process bucket.
Token refresh locks the token row FOR UPDATE in an autonomous transaction and re checks expiry after the lock, so two workers never both POST the same rotating refresh token and a caller side rollback never discards tokens the vendor already rotated.
Each authorisation uses a per attempt PKCE verifier and CSRF state on its own row. The callback claims the flow with a single DELETE RETURNING by state, so a replayed or concurrent callback finds nothing and cannot redeem the code twice.
OData, page index and cursor styles each stop on a short or empty page or an exhausted cursor. If a hard page cap is hit instead of a natural end, the result is flagged with a loud warning rather than silently dropping records.
Stored tokens are tagged with the fingerprint of the key that sealed them, so a decrypt under the wrong key fails with an actionable message. A rotation helper re encrypts every token from the old key to the new one inside a savepoint, all or nothing.
A 2xx body that parses to plain text, such as an HTML maintenance or proxy page, is never yielded as a record. The page fails with a clear validation error instead of feeding garbage to a mapper.
What is inside
Built to do the job, end to end.
- Connection records. One record per link to an Employment Hero product API, scoped per company, with product (HR platform, Payroll, ATS), auth type, base URL, identifier, rate limit, timeout and retry count. A default per product and company is used when a job does not name one. A Test Connection action probes a per product endpoint and records the result.
- Three authentication schemes. API key HTTP Basic for the Payroll API, OAuth2 Bearer with PKCE and lazy plus proactive refresh for the HR platform, and a static configurable header token for the ATS recruitment API. The client never deals with token lifetimes; the connection supplies a valid token on demand.
- Data driven endpoint registry. Endpoints are records with method, path template, pagination style, item and cursor paths, page size and rate group. A base catalogue ships for all three product families and integrators add more from the interface. Path placeholders for business and organisation id are filled automatically.
- Resilient HTTP client. A standalone, database free transport with token bucket rate limiting, exponential backoff with jitter, transient only retry, Retry-After handling, per request timing and a pagination engine for OData, page index and cursor styles. One rate token is spent per logical call, not per retry.
- Encrypted tokens and key rotation. OAuth access and refresh tokens are encrypted at rest with Fernet, keyed from an environment variable or a generated system parameter, with key fingerprinting and an all or nothing rotation helper. There is no plaintext fallback: a missing crypto library is a hard error, not a silent downgrade.
- Redacting audit log and crons. Every request and response is recorded with status, duration and correlation id, with credentials and known personal and financial identifiers redacted from both structured and raw bodies. A weekly cron purges rows past a configurable retention horizon and a six hour cron refreshes tokens nearing expiry. A separate access log records deliberate reveals of sensitive fields.
Honest about the edges
What this does not do, so nothing surprises you.
- This is the transport and configuration core. It does not by itself sync HR records, map fields or run a job queue; the domain and sync engine modules do that on top of the services here.
- There are no inbound webhooks in this module. The only HTTP route is the OAuth2 redirect callback. Event ingestion and signature verification live in a separate suite module.
- Synchronisation is read oriented out of the box: the base catalogue ships read endpoints and the transport supports writes, but no two way sync, conflict resolution or change detection is implemented in this core.
- Client side rate limiting reduces 429 pressure but does not replace the vendor quota. It spaces and backs off requests; it cannot raise the limit the Employment Hero API enforces.
- OAuth2 authorisation requires the cryptography Python package and the requests library. Without cryptography the connector refuses to store a token rather than save it unencrypted.
- Endpoint and credential administration is intended for integrators and system administrators. Credential fields are restricted to the system group by design.
Employment Hero Odoo connector, Employment Hero API integration, KeyPay API Odoo, Employment Hero OAuth2, Odoo 17 HR integration, Employment Hero HR platform API, encrypted OAuth token storage Odoo, data driven API endpoint registry, Odoo rate limiting client, idempotency key API retry, Employment Hero ATS API, Odoo API audit log, Odoo Community connector core, PKCE OAuth 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.
Bring Employment Hero onboarding workflows, employee goals and contractor flags into Odoo Community as real recor...
End to end French B2B and B2G electronic invoicing for the DGFiP reform, generating Factur-X PDF/A-3 with embedde...
Accept ZainCash wallet payments in Iraq at your Odoo checkout, on the ZainCash Payment Gateway v2 with OAuth2, re...
Sync Employment Hero ATS recruitment job openings into the standard Odoo Recruitment app, mapping each opening on...
The Singapore country pack for the ERP Heritage Employment Hero integration
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
Discuss (mail)
|
| Lines of code | 1996 |
| Technical Name |
eh_hero_base |
| 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