Api

An API lets two systems exchange information directly. In an HR context that usually means a new joiner created once and appearing in payroll, access management and the directory without anyone re-typing them, or attendance data flowing into payroll without a monthly export.

The value is not automation for its own sake. It is the removal of re-keying, which is where a large share of HR data errors originate. A bank account entered twice is entered wrongly some proportion of the time, and the first payroll run is where that gets discovered.

The second value is timeliness. A leaver whose exit reaches access management the same day is a security improvement, not merely an administrative one.

Every vendor answers yes to whether they have an API. The useful questions are narrower.

The last row causes the most avoidable outages. A vendor that changes a response format without versioning will break every integration built against it, and the failure appears as wrong data rather than as an error.

The recurring cause of integration problems is not the connection failing. It is two systems both believing they own a field.

If the HR system and payroll both allow an address to be edited, they will diverge, and the sync will either overwrite a correct value with a stale one or conflict on every run. The same happens with cost centres, job titles, reporting lines and bank details.

• Decide, per field, which system is authoritative, and make the others read-only for it.
• Write that down somewhere findable, because the decision is invisible in the systems themselves.
• Handle the exceptions explicitly rather than by manual correction, since manual correction is what recreates divergence.
• Decide what happens when the authoritative system is wrong, so the fix goes to the source rather than to the copy.

The last is where discipline usually breaks. Correcting a payroll record directly because it is urgent, without correcting the source, guarantees the error returns at the next sync and looks like an integration fault.

Moving personal data through an API does not change what it is or reduce the obligations attaching to it.

An integration that sends the full employee record to a system needing only names and email addresses is over-sharing, and doing so programmatically makes it continuous rather than occasional.

• Send the minimum the receiving system needs, not everything the API can return.
• Know where the data goes, including whether the receiving system is hosted outside India.
• Include integrations in retention thinking, since a copy in a downstream system outlives deletion in the source unless someone handles it.
• Treat API credentials as access to the whole dataset, because that is what they usually are.

The third point is the one most often missed. Deleting a leaver's record in the HR system does nothing about the copies pushed into four other systems over the preceding years.

An integration that works is invisible, and one that has stopped working is also invisible until something downstream is wrong.

In HR that downstream is usually payroll, and the discovery point is usually a pay run. A new joiner missing from payroll, a leaver still being paid, or attendance data that stopped arriving three weeks ago all present as payroll errors and are integration failures.

• Alert on failure, and on the absence of expected activity, since a sync that runs and transfers nothing looks successful.
• Reconcile counts periodically rather than trusting the connection.
• Name an owner. Integrations are frequently built by someone who has since left and are owned by nobody.
• Know how to run the process manually, because you will need to at some point.

The second is the practical control. Comparing record counts between systems on a schedule catches silent divergence long before a person notices it in a payslip.