REST API
Your own code, reading HumanR and feeding it — over a token, not a database password
A versioned REST API your systems call 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 and stored hashed, and a token can never carry a permission the admin who issued it did not already hold.
See it live — demo in minutes →Sound familiar?
The only way to get data out is somebody exporting a file and emailing it
A time system or a kiosk can produce punches, but there is nowhere to send them
The alternative on the table is handing an integrator a database password
The credential in that script has been there for two years and nobody knows who issued it
Capabilities
What you get
10 capabilities
A token that cannot exceed the person who issued it
Scopes are chosen from what the issuing admin already holds, so a token is a narrowed copy of an existing operator's reach and never a way around it. Grant a token attendance-read only and that is precisely what it can do — the same permission checks the web app runs apply unchanged behind the endpoint.
Shown once, stored hashed
The raw token appears on screen exactly once, at issue. Only its hash is kept, so nobody — including us — can read a token back out of the database. A lost token is revoked and re-issued rather than recovered, which is the correct behaviour and the reason this is worth saying out loud.
Issued and revoked on the record
Every issue and revoke is written to the audit trail by the token's short prefix, never its hash, so a year later you can still answer who created the credential now sitting in someone's script — without the log itself becoming a place credentials leak.
Read employees, attendance, leave, performance and reference data
Employee lists and single records, attendance days with first-in, last-out and punch counts, leave requests, review cycles with the reviews and goals under them, and the reference lists behind every dropdown — companies, departments, designations and work sites. Paged, filtered, and capped so no one request can drag the whole table.
Push attendance punches in
A batch of punches posted from any system that can make an HTTP request. Idempotent on employee and timestamp, so re-sending after a timeout stores nothing twice, and a batch mixing good and unresolvable rows still lands the good ones and hands the rest back for correction — no all-or-nothing failures on a nightly sync.
Company boundaries a token cannot argue with
Scope a token to one company and every query is filtered to it before any request parameter is read. A caller asking for another company's rows gets its own company's rows, not an error and not somebody else's data.
Sensitive fields stay behind their own permissions
Salary and personal identifiers are masked in API responses unless the token carries the sensitive-data scope, exactly as they are in the interface. There is no back door where the API returns more than the same user would see on screen.
Documented and explorable
A generated OpenAPI document and an interactive explorer live behind the same login as the rest of the app, so an integrator can read every endpoint, parameter and response shape and try a call against your own data instead of working from a PDF.
Rate-limited per token
Each token gets its own per-minute budget rather than sharing a global pool, so one integrator's ingest loop cannot starve another's, and the cap is a config value your install can tune.
Absent unless you asked for it
The API is a per-tenant switch. With it off, every route — the endpoints, the docs and the token screen alike — answers 404 rather than 403, so an instance that has not enabled it looks to a scanner exactly like one where the feature does not exist.
Whatever can make an HTTP request
There is no connector to build and no SDK to adopt: the API is plain JSON over HTTPS with a bearer token, which every language, every automation platform and most time-and-access systems can already speak.
Straight from the product
Real screens from the demo company — the same system your login opens.
Works best with
Webhooks & Event Streaming
When payroll finalizes or a permit's about to expire, your other systems hear about it — automatically
Explore →Biometric Attendance & Overtime
Punches flow in from your devices — timesheets build themselves
Explore →Search, Filter & Export
Your Excel reflexes, upgraded — filter any list, shape it, take it with you
Explore →Questions
What can the API write?
Attendance punches, and only attendance punches. Everything else is read-only today: employees, attendance days, leave requests, performance cycles, reviews and goals, and the reference lists all come out, but nothing goes in. That is a deliberate stopping point rather than an oversight — punch ingestion is the write that unblocks real integrations, and creating employees or approving leave over an API needs the same approval and audit semantics the interface enforces, which we would rather build properly than quickly.
How is this different from webhooks?
Opposite directions, and most integrations want both. Webhooks are HumanR pushing to you the moment something happens — a payroll run finalizes, a permit is weeks from expiring — with no polling. The API is your code pulling on its own schedule, or pushing punches in. A typical setup subscribes to the events it cares about and calls the API to fetch the detail behind them.
Is it safe to give a vendor a token?
Safer than the alternative that usually gets proposed, which is a database login. A token carries only the scopes you tick, can be pinned to a single company, expires on a date you set, is rate-limited on its own, and is revocable in one click without disturbing anyone else's integration. And because it can never exceed the permissions of the admin who issued it, the blast radius of a leaked token is bounded by a person you can name.
Jionee mwenyewe kwa data inayofanana na yako
Omba demo na tutakutumia kwa barua pepe akaunti yako binafsi ya kuingia katika kampuni ya mfano iliyojaa data — chunguza skrini halisi zenye data ya kweli ndani ya dakika chache.
Hakuna kadi ya mkopo. Hakuna simu ya mauzo. Akaunti halisi ya kuingia, inayotumwa kwa barua pepe.