Guide
Go live
Production readiness requires connected channels, signed webhooks, scoped credentials, audit visibility, and a verified reply loop from inbound customer event to outbound message delivery. Complete each stage before moving to the next. Skipping stages is the primary cause of production incidents.
Stage 1: Channel connection verified
Confirm the WhatsApp channel is active and message events are flowing. Use the channel health endpoint to validate.
GET /v1/atlas/channels/{channel_id}
# Confirm: status = "active", last_health_check is recent- Send a test message from a personal WhatsApp to the business number.
- Confirm a
conversation.createdevent arrives at your webhook. - Confirm your webhook returns
200 OKand the conversation appears in context.
Stage 2: Webhook signature verification deployed
Verify that your production webhook handler rejects unsigned payloads. Use the Atlas webhook test tool or send a manually crafted request without the signature header.
# Should return 401 Unauthorized
curl -X POST https://your-server.com/atlas/events -H "Content-Type: application/json" -d '{"event_type":"conversation.created"}'
# Should return 200 OK
curl -X POST https://your-server.com/atlas/events -H "Content-Type: application/json" -H "Atlas-Signature: <valid_hmac>" -d '{"event_type":"conversation.created"}'Stage 3: Production credentials scoped
Rotate all test credentials into production-specific credentials with least-privilege scopes. Never use sandbox tokens in production. Each environment (sandbox, staging, production) must have its own distinct token.
atlas.sessions.readRead session transcriptsatlas.sessions.writeCreate sandbox sessions (non-production only)atlas.events.readConsume inbound events via webhookatlas.actions.writeSubmit replies and draftsatlas.knowledge.readGrounding knowledge readsatlas.knowledge.writeProduction knowledge managementStage 4: Audit and approval visibility
Verify that action history, approval states, and agent decisions are visible in the Atlas audit trail. For policy-gated actions (e.g., issuing a refund, assigning to a specific owner), confirm that the approval workflow fires correctly and operators receive notifications.
GET /v1/atlas/runs/{run_id}
Response: {
"run_id": "run_01HXAB",
"session_id": "sess_01HX9Z",
"iteration": 2,
"intent": "refund_request",
"status": "pending_approval",
"tools_called": ["retrieve_knowledge", "evaluate_incentive_policy"],
"approval_required": true,
"approval_state": "pending",
"created_at": "2026-05-21T10:30:00Z"
}Stage 5: Full reply loop verified
Execute a complete end-to-end test with a real device. This is the final gate before live traffic.
- Send a message from a personal WhatsApp to the business number.
- Confirm your webhook receives the
conversation.message_receivedevent. - Confirm your agent calls
GET /v1/atlas/context/{id}andGET /v1/atlas/knowledge. - Confirm your agent submits a reply via
POST /v1/atlas/actions. - Confirm the reply appears in the customer's WhatsApp within 30 seconds.
- Confirm a
conversation.message_deliveredevent is received at your webhook.