Documentation
Overview
What the NiuCore API is, the mental model you need, and what v1.0 covers.
The NiuCore public API exposes 54 operations — the resources under https://api.niucore.com/api/v1 plus the four OAuth endpoints — to converse with the organization's models, manage the knowledge they use, and read usage metrics. It is the same platform the application uses, with the same engine and the same rules.
The mental model
There is one idea from which nearly everything else follows: a credential is not a new user, it is permission to act as an existing one.
When someone creates a credential, that credential inherits their access: their permissions, their libraries, their license, their company. Scopes narrow that access; they never widen it. If that person loses a permission tomorrow, the credential loses it on the next request, with nobody having to touch it.
Two consequences are worth internalizing from the start: a 403 is almost never fixed in code — it is fixed in the user's or the credential's configuration — and a long-lived integration should not hang off the personal account of someone who may leave the company.
What you can do
What v1.0 leaves out
We would rather say it here than have you discover it halfway through an integration:
| Not available | Why |
|---|---|
| Uploading or deleting library files. | Document ingestion still belongs to the application. The API reads libraries and files, and creates or edits libraries. |
| Authorizing a new connector (Gmail, Drive, Calendar…). | Completing an OAuth flow requires a browser and a person. You use the ones the user already connected. |
| Creating or editing areas and users. | That is organization administration, not automation. |
| Managing credentials through the API. | The public API cannot manufacture more access for itself. |
The application's permission_mode: "plan". | Its cycle — approve a plan, then follow it across several turns — is not modelled by the API yet. The plan_approval interaction does exist: it arrives in manual or auto when the model proposes a plan within the turn, and is answered with `respond-plan`. |
API chats
A chat's public namespace is (company, user, credential). A chat created from the application, or by another credential of the same user, does not exist for your credential: it is not listed, not readable, and cannot receive a turn.
In the application it is the other way round: the chats your integration creates appear in the user's list like any other, and can be read, renamed and continued from the interface. The isolation is of the namespace, not of the data.
Versioning
This documentation describes v1.0. The version travels in the URL, and within v1 changes are forward compatible: new fields can appear, but no existing one disappears or changes meaning. Write code that ignores what it does not know.