API conventions

The API is HTTP with JSON, with no version in the path and no SDK: http://localhost:3000/api/.... The rules below hold for every route, without exception.

Credential

Authorization: Bearer <token> for scripts, a session cookie for the browser. Both end at the same identity, and the cookie takes precedence. Details in Authentication.

Input

• Every input goes through a schema. Whatever does not match is refused with 422, and the details field carries fieldErrors and formErrors, field by field.
• An absent field is not touched. In a PATCH, sending only { favorite: true } touches only that. Clearing takes an explicit value: null.
• `tenantId` is immutable. It appears at creation and in no edit schema.
• Final list vs. add/remove: tagIds on a card is the FINAL list; in a batch, labels travel as addTagIds/removeTagIds.

Output

Success returns the serialised resource (or { "deleted": true }, or a count). Failure always returns the same shape:

{
  "error": "Dados inválidos.",
  "details": {
    "formErrors": [],
    "fieldErrors": {
      "name": ["Campo obrigatório."]
    }
  }
}

error is a sentence in Portuguese, the application's interface language, written for whoever is on screen. details only shows up on schema refusals. The full list is in Error handling.

A batch operation refuses as a whole

A destructive route requires the phrase in the body

The interface's confirmation is a layer on top of that, never the only one. confirm is consumed during validation and is never stored.

Static segment precedence

bulk, epic and order take precedence over [id] in routing. No resource becomes unreachable because of it: ids are cuids (or fixed and readable, such as tenant-pessoal), and none of them is one of those words.

There is no pagination

Listings return the whole set of the requested filter, ordered. The filter that does exist is the workspace, and it is applied on the server.