Portal diagnostics and onboarding progressCopy Anchor Link

Open the developer dashboard and select an organisation. Its owner or admin can inspect progress and activity. Q rechecks current Wocha membership for every management request; cached organisation names do not grant access.

Evidence-based setup checksCopy Anchor Link

The dashboard shows four live checks:

1. Organisation access verified: the overview endpoint accepted the current membership.
2. Active API key created: the organisation has a non-revoked, unexpired key. This does not mean the selected historical key is active or has every required scope.
3. Successful API response observed: a retained HTTP 2xx response was recorded for the selected API key.
4. Environment configuration checked: the phase-4 readiness checks passed. Live provider connectivity and worker execution remain separate checks.

Progress is recalculated when you refresh. It is not a lifetime achievement record: revocation, configuration changes and retention expiry can change the result. Unavailable data does not count as success. No persistent checkbox or browser credential is used to infer progress.

A recorded HTTP 2xx does not prove an answer was correct, a stream finished, or an external action succeeded. Follow the first integration guide and workflow helpers to verify the actual result.

Select the identity that made the requestCopy Anchor Link

Choose Your signed-in user to inspect your own retained durable runs, or select an organisation API key to inspect the activity made with that key. Owners and admins can inspect these content-free key diagnostics, including historical records for revoked or expired keys. The server verifies that the chosen key belongs to the selected organisation. Other users' OIDC runs remain private.

Request logging records API-key calls only. When the signed-in-user identity is selected, the HTTP-response check stays not checked. No recorded activity can mean that you selected a different key, used another authentication method, logging is disabled, records expired, or a best-effort write was lost.

Recorded HTTP responsesCopy Anchor Link

The request panel shows retained response counts and the latest 20 response records for the selected key: a fixed API surface label, status, latency, timestamp and request ID. It does not return request/response bodies, raw URLs, query strings, headers or arbitrary error text.

The window is at most 30 days, shortened by the deployment's request-log setting and governance retention policy. Expired rows are excluded even before cleanup runs. Logging may lag or drop records; these counts are observations, not billing totals. Stream status and latency describe the initial HTTP response, not final stream completion. Unauthenticated failures cannot reliably be attributed to a key and may not appear.

HTTP failures include next steps for credential/scope checks, schema validation, rate limits, idempotency conflicts and unavailable services. Preserve the response's original request ID when contacting support.

Durable run diagnosticsCopy Anchor Link

The activity panel covers version-2 durable runs created within the retained window for the selected identity. It shows the latest 20 runs, state counts and whether a completed run is recorded. These are not HTTP request counts and do not include ordinary search or answer calls.

Choose Inspect run for the existing diagnostic report: safe failure codes, recommended next action, queue and execution timing, worker-stage timings, provider observations, spend holds and reconciliation state, and replay availability. Missing measurements stay missing. Provider observations and spend-ledger figures are not invoice totals. Recorded stage timings can overlap and represent the latest finished worker attempt.

Copy support details copies only run/agent/request identifiers, state, safe reason/failure/action codes and report timestamp. It excludes prompts, results, credentials and cost details. Diagnostics do not approve, resume, replay or cancel work. Reconcile uncertain effects before retrying a mutation.

Management endpointsCopy Anchor Link

All endpoints require a Wocha user session and current owner/admin membership. They are read-only and return Cache-Control: no-store:

• GET /api/v1/developers/organizations/{org_id}/overview
• GET /api/v1/developers/organizations/{org_id}/requests
• GET /api/v1/developers/organizations/{org_id}/runs/{agent_id}/{run_id}/diagnostics

Append ?api_key_id=123 to select a managed key. Omitting it selects the verified signed-in identity for runs and leaves request-log verification unavailable. The browser never supplies a principal hash or arbitrary upstream URL.

Membership failures return 403; foreign/missing keys and inaccessible run records return 404. Store failures and bounded-query timeouts return 503, not an empty activity list. Disabled logging or zero retention is reported explicitly. These views reuse existing log, key, run and spend tables; they require the current schema but add no migration.