Solution guide · Proposed implementation. Workflows, contracts, examples and evaluation plans are illustrative proposals, not delivered customer systems, audited integrations or measured results.
An assistant asks a connector to send a message. The network stalls, the request times out, and the assistant tries again. That recovery can produce two messages. What happened after the first request left the application but before its result became visible locally?
This proposed architecture makes caller intent, account ownership and observed side effects inspectable. It does not promise exactly-once delivery. Operators should be able to explain why an operation was dispatched, which account authorized it and what remains unknown.
Start with the account boundary
Carry account identity through every lookup and action. Resolve recipients and attachments inside that account. Never recover from missing identity by choosing whichever session is connected: initialization order after restart must not choose the sender.
Datahase’s pinned provenance/change record documents explicit account IDs, isolated stores and durable sends in its personal-account derivative. That is documentation evidence, not a completed audit or delivered business integration.
Put ownership in database keys and application checks. Query operations by account plus operation key; resolve media through account-scoped queries. Test a valid identifier from the wrong account, not only random invalid IDs.
Define an operation contract before retrying
| Proposed operation field | Meaning |
|---|---|
| Account and operation key | Account-demo-a / intent-204: one caller intent |
| Payload fingerprint | Canonical account, recipient, text, attachment content identity and delivery mode |
| Actor and authorization reference | Operator-demo-2 and approval-demo-31 |
| Remote message ID | Persist before dispatch where protocol supports it |
| State | Prepared, dispatching, unknown or evidence-backed observation |
| Created/observed times | Intent age and last observation, separately tracked |
These identifiers are synthetic. Specify canonicalization: transport timestamps and temporary upload URLs generally do not define new intent. Same key/same fingerprint returns the existing operation; changed payload under that key conflicts. Creating a fresh key after every timeout defeats deduplication.
The Builders’ Library article on idempotent APIs explains caller-provided identifiers and different intent under the same ID. This contract is an original proposal, not copied implementation.
Separate dispatch from observations
Persist intent before network dispatch, with queue insertion in a local transaction where appropriate. A local transaction cannot ordinarily include a remote messaging service.
Use prepared, dispatching and unknown, adding accepted/delivered/read/failed only when supported evidence exists. Retain raw provider status beside its interpretation. After losing a connection, preserve uncertainty; reconcile through supported lookups, later receipts or operator review. Without authoritative lookup, unknown remains unknown rather than success or silent resend.
Acceptance, delivery and reading are distinct observations. None proves understanding or completion of a requested action. A stricter unknown-state workflow reduces duplicate risk but may delay communication while an operator investigates; document that tradeoff.
A synthetic crash worth testing
Intent-204 sends a maintenance notice. Remote acceptance occurs, then the worker crashes before recording the result. Queue visibility later makes the job eligible again.
A naive worker resends. The proposed worker finds the durable dispatch marker and enters reconciliation. A late receipt updates the original operation; another worker sees that same account/key state rather than starting an independent send.
Replay the key with “maintenance at 11:00” instead of “10:00.” Expose a fingerprint conflict. A correction needs its own intent and authorization, not disguise as recovery.
Engineer beyond a durable table
Use transactional uniqueness and a worker lease or comparable ownership mechanism. A lease coordinates local execution; it cannot prove a timed-out remote send never happened.
Handle receipt order without allowing late acceptance to overwrite delivered state. Preserve observation and ingestion timestamps. Account-scope remote-ID indexes and quarantine conflicting matches.
Retaining operations for less than the permitted retry horizon makes old retries appear new. Define retention and reject expired requests rather than silently dispatching. Balance minimal reconciliation evidence against content retention/access rules.
Dashboards should show unknown operations, age and owner, not call every nonfailed operation successful. Log identifiers, transitions and error categories without bodies or credentials.
Evaluate side effects, not just responses
Use a synthetic adapter that fails before persistence, after queue insertion, during dispatch and after acceptance. Restart at each point. Replay receipts twice and backward; change payload under a key; attempt cross-account media access.
Compare observed remote sends against local intents. Track duplicate physical sends, unexplained transitions, unresolved work and evidence-recovery time. Agree gates before testing; favorable average latency cannot replace missing evidence. Harness results cover tested conditions, not a production reliability rate.
Preserve the reference project’s identity
The pinned README identifies an unofficial personal-account client with no Meta affiliation; protocol changes and account restrictions remain possible. The provenance credits the Sealjay starting point and Luke Harries origin, retains upstream MIT notices, identifies whatsmeow and explains GPL-3.0-or-later distribution. Preserve applicable notices and obtain license review before redistribution. No code is reused by publishing this guide.
Use the open-source overview for context. Bring account boundaries and failure cases to discovery before selecting an adapter or promising delivery semantics.
Context, sources and next step
Datahase’s open-source overview and existing personal MCP connection guide provide reference context. The unofficial personal connector is distinct from an official business deployment. Business account setup, policy eligibility, technical adapters, identity, operational staffing and recovery require separate discovery and verification.
Sources checked 5 November 2026 are linked next to relevant statements. Pinned repository documentation describes that exact revision, not an independently completed code audit. Current platform endpoints, policy, categories and commercial terms must be rechecked for an actual implementation. No live messages, personal chats or business bookings were used to validate this design.
Explore Datahase API integration services and discuss this workflow with synthetic events, account ownership, authorization rules and failure cases.