Skip to main content
The Woes public API will let teams connect Woes to their own products, internal tools, reporting workflows, and support operations. This section is a public API map. It describes the categories Woes plans to expose, but it does not publish endpoint paths, request schemas, response schemas, SDKs, or production limits yet.
Do not build production integrations from this section until endpoint-level documentation is published.

​
Category map

Authentication

Server credentials, scopes, rotation, widget keys, and conversation secrets.

Workspaces

Workspace metadata, members, roles, tags, custom fields, macros, and automations.

Conversations

Conversation lifecycle, assignment, state, messages, notes, and issue links.

Customers

Customer profiles, external IDs, traits, account context, and channel identities.

Knowledge

API Context sources, scans, endpoint evidence, chunks, and test metadata.

Agent

Lab runs, drafts, citations, confidence signals, handoff events, and verification traces.

Channels

Live chat, Discord, widget sessions, email readiness, and channel configuration.

Webhooks

Event subscriptions for conversations, messages, customers, issues, sources, and agent events.

Errors and limits

Error categories, pagination, idempotency, rate limits, and retry behavior.

​
Design principles

PrincipleWhat it means
Workspace scopedPublic endpoints should operate inside one workspace boundary.
Least privilegeCredentials and scopes should grant only the access an integration needs.
Widget separationBrowser-facing widget routes should stay narrower than authenticated workspace APIs.
Grounded agent dataAgent output should include evidence, confidence, and handoff state where relevant.
Redaction firstSensitive values should be redacted before being returned, logged, or sent to AI workflows.
Stable before launchEndpoint behavior should be stable enough for customer integrations before detailed docs are published.

​
Planned documentation layers

1

Category map

The current docs define the major API surfaces and boundaries.
2

Endpoint reference

Future docs should add paths, methods, parameters, request bodies, responses, examples, and auth scopes.
3

Integration guides

Future guides should show common workflows, such as creating a conversation, syncing customers, or subscribing to webhooks.
4

SDKs and changelog

SDK docs and versioned API changes should come after the endpoint contract is stable.

​
Intentionally not documented yet

  • Endpoint paths.
  • Request and response schemas.
  • Authentication scopes.
  • SDKs.
  • Webhook signing format.
  • Versioning policy.
  • Production rate limits.
  • SLA or compliance claims.
Those details will be added when the public API is ready for integration work.