The Ziggu public API exposes 28 resources across 55 endpoints, from projects and units to issues, decisions, installments and messages, with a rate limit of 60 requests a minute.
https://api.ziggu.app/public in JSON:API format.ziggu-integration-token header carrying an integration slug and a token, granted per organisation on request.The Ziggu public API exposes 28 resources over 55 endpoints, in seven families: project structure, people, snagging and aftercare, decisions, money, documents and messages. That is the whole surface. Anything outside those seven families is not reachable from the API, whatever the product page next to it says.
One thing catches every team on the first afternoon. The names in the API are not the names on the website. A developer greps for issues; a project lead calls the same thing Reports. Both are right, and a mapping table saves an hour of confusion in the kickoff call.
| Family | Resources in the API | What it is called in Ziggu |
|---|---|---|
| Project structure | projects, phases, lots, buildings, units, spaces, fractions | Projects |
| People | customers, unit_customers, companies, partners, employees (read only) | Clients and partners |
| Snagging and aftercare | issues, issue_lists, issue_list_types, issue_categories, issue_statuses, tickets (read), ticket_categories (read) | Reports |
| Decisions | decisions, decision_types, decision_type_categories (read), proposals | Decisions and Approvals |
| Money | installments, installments/groups | The financial layer in Client Updates |
| Documents | documents, attachment_categories | Documents |
| Messages | messages (GET and POST only) | Conversations |
Read that last column before you name anything in your own system. A field called issue_status landing in a dashboard your project leads use every day will be read as a bug tracker, not as a snag list.
A project divides into phases, lots and buildings, and those carry the units; a unit then carries its spaces. Every foreign key follows that line, so a filtered call at any level returns the branch below it.
fractions sits beside that line rather than in it: it carries a project, a unit and an installment, so it is the join between a unit and what is invoiced against it.
Two things worth knowing before you write the joins. Phases, lots and buildings each carry units_count and units_active_count, so a roll-up for reporting needs no aggregation on your side. And every level except project and unit is optional: a unit can hang straight off a project.
Authentication runs on a custom header, ziggu-integration-token, carrying your integration slug and your token. It is not OAuth 2.0 and there is no bearer token. Access is granted per organisation, on request: contact the team with what you intend to build and they set the integration up with you.
The limit is 60 requests a minute, counted across all endpoints together, not per resource. Plan a nightly sync around it rather than a per-record loop.
The API is not read only. Most resources accept POST, PUT or PATCH, and several accept DELETE. messages is the exception that catches people out: it takes GET and POST, so you can post into a conversation but not edit or remove what is there.
Responses follow JSON:API. A flat import gives you one column called data, so plan on unpacking data and attributes, and on resolving relationships that arrive as references rather than as nested objects.
Availability is published rather than promised: over the last 60 days the API ran at 99.997%, on the same public status page as the app and the website.
Four capabilities on the Ziggu website have no endpoint behind them, and knowing that up front is worth more than any feature list.
There is no tasks resource. Task Management is a product feature, and it is not reportable through the public API. If your dashboard needs task state, it needs a different route.
There are no milestones. phases exists and is often mistaken for it, but a phase is a structural level that carries lots and buildings, not a date on a timeline. Anything you build on milestones in the API is being built on a resource that does not exist.
Forms and Workflows have no endpoint either. Survey answers and workflow state stay inside the product.
There are no webhooks. Nothing in the API pushes to you, so every integration is a pull on your schedule, inside the 60-per-minute limit. That single fact usually decides the architecture: a change in Ziggu becomes visible to your system when your next poll runs, not the moment it happens.
| Feature on the website | Endpoint in the public API |
|---|---|
| Reports | Yes: issues, issue_lists, tickets |
| Decisions and Approvals | Yes: decisions, proposals |
| Documents | Yes: documents, attachment_categories |
| Conversations | Partly: messages, GET and POST only |
| Client Updates | Partly: installments and installments/groups |
| Task Management | No |
| Forms | No |
| Workflows | No |
If you are looking for a connection to a named tool rather than a resource list, the integrations overview is the shorter route.
The full reference is an OpenAPI 3.0.3 specification, published at api.ziggu.app/api_docs, and it describes every endpoint with its fields and its relationships. It is the source of record: where this page and the specification disagree, the specification is right.
To get started, contact the team with the integration you have in mind. Access is set up per organisation, and the same conversation is where the token comes from.
