Skip to content

Integrations

Integrations is where Humavera is joined to the other systems your company runs, so people sign in once and data moves without being retyped. It covers both directions: bringing data in, and telling other systems when something changes.

Choosing the right one is most of the work, and the question is what triggers the exchange.

OptionDescription
Single sign-onYour identity provider authenticates people, so they use existing company credentials. Supports SAML and OIDC.
WebhooksHumavera tells another system the moment something happens. Event-driven, outbound, near-immediate.
API keys and OAuth appsAnother system asks Humavera for data when it needs it. Request-driven, inbound.
Import and exportBulk movement of records, run on demand or scheduled. Best for volume, not for immediacy.

Example: HC Corp uses single sign-on so people use their company login; a webhook tells its service desk when someone joins; and a scheduled export feeds its finance system. Three mechanisms, three different reasons.

Beyond authentication, sign-on can map attributes from your identity provider onto Humavera, including mapping groups to roles. That means a person’s access follows what your directory already says about them, rather than being maintained twice.

Configuration is testable before you switch it on. Test first — a misconfigured sign-on locks people out of the system they need in order to report it. Set up single sign-on covers the whole sequence.

Webhooks carry a signature so the receiving system can verify a message genuinely came from Humavera and was not altered. Deliveries are logged, failures retry with increasing gaps rather than hammering a system that is down, and an endpoint that keeps failing is paused automatically instead of retrying forever.

Example: if HC Corp’s receiving service is offline for an hour, deliveries retry rather than being lost, and the endpoint pauses rather than accumulating failures indefinitely.

API keys are scoped, so a key grants only what it needs, and rate-limited so one integration cannot exhaust capacity. Keys are stored hashed, which means a key is shown once when created and cannot be retrieved afterwards — if it is lost, it is replaced rather than recovered. Usage is tracked per key.

OAuth apps are registered separately, with secret rotation, for integrations that act on behalf of a user rather than as a service.

Connectors cover categories of system rather than individual products — human resources, learning, recruitment, identity, calendar, and communication, plus a custom option. Credentials are stored encrypted, and syncing can be scheduled.

Connectors, API keys, and single sign-on depend on your subscription plan.

Import handles the bulk path, accepting common spreadsheet and data formats with field mapping and validation. A dry run previews the outcome before anything is written, which is the step to use rather than trusting a large file.

Example: loading HC Corp’s existing employee records is an import with a dry run first, not several hundred records typed in by hand.

Underneath webhooks, domain events are persisted and delivered reliably, and can be replayed. This matters when a receiving system was down: the events still exist rather than having been broadcast into nothing.

Set up single sign-on before inviting many people, because it changes how everyone signs in. Import your employee records before configuring payroll, since payroll reads from them. Once connections are live, monitor delivery logs and API usage — an integration that has quietly stopped is easier to catch there than in the system waiting for the data.