Status: in development. The public REST API and webhooks are designed and the specification is locked, but the endpoints are not live yet. This page is honest about the split: what you can integrate today, and what the API will look like when it ships. If programmatic integration is a condition of purchase, tell us — we'll give you dates and early access.
What you can integrate today
A company of 200 to 1000 people never lives in one tool. Payroll and personnel records sit in an HRIS, access is granted in Jira and GitHub, reporting is assembled in BI. Until the public API is live, DTPulse exchanges data through files and through single sign-on. Both are unglamorous and both work.
Employee import and export. The admin area imports CSV with per-row error reporting, and exports in two formats: CSV with the same columns as the import — so it can be loaded straight back, into another company or an on-premise instance — and JSON, a full snapshot including departments, department heads, reporting lines and photos. A nightly dump from your HRIS into CSV plus an upload covers the core personnel-sync case.
Automatic account creation. With SAML, Google or Slack connected, accounts are created on first sign-in. Nobody has to provision a new hire by hand, in the portal or in a script.
Audit log export. The audit log exports to CSV for any date range, up to 50 000 rows per request — enough to feed a SIEM or a corporate warehouse on a daily schedule.
All of that works today, and it covers most of what people actually want when they ask for an API. What it does not cover is reacting to an event in real time and writing back from an external system without a human in the loop. That's what the API is being built for.
What the API will be
The architectural decisions are settled and written down; we don't expect to revisit them.
Workspace tokens, not personal ones. A token belongs to the company rather than to the engineer who issued it, so the integration doesn't break when that engineer leaves. Each token has a name, a set of scopes, a lifetime (90 days by default) and an optional CIDR allowlist. Only a hash is stored; the token itself is shown once, at creation.
Scopes per resource. Not "full access" but a concrete set — read:employees, write:absences, approve:absences, read:pulse. A token can never exceed the authority of the role that issued it: HR cannot mint a token with permissions HR doesn't already have in the interface.
Read and write. Employees, departments, absence requests and approvals, 360-review cycles and their results, work reports, goals, pulse aggregates, audit log. Pagination is cursor-based, which matters once a company has a thousand people and a year of absence history behind it.
A response will look like this:
GET /api/v1/employees?limit=200
Authorization: Bearer dtp_live_...
{ "data": [ … ], "meta": { "cursor": "…" } }
Signed webhooks with retries. Events cover employee created and updated, absence requested, approved and rejected, review cycle activated and closed, work report submitted, pulse run closed. Every delivery carries an HMAC-SHA256 signature in the scheme anyone who has integrated with Stripe already knows, plus a unique delivery id so your receiver can be idempotent. Failed deliveries retry on a widening schedule up to five times, then move to a dead-letter list you can replay by hand. The delivery log, with status codes and error text, is visible in the admin area.
Limits by plan. No "unlimited" anywhere: TEAM gets 3 tokens, 3 webhook endpoints and 60 requests per minute; BUSINESS 10, 10 and 300; ENTERPRISE 50, 50 and 1000. The free plan doesn't include API access.
Everything audited. Every call writes an audit entry marked as performed by a token rather than a person, with the token's name attached. "Who approved this leave request?" gets answered with "the BPM integration, workflow #…".
Who this will help
Your engineers get an ordinary HTTP client, cursor pagination and a predictable error format instead of a nightly CSV parser.
HR stops re-keying personnel changes. They arrive from the system of record, and the two employee lists stop drifting apart.
IT can provision Jira, Confluence and GitHub from an employee.created event, and revoke on the matching delete.
Analytics can pull review and pulse results into BI on a schedule, with the same minimum-sample rule the interface enforces: aggregates covering fewer than three responses are returned to nobody.
Getting started
Today, start with import and export — they cover personnel sync and need no code at all. If you need real programmatic integration, write to us with the scenario. We're prioritising endpoints against real use cases rather than alphabetically, and we'll bring you in as soon as the API is live.