Aozo Developer Documentation
REST APIs for every product in the Aozo suite — CRM, Accounting, Helpdesk, Chat, Projects and Teams — all authenticated through one shared identity layer, account.aozo.in.
How the Aozo API surface works
Each product ships its own independent REST API on its own domain. There is no single unified gateway — you call crm.aozo.in/api/... for CRM data and helpdesk.aozo.in/api/... for Helpdesk data directly. What ties them together is identity: every product accepts a token issued by the same Central Auth server, so a user who signs in once can be recognized by any product that also has them as a workspace member.
| Product | Base URL | Accepts |
|---|---|---|
| Aozo CRM | crm.aozo.in/api | Bearer JWT, or an aozo_-prefixed API key |
| Aozo Accounting | accounting.aozo.in/api | Bearer JWT, or an aozo_-prefixed API key |
| Aozo Helpdesk | helpdesk.aozo.in/api | Bearer JWT, or x-api-key + x-workspace-id headers |
| Aozo Chat | chat.aozo.in | Session cookie (from SSO login) — no standalone API key |
| Aozo Projects | projects.aozo.in/api | Bearer JWT only — no separate API key |
| Aozo Teams | teams.aozo.in/api | Bearer JWT only — no separate API key |
Auth isn't identical everywhere
Every product verifies the same underlying JWT, but how you present it differs by product — some also accept a long-lived API key, one uses distinct header names, and one is cookie-first. Check the Auth line at the top of each product page before assuming a pattern carries over.
What's in these docs
- Quickstart Guide — get an authenticated request working in under five minutes.
- Authentication — how Central Auth issues tokens, the JWT payload shape, and how to verify it from your own backend.
- Product pages — one page per product, listing every real endpoint it exposes, grouped by resource, with request bodies and example calls.