Most engineers don't think about HR software until they're the ones stuck debugging why a new hire's SSO login isn't syncing with the payroll system three minutes before their first day. I've spent time on the integration side of an HRMS (Zimyo), connecting it to identity providers, job boards, accounting tools, and background verification APIs. It's not glamorous work, but it exposes some API design lessons that generalize way beyond HR tech.
Here's what stood out.
- Auth integrations fail loudest when they're not your fault
Single sign-on sounds simple on a slide: connect Okta, OneLogin, Google Workspace, or Microsoft Entra, and users log in with existing credentials instead of juggling another password. In practice, each provider implements SAML or OIDC with just enough variation to make "standard" a loose term.
The lesson that stuck: build your SSO integration layer assuming the identity provider's token claims will occasionally be inconsistent or delayed, not just wrong. A user's role or department attribute syncing a few seconds late shouldn't lock them out or route them to the wrong permission set. Defensive defaults (fail to a safe, minimal-access state rather than an error page) save you from a lot of angry Monday-morning tickets.
- Data sync isn't a one-time import, it's a relationship
Connecting an HRMS to finance tools like Tally, Zoho Books, or QuickBooks looks like a straightforward export/import job at first. It isn't. Payroll data changes constantly, salary revisions, new joiners, exits, tax adjustments, and both systems need to agree on what's current without one silently overwriting the other's changes.
The pattern that actually holds up is treating sync as an ongoing reconciliation process rather than a batch job: track a last-modified timestamp or version per record, sync deltas rather than full snapshots, and always log which system was the source of truth for a given change. Skipping this is how companies end up with two different "official" salary figures for the same employee, which is a genuinely bad Tuesday for finance.
- Third-party APIs you don't control need a translation layer
Background verification is a good example. Zimyo integrates with providers like DigiLocker, SpringVerify, IDFY, TraqCheck, and Authbridge, each with its own request/response shape, status codes, and webhook conventions for "verification complete" or "flagged for review."
Rather than letting each vendor's API shape leak into the core product logic, the integration layer needs to normalize everything into one internal schema (status: pending | verified | flagged | failed, plus a vendor-specific payload for anyone who needs the raw detail). This isn't a novel idea, it's just the adapter pattern, but it's easy to skip early on and painful to retrofit once you're integrated with six vendors instead of one.
- Webhooks need idempotency more than they need speed
Interview scheduling integrations (Zoom, Google Meet, Microsoft Teams) and job board postings (Naukri, Indeed, LinkedIn) both rely heavily on webhooks and callbacks. The failure mode that actually bites you isn't slow webhooks, it's duplicate ones. A flaky network retry on the sender's side can fire the same "interview confirmed" event twice, and if your handler isn't idempotent, you get double calendar invites or duplicate candidate records.
Simple fix, easy to forget under deadline pressure: every webhook handler should check whether it has already processed that event ID before acting on it.
- The boring integrations are the ones users actually notice
Nobody praises a company for having working SSO or accurate payroll sync. But the moment either breaks, it's the first thing people complain about, loudly, and often to leadership. There's an asymmetry here worth internalizing: unglamorous integration work has a much higher cost-of-failure-to-cost-of-praise ratio than flashy new features. It's worth budgeting engineering time accordingly, even when it's hard to justify on a roadmap next to more visible features.
Where this is heading
A lot of this integration work is starting to shift from "move data from A to B reliably" to "let a system decide what to do with that data." Zimyo's newer agentic AI layer (part of what they're calling Zimyo 3.0) leans on exactly this kind of integration backbone, pulling attendance, payroll, and compliance data together and having an AI agent flag anomalies or resolve routine queries instead of routing everything through a person. None of that works without the unglamorous sync and normalization layer underneath it being solid first.
If you're building integrations for any multi-system SaaS product, the SSO/data-sync/webhook lessons above generalize pretty directly, whether you're working in HR tech or anywhere else that has to play nice with a dozen other people's APIs.
Top comments (0)