API docs

Documentation that reads
like code, not a brochure.

The public docs surface the parts developers need first: auth, core endpoints, webhooks, and error behavior. The goal is to make integration feel predictable on day one.

Open full docs Get access

Authentication

Bearer tokens and X-API-Key

The API supports app sessions with bearer tokens and server-to-server automation with API keys. Tenant scope stays enforced in both cases.

curl /v1/invoices

curl -X POST {BASE_URL{'}'}/invoices   -H "Authorization: Bearer <token>"   -H "Content-Type: application/json"   -d '{"client_id": 42, "due_date": "2026-04-30"}'

Core endpoints

The first endpoints answer the important questions

If the first integration touchpoints are clear, the rest of the API tends to feel obvious.

GET/clients

List clients for the current tenant

POST/invoices

Create an invoice and generate its number

POST/payments

Record a payment against an invoice

GET/reports/aging

Fetch outstanding aging data

Auth and errors

A predictable API is easier to ship

The docs call out auth, rate limits, and error handling up front so the integration story stays boring in a good way.

Example response

json response

{
  "success": true,
  "data": {
    "invoice_id": 4242,
    "invoice_number": "INV-2026-0042",
    "status": "draft",
    "tenant_id": 1
  }
}

Token model

Bearer token for users, API key for integrations.

Webhook events

invoice.created, invoice.sent, invoice.paid, payment.recorded, and more.

Error format

Validation and auth errors return structured JSON with actionable messages.

Rate awareness

The platform applies tenant and subscription-aware limits where it matters.

Webhook catalog

Events for the moments you care about

The webhooks are small on purpose. They cover the state changes that matter to reporting and automation.

invoice.created