Skip to main content
Public API integrations need predictable failure behavior. This page describes the error and limit categories Woes should document before endpoint-level release.

Planned error categories

CategoryTypical meaning
Authentication failedThe credential is missing, invalid, expired, or revoked.
Permission deniedThe credential is valid but lacks the required scope.
Workspace not foundThe workspace is missing or not visible to the credential.
Resource not foundThe requested object does not exist in the workspace.
Validation failedThe request shape or field value is invalid.
Payload too largeThe request body exceeds accepted limits.
Rate limitedThe integration sent too many requests.
ConflictThe requested state change conflicts with current resource state.
Idempotency conflictThe same idempotency key was reused with different content.
Upstream unavailableA dependent provider or integration is unavailable.
Source scan failedAPI Context ingestion could not complete.
Agent context insufficientThe agent cannot answer from available evidence.

Planned limit categories

Payload limits

Maximum body size and file/source upload limits.

Pagination

Page size, cursors, ordering, and filtering boundaries.

Rate limits

Per-credential, per-workspace, or per-route request limits.

Webhook delivery

Timeout, retry, and payload-size expectations.

Source ingestion

Crawl, document, chunk, and scan limits.

Live verification

Guardrails for running API checks from Woes.

Retry guidance

Future endpoint docs should state:
  • Which errors are safe to retry.
  • Which errors require user action.
  • Which operations support idempotency keys.
  • How rate-limit reset information is returned.
  • How webhook retries are scheduled.

Current expectation

Rate limits should be treated as practical product controls, not a full DDoS or compliance boundary. Teams with high-volume integration needs should coordinate capacity and monitoring before launch.