Plugin Endpoints

These endpoints are only available when an auth plugin is installed. Check discovery.services.auth.enabled first.

There is no workflow endpoint, and there is no workflow service slot. The three routes documented here were declared in the API protocol and served by nothing — no dispatcher handler, no plugin — so they 404'd for the whole life of the declaration. The slot, the WorkflowProtocol methods behind it and the discovery fields that reported it were all retired in v17 (#4451). Use the live mechanisms instead: an object validation rule of type state_machine for lifecycle transitions, an approval flow node for human approval pauses (ADR-0019), and lifecycle hooks / record_change flows for record-triggered automation.

Not yet mounted. The /ui/views CRUD routes are declared in the API protocol but no handler is registered for them, so they return 404 today (and the /api/v1/ui prefix is itself deprecated in favour of /api/v1/meta/view). The always-available view resolver is a separate route — see the note below.

The auto-generated (non-CRUD) view resolver GET /ui/view/:object/:type is always available and provided by the kernel — see Metadata API. It is a separate route from the /ui/views CRUD above.

Not implemented. There is no realtime HTTP or WebSocket surface: @objectstack/service-realtime is an in-process pub/sub bus consumed via kernel.getService('realtime'), not over HTTP. The dispatcher has no /realtime branch, discovery deliberately omits the route (features.websockets is false), and the routes below would return 404 (ADR-0076 D12). They document the planned protocol shape only.

The core dispatcher implements only the list / read / read-all routes above. Device-registration and preference endpoints are provided by specific notification plugins, if any.

This table used to be inverted (#3718). It listed /ai/nlq, /ai/suggest and /ai/insights — none of which any plugin has ever mounted — and its callout stated "there is no /ai/chat route", which was wrong.

The three phantom routes were declared in DEFAULT_AI_ROUTES and called by client.ai.nlq/suggest/insights; every call 404ed. v17 removed that SDK namespace rather than build endpoints for it, and the same issue then gave the SDK the surface that does exist — the ai.* column above.

Reviewed dispositions for all 12 routes live in the cloud repo, packages/service-ai/src/ai-route-ledger.ts, whose conformance test reads buildAIRoutes() and drives the SDK against it. The three rows with no SDK method are deliberate: /status and /effective-model are operator diagnostics, and /chat/stream is superseded by /chat's streaming mode. For a React chat UI prefer useChat() (@ai-sdk/react) — it speaks the same protocol ai.chatStream parses and owns message state for you.

This table used to list two routes that never worked (#4087). POST /storage/upload and GET /storage/file/:id were a dispatcher-side bridge to the file-storage service, written against a service shape that does not exist: it called upload(key, data, options?) as upload(file, { request }) — a TypeError against every implementation in the repo — and read the Buffer that download(key) resolves as if it were a { url | stream | mimeType } descriptor. They stayed mounted and reachable — nothing shadowed them — so anyone who followed this table got a 500; everyone who followed the SDK used the protocol above and never touched them.

Both routes are retired. /storage is service-storage's surface — install that package to get it. Discovery advertises the route only when the occupant of the storage slot (spelled file-storage before #9683; that spelling stays a deprecated v17 alias) actually mounts HTTP handlers, so an in-memory dev implementation now reports handlerReady: false and no routes.storage instead of pointing at a path with nothing behind it.