Build better business messaging.

Two secure ways to integrate

Customer API keys

Customers can create scoped, expiring application keys. Keep bearer keys server-side and never include them in frontend JavaScript, URLs or support tickets. Keys can be rotated and revoked.

Authorization: Bearer dvk_... 
GET /v1/me
GET /v1/contacts
GET /v1/templates
GET /v1/usage

Delegated agent access

For Mia, Leo or another customer-approved agent, use the authorization-code flow with PKCE S256 and an exact registered HTTPS callback. Customers sign in to their TryDataverse workspace and see requested permissions and daily limits before they explicitly approve. Their private API key is never handed to the agent.

Token lifetimes: Access tokens 15 minutes; rotating refresh tokens up to 30 days; standing customer authorization continues until revoked, subject to limits and provider policy.

GET  /connect/authorize
POST /connect/approve
POST /oauth/token
GET  /v1/agent/authorization
GET  /portal/api/agent-grants
POST /portal/api/agent-grants/{grant_id}/revoke

The current private token endpoint accepts JSON request bodies. Public OAuth discovery metadata and standards-compliant form encoding remain to be implemented and verified before formal OAuth interoperability claims.

Endpoints grouped by workflow

Workspace and application management

GET    /v1/me
GET    /v1/apps
POST   /v1/apps
GET    /v1/apps/{app_id}/keys
POST   /v1/apps/{app_id}/keys
DELETE /v1/apps/{app_id}/keys/{key_id}
DELETE /v1/apps/{app_id}

Contacts and campaigns

GET    /v1/contacts
POST   /v1/contacts
POST   /v1/contacts/{phone}/opt-out
GET    /v1/templates
GET    /v1/agent/campaigns
POST   /v1/agent/campaigns/drafts
POST   /v1/agent/campaigns/{campaign_id}/pause

Messaging and reporting

POST   /v1/messages
GET    /v1/messages
GET    /v1/usage
GET    /v1/inbox/conversations
GET    /v1/inbox/contacts
GET    /v1/agent/wallet

A template send requires a verified business number, Meta-approved matching language/template, recorded opt-in, an idempotency key and enabled production delivery. Messages without a recent authenticated inbound customer conversation cannot be sent as unrestricted free-form replies.

Example draft creation — this creates no real outgoing WhatsApp message or charge:

POST /v1/agent/campaigns/drafts
Authorization: Bearer dva_...
Content-Type: application/json

{
  "name": "October follow-ups",
  "template_name": "order_followup",
  "language": "en_US"
}

Always check both the HTTP response and asynchronous final delivery state. An accepted provider submission is not a guaranteed delivered or read message.

One approval. Ongoing bounded automation.

An agent integration must be registered to the platform with exact callback URLs. It generates a cryptographically random state and PKCE verifier, sends the customer to the consent page, and exchanges the returned short-lived authorization code. Refresh tokens rotate; replay terminates the affected token family.

Credit debits are not delegated yet. Read-only wallet visibility is available with credits:read; credits:spend is intentionally unavailable until actual merchant capture, Meta tariffs and financial controls have been verified. Approval does not override WhatsApp policy or consent.

Predictable operations, traceable results.

Mutating message requests require Idempotency-Key. Token access is tenant-scoped, and its associated permission may be revoked immediately. The business messaging engine does not automatically retry an uncertain delivery outcome because doing so may create duplicate customer messages.

Existing private infrastructure exposes /openapi.json and /docs for full typed schemas. A public hosted interactive API console and public API endpoint are planned but not yet enabled.

For the initial technical review, customer key/API and delegated-agent backend paths were exercised with real PostgreSQL and mocked Meta delivery/payment providers. Security penetration tests, load testing and real Meta approvals remain outstanding.