Errors

When an API call fails, GoodVision returns an HTTP status code and Problem Details. Handle failures using the status and error code. The detail field provides additional context and should not drive program logic.

Common responses

Status	Meaning	Caller action
400	Malformed request or missing field	Correct the input; do not retry unchanged
401	Missing authentication or invalid token	Obtain a token for the correct issuer and audience
403	Authenticated but unauthorized	Check scopes, organization, ProductAccess, and resource ownership
404	Resource absent or not visible	Verify the ID and authorized tenant context
409	State, version, or idempotency conflict	Read current state before deciding the next action
422	Business rule validation failed	Correct the business input using the error code
429	Quota exceeded	Respect Retry-After and back off
5xx	Service temporarily unavailable	Retry transient failures only as specified by the API

Recover Developer Console operations

Expired sign-in, insufficient recent verification and revoked access require different actions. Follow the displayed error to recover the original scope instead of changing accounts or enterprises to bypass denial.

Situation	Action
401, sign-in expired	Sign in from the original page; the same account and valid scope can retain ordinary drafts, while Secrets and sensitive confirmations are cleared
403, explicitly requiring recent verification	Complete sensitive-action verification, review the original page and submit explicitly
403, enterprise or Application access revoked	Stop operations in that scope and clear old data; ask the current owner or administrator to check access
409, revision or state conflict	Read current state and review the action before submitting again
Timeout or unknown write result	Preserve the original content and operation identifier; use Recover original request or Retry original request instead of creating another operation
Dependency unavailable	Retain verified sign-in and retry the read; failure does not prove an absent enterprise or denied access

Successful verification never automatically replays creation, saving, deletion, payment, replies or forwarding. Changed accounts, sign-out or invalid original scope clears old drafts. API 401 responses still require a correct token; Console session recovery does not replace business API authorization.

If recovery of an unknown request requires sign-in or recent verification, complete verification and explicitly recover that same request. Its content, revision and operation identifier remain unchanged; verification does not prove the earlier write failed. When the page explicitly identifies invalid input, correct the field before submitting a new request.

For help, submit technical feedback within the current Application with safe diagnostics. Platform support participates only after explicit forwarding.

Safe diagnostic fields

• request_id or correlation_id;
• operation_id, delivery_id, or event_id;
• HTTP status and machine-readable error code;
• endpoint name and UTC timestamp;
• Application ID and environment.

Never include an access token, client secret, webhook secret, private key, or complete customer payload in logs or support requests.

Valid token returns 403

A valid Token confirms authentication. For 403, check:

1. Audience and scopes for the target API.
2. Current organization membership.
3. ProductAccess, Delegation and resource permissions for the operation.

Use the current user’s own session and Token. Do not bypass rejection with another person’s session, a forged organization header or shared privileged Token.

Space resolution fails after login

For User and customer space, 401 requires login to the current Application; 403 stops operations in that scope until the Application or membership is confirmed; 503 retains verified login and offers another read. Do not fall back to the developer organization or switch spaces silently. User context requires no additional API Subscription; business API permissions are checked separately.