Integrations
No rip-and-replace. HumanR plugs into what you already run.
Terminals on every site, workbooks HR has kept for years, an accounting system finance will not be changing, and a group chat where the work actually gets chased. This page lists every one of those connections by direction — what comes in, and what goes out.
Comes in
Goes out
Data in
What your operation already produces
Two things exist before HumanR does: the punches coming off your terminals, and the workbooks your HR team has been keeping for years. Both come in as they are — and once you are running, a token-authenticated endpoint lets your own systems read and feed it directly.
ZKTeco biometric terminals
Devices speaking the iClock/ADMS push protocol connect straight to HumanR and stream fingerprint, face and card punches in as they happen — every terminal on every site, without middleware, a polling agent or somebody walking a USB stick to the office. Each device is registered by serial number before it is accepted.
How it works →Your existing Excel and CSV registers
We bring these across for you during initial setup: our importer reads the employee registers, salary sheets and document trackers you already maintain, matches them against what is in the system, and produces a validation report naming exactly what was imported, matched and flagged. The workbook can stay alive in parallel while the team switches over.
How it works →Your own systems, over the REST API
A versioned /api/v1 surface your code calls with a bearer token: read employees, attendance days, leave requests, review cycles and goals, and the reference lists — and post attendance punches in from a time system that speaks nothing but HTTP. Tokens are shown once, stored hashed, and can never carry a permission the admin who issued them did not already hold.
How it works →Payroll out
Into the accounting system finance already runs
Every finalized run becomes a balanced journal against your own chart of accounts. Two ways it gets there: posted directly over the accounting system's API, or written as a file in that system's own import format. Same mapping behind both.
QuickBooks Online — posted directly
Connect a QuickBooks company once and journals post over its API with no file in between. You map to its live chart of accounts rather than typing codes from memory, and a retried export finds the journal it already posted instead of posting a second one.
How it works →SUN, SAP, iScala, Dynamics NAV and Sage 300 — as a journal file
Each gets an import file in its own format, plus generic CSV and Excel for anything not on that list. A run is validated against the mapping first: unmapped components and out-of-balance journals stop the export and are named, because a file that imports wrong is worse than no file.
How it works →Your banks
The net-payable list exports grouped by bank and by currency — the shape the transfers are actually submitted in — with held salaries listed separately so the total tallies with what leaves the account.
How it works →Running something that isn't on this list? Most systems will still take a journal — the generic CSV and Excel formats are deliberately plain, and a system's own format is a mapping exercise rather than a rebuild. Tell us which one and we'll say honestly whether it's a week's work or a quarter's. Ask us.
Events out
The moment something happens, not the next time someone looks
Webhooks push HumanR's own events to wherever your team already watches. Slack and Teams need no code — paste an incoming-webhook URL and tick the events. Anything else receives a signed JSON POST, which is what makes Zapier, Make, n8n or your own service a receiver without us building anything specific for it.
Slack and Microsoft Teams
Events arrive as readable cards in the channel the work actually gets chased in. Setup is a paste and a set of checkboxes: the incoming-webhook URL is the only credential, and there is nothing to install from an app directory — both platforms accept a plain incoming webhook, which is exactly what HumanR sends.
How it works →Signed webhooks into your own systems
A canonical JSON envelope signed with HMAC-SHA256, so your receiver can prove the event came from HumanR. Every event carries a stable id that survives retries, so duplicates are safe to drop, and failed deliveries back off — a minute, five, thirty, then hours — rather than hammering you.
How it works →The events you can subscribe to
Payroll runs finalizing and reopening, every approval decision across all ten request types, and documents, work permits, contracts and probations approaching expiry. Subscribe to one event, a family like approval.*, or everything — and scope an endpoint to a single company if you run several.
How it works →Everything else out
Files, mail and the data you own
The unglamorous half of integration: getting data out in a form something else can read, and getting mail delivered through infrastructure you control.
CSV and Excel from every list
Every list in the system — filtered, sorted, exactly as it looks on screen — exports to a file. Sensitive columns are dropped for anyone without clearance to see them, and the export itself is recorded in the audit trail.
How it works →Your own mail server
Notifications, expiry digests and portal mail go out through your SMTP host, from your domain, so employees see mail from their employer and not from a vendor. Leave it unconfigured and mail is logged rather than sent — useful for a pilot that should not email anyone yet.
Reports as a data source
Payroll summaries, export logs, attendance rollups and headcount reports are all queryable and all exportable, so the numbers that go into a board pack or a group consolidation come out of the system rather than out of somebody's re-typing.
How it works →Three different things people call “an integration”
These get used interchangeably on vendor websites and they are not the same mechanism. Which one you want depends on what has to happen, and when.
| Mechanism | When it fires | How it works | Who asks for it |
|---|---|---|---|
| GL export | Once a month, when a payroll run is finalized | Someone finalizes the run and exports. Journals post into QuickBooks over its API, or download as a file for SUN, SAP, iScala, NAV or Sage. | Finance |
| Webhooks | The instant an event happens, with nobody watching | HumanR POSTs a signed JSON event to a URL you configure, and retries if you are down. Slack and Teams get formatted cards instead. | Ops, IT, whoever owns the channel |
| Exports and imports | Whenever a human needs the data somewhere else | Any list out to CSV or Excel; existing registers and salary sheets brought in for you during setup. | Everyone |
Integration questions
Including the ones with a "not yet" for an answer — we would rather you read it here than find out on a call.
Does HumanR integrate with QuickBooks?
Yes, directly over its API. Connect a QuickBooks Online company once, map your pay components to accounts picked from its live chart of accounts, and finalized payroll runs post as balanced journals with no file in between. A retried export finds the journal it already posted rather than duplicating it.
Which biometric devices work with it?
ZKTeco terminals speaking the iClock/ADMS push protocol — fingerprint, face and card. The device pushes punches to HumanR as they happen rather than being polled, so a site with a flaky link catches up on its own once the link returns. Devices are registered by serial number before their data is accepted.
Can payroll and HR events go into our Slack or Teams channel?
Yes, and it takes about a minute. Paste the channel's incoming-webhook URL, tick the events you want — payroll finalized, approvals decided, permits and documents expiring — and cards start arriving. No developer, and nothing to install from an app directory.
What's the difference between the GL export and webhooks?
Timing and audience. The GL export is a monthly, human-triggered push of payroll totals into your accounting system. Webhooks are automatic and immediate: the instant a run is finalized or a permit is 30 days from expiring, an event lands in the channel or system you pointed at it. Finance wants the first; operations and IT want the second.
Does HumanR have a public API?
Yes — a versioned REST API your own code calls with a bearer token. It reads employees, attendance days, leave requests, performance cycles, reviews and goals, and the reference lists (companies, departments, designations, work sites), and accepts attendance punches as a write. Tokens are displayed once at issue and stored only as a hash, so nobody — us included — can read one back out of the database, and a token can never carry a permission the admin who issued it did not already hold themselves. Every issue and revoke is audited by the token's prefix, never its hash. Two honest qualifiers: the API is a per-tenant switch rather than something every install carries, so it is turned on for your instance rather than found by scanning, and it is not yet a full write surface — punches go in, but employee and leave records are read-only today.
Can another system push data into HumanR?
Yes, two ways. Biometric terminals push punches in over the iClock/ADMS protocol they already speak, and any system that can make an HTTP request can post punches to the REST API with a bearer token. What still does not exist is an inbound webhook — there is no endpoint you register with a third party so it can notify us of its own events. Bulk data is still an import rather than a live feed, so a nightly sync from another HR or finance system is a scheduled workbook import today.
Do you support single sign-on?
Not yet. Accounts use passwords stored hashed, with a live list of every session that can be signed out remotely, and employee portal resets are done by HR in person rather than by an emailed link. SSO and two-factor are both roadmap items, and this answer changes the day either ships rather than the day we decide to imply it.
Can we get our data out if we leave?
Yes. Every list in the system exports to CSV or Excel, reports are exportable, and self-hosted installs hold their own database. There are no export fees and no formats designed to be hard to read elsewhere.
Need something that isn't here?
Tell us the system and what has to move between it and HumanR, and we'll say honestly whether it already works, whether it is a mapping exercise, or whether it is a real build. Get in touch — or see the security page for how any of this is protected in transit.
See the connectors running on real data
Request a demo and we'll email you a personal login to a fully loaded demo company — explore real screens with realistic data within minutes.
No credit card. No sales call required. A real login, emailed to you.