Integrations

The Connections screen lists every integration your organisation maintains: a name, a type — Biometric, Payroll, Slack, Email, Webhook or Other — the endpoint URL, an API key where one applies, and a connected or disconnected status. It is a plain, auditable register that administrators add to and retire from as systems come and go.

Alongside it sit the Webhooks register and API Keys. Each webhook records the HR event it is meant for, the HTTP method — POST, PUT or GET — the endpoint it calls and an active or inactive status. API Keys is not a register but an issuer: a key is generated by Nexa People, shown once, stored only as a hash, and enforced on every request against the scope it was issued with. Each key carries a name, its scope, when it was last used and when it expires.

Every webhook row has a Fire button that sends a real test payload to the configured endpoint there and then — a small JSON message identifying the event and marking itself as a test. The result comes straight back: OK with the response code, or Failed with whatever went wrong, and the webhook's status is updated to reflect the last outcome. The register keeps the event label each webhook is meant for against its row; the Fire button is how you prove, on demand, that the endpoint behind it still answers.

The Integrations Settings screen records your webhook policy — whether outgoing webhooks are allowed at all, whether payloads should be signed, and whether failed deliveries should be retried — along with an allow-list of IP addresses or CIDR ranges kept as its own tab.

The device register holds each biometric machine with its name, IP address, port (4370 by default), device type, the station it serves, an optional device password and an active flag — passwords stay masked until an administrator chooses to reveal them. A Sync button opens a connection to a ZK device, pulls its attendance logs and writes them into attendance, stamping the device's Last Sync Date so you can see exactly when each machine last reported.

Devices that push instead use the Client API. The Token Settings panel shows your organisation's Company Token and the push URL to point devices or middleware at; a device posts its punch logs with the token in a header — no user account involved. Punches are matched to employees by their punch code, grouped into attendance days along each employee's shift day-end boundary, and the reply summarises what was saved, updated or skipped. Regenerating the token invalidates the old one instantly; existing devices are then re-pointed to the new value.

Payroll GL Code Mapping captures everything SAP-specific your finance team has to supply, in three tabs. GL Accounts maps each payroll component to an account number in your chart of accounts, with its debit or credit side shown. Cost Centres assigns a cost centre per department — an employee with a cost centre on their own record overrides it. Document Defaults holds the constants stamped on every journal: company code, document type and currency.

SAP Field Names renames columns per dataset. When your SAP calls the employee number PERNR and the cost centre KOSTL, someone types that here instead of a developer editing an extractor; conventional SAP names are shown as hints, and any column left blank simply ships under its Nexa People name — nothing is dropped. Because the columns are declared up front, mapping can be completed before a single period of data exists.

SAP Connection decides how the payload leaves Nexa People. Download mode needs nothing from your side and works immediately: the export lands as a file you upload to SAP yourself. Endpoint mode POSTs the same payload to whatever HTTP door your SAP exposes, with a choice of CSV or JSON and authentication by basic credentials, a bearer token, a custom API-key header, or none.

The JV Report Integration screen is a deliberate two-step. Pick a dataset — Employee Master, Attendance Summary, Payroll Detail or the Payroll Journal — and a month, then Preview: a dry run showing the exact rows, the employee count, total debit and credit and whether the journal balances, and every reason the export cannot run yet, such as unmapped GL accounts. A run with gaps is refused outright, and if the period was already sent successfully you must confirm before sending again. Preview never touches your SAP.

Export History records every run: date, dataset, period, status with the HTTP response code, row count, debit and credit totals, and who sent it. A failed endpoint delivery can be retried — re-sending the exact stored payload, never a fresh build — and any run's file can be re-downloaded byte for byte.