Skip to content
ZivoHR

Interface style

Colour scheme

Integrations

Five connections,
described honestly.

There is no marketplace here and no logo wall. There is single sign-on, there is Slack, there are attendance devices, there is the API the product itself is built on, and there is email. Each one is written up below with the part that usually goes wrong.

Single sign-on

OpenID Connect against Okta, Microsoft Entra ID or any OpenID provider. On the web and on the phone.

Slack

Installed per workspace over OAuth. Every notification arrives as a DM, plus a week-ahead note on Monday morning.

Biometric devices

eSSL and ZKTeco readers push punches over ADMS as they happen. No midnight CSV export, no re-key.

API and MCP

Every feature is a JSON API the web and mobile apps both use. Ziva is also served as an MCP server.

Transactional email

Templated, version-controlled and rendered from the app, so what an employee receives is in the repository.

Single sign-on

People sign in with the account IT already manages.

SSO is OpenID Connect, configured per workspace with Okta, Microsoft Entra ID or any OpenID provider. It signs in people who already have an employee record, matched on work email, and refuses everyone else rather than creating an account for them.

How SSO is enforced
OktaMicrosoft Entra IDOther OpenID providerMobile sign-inRefusal logAdoption list

Rolling it out

  1. 1Connect the providerIssuer, client ID and a client secret that is encrypted and never shown again.
  2. 2Someone signs in for realPassword sign-in cannot be switched off until one SSO sign-in has succeeded on the workspace.
  3. 3Watch who has not come throughA list of linked people who have never used SSO, and the last twenty refusals with their reasons.
  4. 4Switch passwords offOwners keep an audited break-glass password. Everyone else signs in through the provider.

SAML and SCIM provisioning are not supported today.

Slack

The notification goes where people already look.

Slack is installed per workspace over OAuth. Once a person's Slack account is linked to their employee record, every notification they would see in ZivoHR also arrives as a direct message, with a link back to the record it is about. Approving still happens in ZivoHR, one click from the message.

  • A week-ahead note on MondayAt 07:00 in each office's own timezone: the holidays coming up, your leave, and who on your team is out. Skipped on a quiet week, so it never becomes noise.
  • Bulk linking, approved by HRZivoHR proposes matches between Slack members and employees; HR approves the pairs it trusts. People can also link themselves from a single page.
Leave decisionsExpense decisionsPayslip readyAnnouncementsBirthdays and anniversariesMonday digest
The Slack integration panel under workspace Settings: an Add to Slack button and the scopes it requests, im:history, im:write, chat:write, users:read and users:read.email.The Slack integration panel under workspace Settings: an Add to Slack button and the scopes it requests, im:history, im:write, chat:write, users:read and users:read.email.

The security posture, plainly

  • The OAuth state is single-useA state value is accepted once and then it is spent. Replaying an install callback does not get a second bite at binding a workspace.
  • A rebind drops the identity mapReinstalling against a different Slack workspace does not inherit the old map of Slack user to employee. It is discarded and rebuilt.
  • Why that mattersInherited identity maps are how one employee ends up reading another's payslip: the account changed underneath, the mapping did not, and the bot happily answered as the wrong person.

Biometric devices

The punch arrives when it happens.

Attendance hardware usually ends its life as a laptop in the corner of an office, running an export at midnight that somebody uploads the next morning. eSSL and ZKTeco readers here push punches over the ADMS protocol straight into the same timeline the mobile app and the web app write to.

One timeline, four sources

Device, mobile, web and a manual correction all land in the same record, tagged with where they came from. The shift engine reads one list, not four exports it has to reconcile.

Learn more

Registered per location

A device belongs to a location in the org, with a role such as entry door. Its punches are scoped to the right site and the right workspace before anyone looks at them.

Unknown devices are quarantined

ADMS identifies a reader by the serial printed on it, which is a weak credential and we say so. A serial we have never seen lands as pending, its punches held until a person approves it, and an approved device can require a comm key as well.

Geofences drawn on a map

Each office's check-in circle is set in a Google Maps editor with address search, 200 m by default. Without a Maps key the same editor runs on OpenStreetMap.

Learn more

A request, in full

acme.zivohr.com
GET/api/v1/employees/?department=design&status=active
Host:acme.zivohr.com
Authorization:Bearer <scoped token>

The host is the tenancy. The token carries a tenant claim and a scope. Present it against another workspace's host and it fails — there is no query parameter that changes which company you are reading.

API and MCP

The product is a client of its own API.

Every feature you see in the web app is a JSON endpoint first. The React app and the Flutter app are two clients of the same surface, which is the only durable way to promise an API is complete: we would notice immediately if it were not.

  • Tokens are scope-narrowedA machine token carries the scopes it needs. An endpoint has to opt in to accept one, so a narrow token that leaks buys nothing beyond the job it was minted for.
  • Ziva, as an MCP serverThe assistant's tools are served over the Model Context Protocol, which is how Ziva answers in Slack. The caller gets an MCP-scoped token, and the tools still only read the person's own record.
  • The same permissions as a personAn API caller is subject to the same permission codes and the same row scoping. There is no service account that quietly sees everything.

Email, tenancy, and what is not here

What an integrator needs to know before writing anything.

Two facts shape every integration against ZivoHR: mail is rendered by the application, and a workspace is addressed by its subdomain. Neither is exotic, but both decide how your side is built.

Transactional mail is in the repository

Offer letters, invites, reminders and payslip notices are templates under version control, rendered from the app. What changed in last month's reminder is a diff, not a memory of who edited a third-party editor.

One database, tenant on every row

Shared schema with a tenant identifier on every record, and scoping enforced in the model manager rather than in each view. A query with no tenant bound raises instead of returning everybody.

Learn more

The subdomain is the address

A workspace is reached at its own host, and the token you present must agree with it. Point your integration at one host per workspace and the isolation takes care of itself.

If the one you need is not here

We would rather list four connections that work than forty that half-work. There are no outbound webhooks yet and no accounting connector. If the system you need to talk to is not on this page, the API is, and most integrations are a few endpoints away. Tell us what you are connecting and what has to flow which way — it is a useful conversation for both of us.

Book a demo · 30 min

Bring the system on the other side.

Your finance tool, your access-control hardware, your Slack workspace. Thirty minutes is usually enough to know whether it is a few API calls or a longer conversation.