Public API
Your data has an API,
with keys you govern.
A per-company API key, shown once and stored as a fingerprint, opens a versioned REST surface over your records: company, users, employees, roles, projects, shifts, absences, expenses. Scopes decide what each key may touch, and webhooks tell your systems when something changes — signed, retried, and disabled when an endpoint keeps failing.
A key is scoped, and shown exactly once.
Keys are created per company with the scopes they need and nothing more; the secret is displayed at creation and never again — what is stored is a fingerprint. Reading users is one scope, writing them another, and most of the surface is deliberately read-only today.
One key, its scopes, its fingerprint — the secret shown once at creation.
Webhooks that survive a bad afternoon.
Created, updated, deleted — on the same resources the API exposes — delivered with an HMAC signature and retried on failure at growing intervals. An endpoint that keeps dying is switched off automatically and the admins are told, so a broken integration arrives as a notification.
A delivery with its signature, the retry ladder behind it, and the auto-disable at the end.
Limits that protect your tenant.
Requests are rate-limited per key and per company, with an honest 429 and a Retry-After when you reach them. Idempotency keys make retries safe on the write path: the same request twice is one effect.
The limits as the integrator sees them: per key, per company, with Retry-After.
Gated the way everything here is gated.
The module is the master switch: without it, no key of the company authenticates. Each resource also answers to the module that owns it — shifts through the commesse, users through the core — so the API can never show what the platform itself would not.
A scope refused because its module is off: the API answers like the product.
Everything it does
- Scoped API keysOne key per integration, scoped per module, optional expiry, instant revocation and company-isolated data.
- Signed, reliable webhooksHTTPS endpoints per module event, signed deliveries, growing retries and a full delivery log.
- REST API over company dataRead company, people, projects, shifts, absences and expenses via paged, filterable lists.
- Safe writes and user provisioningIdempotent writes attributed to the integration, user creation with invite and session-ending offboarding.
- Developer documentationIntegration guides, a changelog and an interactive API reference always matching the live specification.
Questions we actually get asked.
- Can we write everything through the API?
- Not yet. Users can be created and deactivated; the rest of the surface is read-only today. What is exposed is exactly what is listed, and the list will grow deliberately.
- How are webhooks secured?
- Every delivery is signed with a per-endpoint secret, so your receiver can verify who is calling. Failures retry at growing intervals; an endpoint that fails repeatedly is disabled automatically and the admins are notified.
- Which records can it reach?
- Company, users, employees, roles, projects, shifts, absences and expenses — each behind its own scope, and each behind the module that owns it in the platform.
Works with
- AIAn assistant that answers from your data, and recurring tasks that run on the schedule you set.
- AI agentsScheduled agents that run a recurring flow, starting with the month-close, leaving drafts to review and a report of what they did.
- Reports and exportsAny table becomes an XLSX with the filters it was showing, from templates you keep for the exports you rerun.
Tell us how you work today.
There is nothing to prepare. Half an hour on how your company runs — who tracks the hours, how an invoice comes together, when you find out whether a commessa made money — and we tell you which modules would fix it and what a quote looks like.