| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
Discuss (mail)
|
| Lines of code | 1974 |
| 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 credential layer every Employment Hero integration module is built on, configured as data, not code.
Why this module
Employment Hero Connector Core
One transport, every module
Install any Employment Hero domain module and this core installs with it. Every sync job calls one connection surface, so no module reinvents the HTTP client, token refresh or call logging. The hard transport problems are solved once.
Endpoints as data, not code
Every API path is a registry record with its own method, path template, pagination style and rate group. A new endpoint is a configuration row you add from the user interface, callable at once, with no module upgrade and no deployment.
Built for a real API under load
Client side rate limiting that can meter one budget across every worker, retry of transient failures only with backoff and jitter, honoured Retry-After, and idempotency keys so a retried write never doubles a record. Tokens encrypted at rest, credentials admin only.
Day in the life
A connection that just works the morning after
An administrator creates one connection for the HR platform, completes the OAuth2 authorisation in a browser tab, and the access and refresh tokens land encrypted in the database. A scheduled job refreshes the token before it expires, so the first sync of the day never stalls on an authorisation prompt. When the vendor throttles a busy pull, the limiter spaces the calls and the retry logic backs off rather than hammering the API into a 429 storm. If a key is ever questioned, the audit log shows every call with its status, timing and correlation id, and the credentials were never written to it. Nobody touches Python to add the next endpoint.
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 write can carry an Idempotency-Key header that is reused across every retry of the same call, so a create that is resent after a timeout is deduplicated by the vendor and returns the first result instead of producing a second record.
Only transient failures retry, the 5xx, timeout, connection and 429 cases. Each retry waits an exponential interval with random jitter, and a server supplied Retry-After is honoured but clamped so a hostile or buggy header cannot park a worker for hours.
The default rate limiter is backed by a shared database row per rate group, refilled against the database clock, so a deployment with many workers honours one cluster wide budget rather than multiplying the configured rate by the worker count.
When the budget cannot be met within the maximum wait, the limiter refuses to send and raises a retryable rate limit error rather than adding to the very 429 storm it exists to prevent, leaving the caller to back off and try later.
OData skip and top, one based page index, and follow the cursor token are all driven from the endpoint record, with the item list and next cursor read from a dotted path into the response envelope. A page cap is enforced and logged loudly so truncated results are never returned silently.
Concurrent callers that find an expired token do not each post the same refresh token. The token row is locked for update in an autonomous transaction, the expiry is re-checked after the lock, and the rotated tokens are committed independently of the caller, so a rollback never discards tokens the vendor already rotated.
Each authorisation attempt is its own row carrying a CSRF state and a PKCE verifier, and the callback claims it with a single delete returning, so a replayed or concurrent callback with the same state finds nothing and cannot redeem the code a second time.
Credentials and personal identifiers such as tax file, national insurance, bank account, super and medicare numbers are redacted by key and by substring, and bearer or basic tokens inside a raw string body are stripped, before any log row is written.
When the encryption key changes, tokens sealed under the previous key are re-encrypted in one atomic call that runs inside a savepoint, so the store is never left split across two keys, and a fingerprint on each value detects a mismatch with a clear, actionable error.
Connections and logs are isolated per company by record rule, while the shared endpoint catalogue is global, so one Odoo database can hold several Employment Hero connections side by side without leaking one company's calls into another.
What is inside
Built to do the job, end to end.
- Connection model. One record per link to an Employment Hero product API, scoped per company, with base URL, credentials, rate budget, timeout, retry count, a test connection button and a per connection call log. A default per product and company is used by jobs that do not name one.
- Three authentication schemes. HTTP Basic with the API key for the Payroll and KeyPay API, OAuth2 Bearer with PKCE and automatic refresh for the HR platform, and a static configurable header token for the recruitment ATS API, all behind one call surface.
- Endpoint registry. Every API path is a record with method, path template, rate group and pagination configuration. A shipped base catalogue covers common payroll and HR resources, and integrators add their own from the user interface with no code change.
- Resilient HTTP transport. A reusable client with token bucket rate limiting, exponential backoff with jitter, retry of transient failures and 429 only, honoured and capped Retry-After, per request timing, and optional idempotency keys for safe write retries.
- Encrypted token storage. OAuth2 access and refresh tokens encrypted with Fernet at rest, keyed from an environment variable or a generated system parameter, fingerprinted to catch a key mismatch, with a one call key rotation helper. Credentials restricted to system administrators.
- Audit and PII logging. An API audit log of every call with status, timing and correlation id, redacting credentials and personal identifiers before storage and trimmed on a schedule, plus a separate append only log for deliberate reveals of sensitive fields.
- Scheduled jobs. A cron that proactively refreshes OAuth tokens nearing expiry so a sync never stalls on a lapsed token, and a cron that purges API log rows past a configurable retention horizon.
- Security model. User, manager and administrator groups, multi company record rules isolating connections and logs, credential fields gated to the system group, and a PII access log that ordinary users cannot edit or delete.
Honest about the edges
What this does not do, so nothing surprises you.
- This is a transport and configuration foundation. It does not by itself import or sync HR records, leave, attendance, timesheets or pay runs; the domain modules in the suite do that on top of the services it exposes.
- It does not provide webhook receivers, HMAC signature verification, two way write back, conflict resolution or field mapping. Those concerns live in other modules of the suite, not in this core.
- Data movement is read oriented transport. The client can issue any HTTP method an endpoint defines, but this module ships read endpoints and the machinery to call them, not opinionated write or upsert logic.
- OAuth2 authorisation requires the integration to be registered with Employment Hero so you hold a client id and secret, and the Payroll and ATS connections require their respective API key or token. This module does not issue credentials.
- The cross worker rate limiter and proactive token refresh assume Odoo cron and a normal multi worker or single worker deployment; they are not a substitute for a message broker on very high volume integrations.
- The cryptography Python package is required so tokens are genuinely encrypted at rest. Without it the module refuses to store a token rather than downgrade it to plaintext.
- Targeted at Odoo 16 Community. The same code base also runs on Odoo 17, 18 and 19.
Employment Hero connector Odoo, Employment Hero API integration, KeyPay API Odoo, Odoo 16 HR integration, OAuth2 token refresh Odoo, encrypted API credentials Odoo, REST API endpoint registry, client side rate limiting, API audit log Odoo, Employment Hero Odoo Community, idempotent API retry, multi company connector 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 | 1974 |
| 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