The portal in your IT landscape
HRIS import, SSO, and an open API
Connect sign-in through your corporate identity provider, employee import from your HRIS, and data exchange over an open API. This page lists what connects, what needs your IT team, and what the product does not do.
Data sources
How a connection is set up
- 1
Sign-in through your own directory
An administrator registers a connection to your identity provider over OIDC or SAML in the admin panel. Employees then sign in with the same account they use for email.
- 2
Accounts created on first sign-in
JIT provisioning: a person who does not yet exist in the portal is created at the moment of their first successful SSO sign-in. There is no separate 'create the users' step.
- 3
Employees from the HR system
Import over the external API, or a CSV upload. A second run updates the existing records instead of producing duplicates.
- 4
Sign-in restricted to SSO
Once everything is verified, IT switches on enforced SSO and password sign-in stops working. From that point access revocation lives on the company's side: disable the account in the directory and it closes everywhere.
- 5
Everything else over the API
Absences from the HRIS, external data for calculations, an export into your own analytics. An API key is issued for a specific job rather than as general access.
What connects and how
SSO over OIDC and SAML
Sign-in connects to a corporate identity provider — Okta, Entra ID, Keycloak and anything else that speaks SAML or OIDC. Employees hold no separate password.
Connection secrets, the client secret and SAML certificates, are encrypted server-side with Fernet/AES-256 rather than stored in plain settings
JIT provisioning and enforced SSO
A user is created automatically on first sign-in, and password sign-in can be switched off entirely. Two settings that turn the portal from a system with its own list of people into an extension of the corporate directory.
Enforced SSO is a workspace setting, not a per-customer build
Employee import from an HRIS
Synchronisation over the external API: the HR system supplies employees, the portal places them into departments and manager relationships. The org structure and the directory update together.
The /ext/v1/employees/import/* endpoints are part of the product rather than a script for one customer
Import of approved absences
Leave and sick days already approved in an HRIS or ERP arrive in the portal and become visible to the team. The portal does not become the approval system; the decision stays where it has always been made.
A one-way /ext channel: data arrives, and nothing is written back to the HR system
CSV upload for systems with no API
If the HR system exposes nothing, employees can be loaded from a file. For a company whose structure changes a few times a year a file is more honest than a permanent synchronisation.
A repeat upload updates the same records rather than creating new ones
API keys scoped to a job
Each integration receives its own key with a limited set of rights. One key can be revoked without touching the others, and it is clear what will stop working.
Rights are issued per key: read, write, or historical backfill
Email invitation with a code
People who are absent from the corporate directory — contractors, retail staff, a new office — are invited by email with a six-digit code, with no directory entry required.
Works alongside SSO rather than instead of it
Integration catalogue in the admin panel
Connections are visible in one place: what is connected, when it last synchronised, and what went wrong. Nobody has to ask a developer whether the import is running.
Sync status and rejected records are shown per connection
Frequently asked questions
Related TeamEvo capabilities
See the integrations against your own setup
Name your identity provider and your HR system, and the demo will show the connection and the second import run rather than only the first.
