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.created event arrives at your webhook.
  • Confirm your webhook returns 200 OK and 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 transcripts
atlas.sessions.writeCreate sandbox sessions (non-production only)
atlas.events.readConsume inbound events via webhook
atlas.actions.writeSubmit replies and drafts
atlas.knowledge.readGrounding knowledge reads
atlas.knowledge.writeProduction knowledge management

Stage 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.

  1. Send a message from a personal WhatsApp to the business number.
  2. Confirm your webhook receives the conversation.message_received event.
  3. Confirm your agent calls GET /v1/atlas/context/{id} andGET /v1/atlas/knowledge.
  4. Confirm your agent submits a reply via POST /v1/atlas/actions.
  5. Confirm the reply appears in the customer's WhatsApp within 30 seconds.
  6. Confirm a conversation.message_delivered event is received at your webhook.

Production go-live checklist

Channel status is active
Webhook rejects unsigned requests with 401
Webhook handler is idempotent (duplicate event_id handled)
Production token is scoped to least-privilege scopes only
Audit trail shows all action history
Approval workflow fires for policy-gated actions
End-to-end reply loop confirmed on real device
Template message quality rating is Medium or above
Alert set up for message_failed events
Contact email or phone visible in WhatsApp Business profile