Skip to content
ebitex developers

WRITABLE_KINDS

const WRITABLE_KINDS: readonly ["contract", "template", "component", "folder", "site", "node", "nodePayload", "adapter", "stream", "audience", "categoryGroup", "category"]

The kind-to-route table.

This is the only content-model knowledge this server holds, and it is not much: which URL a kind lives at. It knows nothing about what a Contract may contain, what field types exist, or what makes a document valid. Those are answered at runtime by the API (content_describe for the first two, the write’s own response for the third), which is what makes this server unable to drift from the product — there is no second copy of the model here to fall out of step.

The table is worth reading carefully, because a reader who assumed a uniform POST /{kind} / PUT /{kind}/{id} shape would get four things wrong:

  • An Adapter updates with PATCH. Every other family takes PUT. PUT /adapters/{id} does not exist, so assuming uniformity builds clean and answers 405 at run time — on the one family whose mapping canvas is the hardest thing an agent will try to author.
  • A node’s payload is its own route, so it is its own kind. PUT /experience/nodes/{id} carries identity and location and not the payload; folding them together would put a silent no-op behind a successful write, which is worse than a refusal.
  • A site is not a node. POST /experience/sites creates a root; a page under it is a separate call to /experience/nodes.
  • The surface is not uniformly CRUD. Folders, audiences, sites and both taxonomy kinds have no single-entity GET at all — they are read by listing. readOne: null records that rather than inventing a route that would 404.

Anything not in this table is not reachable by this server, and that is the same default-closed posture the API itself takes: a management key is refused any route the API does not explicitly admit. Workflow, providers, environments, promotion and credential minting have no row because a management key cannot reach any of them.