What is a social inbox unifier?

A small serverless system that pulls all your social and messaging DMs into one place so nothing is missed. Messages from each platform — Instagram, Facebook, WhatsApp — land in one shared queue; the system labels each by topic and urgency, removes duplicates, and routes each to the right person, so a small team answers from one queue instead of five apps. A human writes every reply. The system only gathers, labels, and routes. Nothing is auto-answered.

How much does it cost to run?

About $3/month at typical small-business volume (around 1,500 messages a month). The fixed cost is essentially zero. The variable cost is dominated by the per-message labeling call to Bedrock Haiku 4.5; everything else — the webhooks, the queue, the dedupe — is fractions of a cent each. At 10,000 messages a month the bill lands around $12.

Which AWS services does it use?

Lambda (Python 3.14, arm64) with Function URLs for the platform webhooks and the reply endpoint, SQS (with a dead-letter queue) for the work queue, DynamoDB on-demand, S3 (with versioning), EventBridge Scheduler for the daily digest, Secrets Manager and Parameter Store for config, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for the per-message labeling. No API Gateway, no NAT Gateway, no always-on compute.

Where do the replies happen?

In a shared web inbox your team controls. Each conversation shows up as one thread with its platform, its labels, its assigned teammate, and the full back-and-forth. A person reads it and types the reply. On send, the reply goes back out through the same platform the customer used. The system never writes or sends a reply on its own.

Sparingly, and never to answer. Bedrock Haiku 4.5 reads each incoming message once and returns a short label set — topic, urgency, and language — plus a one-line summary. That label set is what powers the routing and the queue sorting. The dedupe and the routing rules themselves are plain Python. No model writes a reply, and no reply is sent without a person.

How does it avoid showing the same message twice?

Every incoming message gets a fingerprint built from the sender, the platform, and a hash of the text. Before a message is added to the queue, the system checks that fingerprint against a short-lived DynamoDB table. If the same message already arrived — a common case when a platform re-delivers a webhook, or a customer messages you on two channels at once — the duplicate is dropped and linked to the original thread instead of opening a second one.

What happens when nobody answers in time?

Each urgency level has a target response time in the rules doc — urgent gets minutes, normal gets hours. If a thread sits unassigned or unanswered past its target, the system re-routes it to a backup teammate and posts it in a team channel so it does not fall through. A daily digest also lists anything still open. None of this sends a reply — it just makes sure a human sees the message.

Series · 7 parts Published June 14, 2026

Social inbox unifier

A serverless system that pulls every Instagram, Facebook, and WhatsApp DM into one shared queue so nothing is missed. It labels each message by topic and urgency, removes duplicates, and routes each to the right teammate — so a small team answers from one place instead of five apps. A human writes every reply; the system only gathers, labels, and routes. Seven posts on the same system — one diagram at a time — with an engineering reference at the end.

01

A social inbox unifier on AWS for a few dollars a month

The whole system on one page — the platform connectors, the labeler, and the shared inbox, plus the rule that a human writes every reply.
02

How a DM reaches the unified inbox

Each platform sends new messages to a webhook; a small connector turns every platform’s format into one common shape and drops it on a single work queue for the rest of the system to handle.
03

How a DM gets labeled and deduped

One Bedrock call reads the message and returns topic, urgency, and language. A fingerprint check drops re-delivered or cross-channel duplicates before they ever open a second thread.
04

How a DM finds the right teammate

Routing per topic, working hours, fair load-sharing, a backup teammate, and the four guardrails between a labeled message and it landing in the right person’s queue.
05

How a DM gets answered

Three actions in the shared inbox: a person sends the reply, reassigns the thread, or closes it. Every reply is human-written and goes back out through the same platform. Every action is logged.
06

What the social inbox unifier costs

A few dollars a month at SMB volume. The hot path is plain Python; the only model call is one cheap label per message, and only on real new messages.
07

Engineering reference: the social inbox unifier architecture

Same system, drawn purely for engineers. Service names, resource identifiers, region, Bedrock model IDs, Lambda inventory, IAM scopes, the webhook setup, SQS config, and the DynamoDB schemas.

What is a social inbox unifier?: A small serverless system that pulls all your social and messaging DMs into one place so nothing is missed. Messages from each platform — Instagram, Facebook, WhatsApp — land in one shared queue; the system labels each by topic and urgency, removes duplicates, and routes each to the right person, so a small team answers from one queue instead of five apps. A human writes every reply. The system only gathers, labels, and routes. Nothing is auto-answered.
How much does it cost to run?: About $3/month at typical small-business volume (around 1,500 messages a month). The fixed cost is essentially zero. The variable cost is dominated by the per-message labeling call to Bedrock Haiku 4.5; everything else — the webhooks, the queue, the dedupe — is fractions of a cent each. At 10,000 messages a month the bill lands around $12.
Which AWS services does it use?: Lambda (Python 3.14, arm64) with Function URLs for the platform webhooks and the reply endpoint, SQS (with a dead-letter queue) for the work queue, DynamoDB on-demand, S3 (with versioning), EventBridge Scheduler for the daily digest, Secrets Manager and Parameter Store for config, CloudWatch Logs (7-day retention), AWS Budgets, and Bedrock (Claude Haiku 4.5 via Global cross-Region inference) for the per-message labeling. No API Gateway, no NAT Gateway, no always-on compute.
Where do the replies happen?: In a shared web inbox your team controls. Each conversation shows up as one thread with its platform, its labels, its assigned teammate, and the full back-and-forth. A person reads it and types the reply. On send, the reply goes back out through the same platform the customer used. The system never writes or sends a reply on its own.
Does it use AI?: Sparingly, and never to answer. Bedrock Haiku 4.5 reads each incoming message once and returns a short label set — topic, urgency, and language — plus a one-line summary. That label set is what powers the routing and the queue sorting. The dedupe and the routing rules themselves are plain Python. No model writes a reply, and no reply is sent without a person.
How does it avoid showing the same message twice?: Every incoming message gets a fingerprint built from the sender, the platform, and a hash of the text. Before a message is added to the queue, the system checks that fingerprint against a short-lived DynamoDB table. If the same message already arrived — a common case when a platform re-delivers a webhook, or a customer messages you on two channels at once — the duplicate is dropped and linked to the original thread instead of opening a second one.
What happens when nobody answers in time?: Each urgency level has a target response time in the rules doc — urgent gets minutes, normal gets hours. If a thread sits unassigned or unanswered past its target, the system re-routes it to a backup teammate and posts it in a team channel so it doesn’t fall through. A daily digest also lists anything still open. None of this sends a reply — it just makes sure a human sees the message.

All posts

Frequently asked questions

Other series