DecentroHR
Start free
Documentation

Build on DecentroHR.

Everything you need to integrate — quickstart, auth, and the full reference.

Welcome to the DecentroHR developer docs. DecentroHR exposes its entire platform through a single, versioned, permissioned API — the same contract the app and the AI assistant run on. If an action ships, you can call it.

Quickstart

Every request goes to one versioned base URL and authenticates with a bearer token.

  1. Get a token. A partner key provisions client orgs and mints per-org service tokens; a client-org token is what the SDK uses for day-to-day calls.
  2. Call an action. POST /v1/actions/<name> with a JSON body. Discover the full list at GET /v1/actions or in the API reference.
  3. Handle the result. Successful calls return { ok: true, result }; errors return a typed error code and message.
first-call.shDecentroHR
# list every available action
curl https://api.decentrohr.com/v1/actions \
  -H "Authorization: Bearer $DHR_TOKEN"

# run one
curl -X POST https://api.decentrohr.com/v1/actions/payroll.listRuns \
  -H "Authorization: Bearer $DHR_TOKEN" \
  -H "Content-Type: application/json" -d '{"companyId":"..."}'

Authentication

Authenticate every request with an Authorization: Bearer <token> header. Tokens are scoped and hashed; a client-org token is bound to exactly one tenant, and a partner key can only ever target tenants it owns — cross-tenant access is impossible by construction.

Never ship a token in client-side JavaScript. Call the API from your server, or from a serverless function that keeps the token secret.

Concepts

DecentroHR is built on a single action registry: one dispatcher enforces role-based access, plan entitlements and an audit trail for every call — whether it comes from the app, the SDK or the AI. Money-critical state (payroll) posts once through an append-only, hash-chained ledger, so every figure is traceable and reproducible.

Next: the API reference, the SDK, or webhooks.