Customer-authorized connection
Begin with a named workspace and project. The account owner follows the available connection path, while Moira preserves the authorization and recovery context for the product team.
Messaging operations
Turn messaging delivery into an observable product workflow.
Give teams a clear route from a customer-controlled connection through message lifecycle events, delivery evidence, and account recovery.
WhatsApp connection architecture
Choose a connection path that fits the product
Keep authorization, account health, delivery state, and recovery in the same product story. The connection route stays customer-controlled and project-aware from the start.
Operational message path
Model the workflow around what a team needs to see: connection health, delivery evidence, incoming events, and the next safe action when state changes.
The product workflow
A connection should leave an operator with evidence, not questions.
Explore the surfaces a connected product needs after setup: message context, group conversations, controlled workflow steps, and realtime event evidence.
1 of 4
Conversation operations
Bring message state into the product surface that needs it.
Show the originating account, customer context, attachment state, and delivery state evidence together so a team can act without switching between systems.- Account context attached
- Event evidence retained
- Recovery path visible
Conversation contextObserved
01
Proposal context attached
02
Delivered state received
03
Recovery route available
Connection control plane
Build the integration around a real operating surface.
The customer console gives teams a clear place to check a connection, inspect account health, use project-scoped credentials, and trace the next recovery action.
Explore the product
Use cases
WhatsApp use cases
Shape the connection around the product experience your users already know—then keep provider and project context visible underneath it.
MMaya ChenNew conversation context
DDaan BakkerFollow-up requires review
AAmara SinghAccount signal updated
ATS publisher
Keep candidate conversations, connection health, and recruiter actions in one reviewable workflow.
Explore use caseMMaya ChenNew conversation context
DDaan BakkerFollow-up requires review
AAmara SinghAccount signal updated
CRM publisher
Give account teams message context beside the customer record, stage, and next best action.
Explore use caseMMaya ChenNew conversation context
DDaan BakkerFollow-up requires review
AAmara SinghAccount signal updated
Outreach publisher
Make each communication step accountable to project scope, provider state, and the intended operator.
Explore use caseDeveloper integration
Design the event contract before the workflow is live.
A practical integration has an explicit project boundary, a connection owner, an event identifier, and a recovery route. Keep those decisions in code and in the customer-facing interface.
Read developer documentationconst event = await moira.events.verify({
projectId, provider: "whatsapp",
eventId: request.headers.get("x-moira-event-id"),
});
if (event.state === "attention_required") {
await queueRecoveryReview(event);
}Trust work in progress
Security and compliance status
These are current in-progress programs, not completed certifications, compliance guarantees, or a substitute for your own assessment.
Integration questions
WhatsApp integration FAQ
Answers are deliberately specific about operational boundaries, not sales promises.
How does a WhatsApp connection begin?
A workspace member starts in the intended project context. The live provider registry determines the available connection route and the customer sees the associated account-health and recovery state in the console.
Does this page guarantee a particular WhatsApp capability?
No. This page describes the product architecture. Actual availability depends on the configured provider path, account state, workspace policy, entitlement, and provider terms at the time of use.
How are delivery outcomes represented?
Moira is designed to keep provider outcomes and event references visible beside the workflow. Product teams can distinguish a requested action, a reported event, and an attention-required state rather than reducing them to one generic status.
Can product teams work with group conversations?
Where the selected connection and provider policy support it, group context is represented with its workspace and project boundary so teams can investigate an outcome without losing the originating account context.
What is the webhook model?
Webhook-oriented integrations should preserve an event identifier, signed-delivery boundary, and retry context. Downstream systems should use those records to make a measured recovery decision rather than blindly replaying an uncertain action.
How are attachments and message context handled?
Attachment and message metadata remain scoped to the selected workspace and project. The connection surface is designed to expose the operational context needed for a workflow without presenting it as an unrestricted contact-data repository.
What is Moira’s current security and privacy posture?
Moira is progressing through a SOC 2 Type II audit and an ISO 27001 certification program, while operating a GDPR-focused privacy program. These are in-progress initiatives, not completed certifications or a guarantee of suitability for a particular use case.
Where can an engineering team start?
Start by defining project scope, the customer-owned connection route, the event contract, and a recovery model. The customer console and API documentation are the right next surfaces for a live readiness check.
Provider path
How the provider path stays operable
A useful integration does not stop at authorization. It makes the current boundary, account state, and recovery route legible inside your product.
WhatsApp workflowIllustrative
- Delivery and event state
Capture the progression from requested action to accepted, delivered, or attention-required state as a visible workflow.
- Keep the connected account beside the message
Account ownership and project scope stay legible when a team investigates an outcome or handles a support question.
- Use webhooks as evidence, not a hidden implementation detail
Surface signed delivery, retries, and event identifiers so a downstream workflow can make a measured decision.
Start with the right boundary
Connection modes
Customer-controlled business connection
Make the account owner, project purpose, and authorization route explicit before a messaging workflow is enabled.
Delivery state
Carry a normalized message outcome and delivery event reference into the product instead of relying on an opaque send result.
Product workflows
From connection to an operable outcome
Message lifecycle
Delivery and event state
Capture the progression from requested action to accepted, delivered, or attention-required state as a visible workflow.- Traceable delivery evidence
- Provider event context
- Clear customer feedback
WhatsApp event stream
Account state projected
evt_01Event envelope received
evt_02Delivery evidence recorded
evt_03Customer operations
Keep the connected account beside the message
Account ownership and project scope stay legible when a team investigates an outcome or handles a support question.- Workspace isolation
- Account health beside activity
- Auditable operational trail
WhatsApp account Health visible
Connection stateObserved
Project boundaryScoped
Recovery routeReady
Realtime integration
Use webhooks as evidence, not a hidden implementation detail
Surface signed delivery, retries, and event identifiers so a downstream workflow can make a measured decision.- Webhook delivery status
- Idempotent event handling
- Retry-aware recovery
WhatsAppContextEvents
01
Connected account context attached
02
Workflow event ready for review
03
Recovery state is visible
Capability boundaries
Capability map
Every category communicates its readiness state in words, not colour alone.
Connection and health
- Project-scoped connection state
- Account-health signals
- Reconnect guidance
Messaging workflows
- Customer-controlled messaging intent
- Provider-aware delivery state
- Policy-aware operation
Event operations
- Normalized event envelope
- Signed webhook delivery
- Traceable retry context
Build with context
Developer resources
Keep connection state, event evidence, and security boundaries in the implementation path from the start.
WhatsApp connection architectureStart with project context, the hosted connection route, and an explicit account-health state.Event delivery and recoveryUse signed webhook delivery, event identifiers, retries, and account state to make failures actionable.Connection security boundaryKeep credentials, provider consent, API-key scope, and project isolation separate from browser-visible code.
Data-handling boundaryMessage and account data remain scoped to the selected workspace and project. Event records are designed for operational traceability, not an unbounded contact-data store.
Architecture questions
Frequently asked questions
How does a WhatsApp connection start?
A workspace member initiates a connection in the intended project context. Moira presents only the authorization path and capability state that the control plane permits.
What happens when messaging policy or account readiness changes?
The account health and capability state becomes visible in the customer console. A customer or operator can follow the specific reconnect, approval, or policy-recovery route instead of retrying a blind action.
Is availability guaranteed by this page?
No. This page explains the integration architecture. The live provider registry, workspace policy, and provider terms decide whether a connection or action is available at execution time.
Start with verified readiness