Reference
OpenAPI specification
The whole public API as a machine readable document. Point your code generator, your API gateway or your test client at it and skip the hand written client.
Where it lives
https://api.iwiconnect.com/openapi.json
It is OpenAPI 3.0.3, served as JSON, and it needs no API key to fetch. A copy is published alongside these pages at openapi.json if you would rather pin a file than call the live endpoint. The live URL is the one that moves with the platform, so prefer it for anything automated.
npx openapi-typescript https://api.iwiconnect.com/openapi.json -o iwiconnect.d.ts
Try it in the browser
The same document is served as a browsable reference, with every endpoint expanded, request bodies pre-filled from the schema, and a working Try it out button.
https://api.iwiconnect.com/reference
Press Authorize, paste a key, and the requests you send from the page are ordinary API requests carrying that key. It runs on the API host itself, so there is nothing to configure and no proxy in the middle, and the spec it loads names whichever host you opened it on.
It is the live API, not a mock. A project you create there is a real project, and PUT /projects/{id}/send really does email an iwi and spend a token. Explore with a sandbox key if you have a sandbox account, and read before you press send.
What is in it
Every endpoint documented on these pages, with its path and query parameters, request body, response envelope and the scope it needs. The scope is stated in each operation's description, so a generated client carries the permission model with it rather than leaving it in a wiki.
| Section | What you get |
|---|---|
paths | Projects, engagements, iwi and rohe, teams, users, organisations, groups, files and billing. |
components.schemas | Every public object and every enumeration, including project types, phases, statuses and meeting types. |
components.securitySchemes | A single bearer scheme. Send your key as Authorization: Bearer iwk_live_…. |
What is deliberately not in it
The specification describes the public API, not the whole platform. Internal endpoints, administrative tooling and the fields behind them are left out entirely rather than marked private, so there is nothing in the document to work backwards from.
- Administrative, support, revenue and diagnostic endpoints. An API key calling one gets a 403 saying it is not part of the public API.
- Billing internals, routing internals and platform flags that appear on some responses. If a field is not in the specification, treat it as something that can change or disappear without notice.
- Address lookup. Geocoding is billed per call, so it stays inside the portal. Geocode on your side and send coordinates.
- The structures iwi hold inside their own accounts. Hapū, marae and takiwā sit with the iwi, and are not exposed here. See iwi and rohe.
Ignore what you do not recognise. Responses can carry fields the specification does not list. Generate your client with additional properties allowed, or you will start failing on a release that only added something.
Keeping up
The specification is regenerated with each release, so the live URL is always current. Additive changes appear without notice. Anything that would break a working integration is announced by email to key owners first and listed in the changelog.
If you are pinning a copy, re-fetch it as part of your own release process rather than once at integration time, and diff it. A new enum member in ProjectType is the change most likely to reach you first.