⚠️ Experimental endpoint — not yet a stable contract. This resource ships as experimental / beta. While experimental, its schema and behaviour may change without a version bump — including breaking changes within v1.0 itself. Anyone consuming it does so for evaluation only, or by coordinating adoption with their account manager so changes can be sequenced with them. It graduates to a stable, version-locked contract (where the normal breaking-change rules apply) only when this experimental notice is removed.

Submit one question for a single, fully automatic, read-only analysis, for example "What happened to user 123?". CoOperator never asks a follow-up question and never waits for confirmation: it always answers with its best effort using the platform data the token's service admin can access, states any assumption it made, and reports what it could not determine. Requests for a change are analysed but never carried out. Poll the read endpoint with the returned id until the state is completed or failed, or subscribe to the CoOperatorInsightChangedNotification webhook through notifications v2.0, which delivers the insight in this same shape as soon as it leaves pending. The webhook reaches operator-level and global subscriptions only, see its own documentation for the recipient rule. One analysis runs per administrator at a time: a request made while the token's service admin already has a pending insight that can still execute is refused with 409. Once that insight has completed or failed, a new request is accepted. Creation is not idempotent: every accepted request is a new insight, so retry only after reading the state of the one you already have.

Requires a Public API token whose service admin has the Access CoOperator permission and an installed, enabled CoOperator app. Every request is rejected with 403 while CoOperator's in-process mode is not enabled for the tenant.

message and context are treated as untrusted input and are not returned by the insight resource. The caller must retain its own copy.

Allowance is checked when the request is accepted and an exhausted allowance returns 429. This best-effort check reserves and refunds nothing, can permit a small overshoot from concurrent requests, and does not prevent already accepted work from completing after the allowance is exhausted.