Gateway (Outbound)

The Gateway is a local daemon that subscribes to the bridge core's real-time stream (SSE) and relays inbound traffic to multiple sinks. Keep the CLI running and consultations flow into your channels (Discord/Slack) or webhooks.

CLI Gateway vs hosted Gateway

The CLI Gateway is a daemon that runs on your machine (laptop/server). If you can't keep the CLI running at all times, use the hosted Gateway (configured in TalkBridge Center), which the server runs on your behalf — in addition to signed webhooks, it comes with persistent retry and dedupe (resumes after restart). → Inbound webhook

Lifecycle

talkbridge gateway start     # start the background daemon
talkbridge gateway status    # liveness + log path
talkbridge gateway restart   # apply configuration changes (restart)
talkbridge gateway stop      # stop

• start only launches when at least one outbound sink (Discord/Slack/Webhook) is configured (configure it in setup).
• The daemon detaches into the background and records its PID and logs to files.

File	Location
PID	~/.bridge-agent/gateway.pid
Log	~/.bridge-agent/gateway.log
Thread mapping	~/.bridge-agent/thread-map.json, slack-thread-map.json
Replay offsets	~/.bridge-agent/stream-offsets.json

Sink types

The Gateway fans out to multiple sinks simultaneously — if one fails, the rest keep working.

Sink	Description
Webhook	Relays inbound traffic received over SSE as a POST (JSON) to the specified URL. For self-built receivers. The console-log option lets you inspect the payload format
Discord	One consultation = one channel thread, relayed in both directions (a human agent replies in the thread → sent out via Kakao)
Slack	Socket Mode (no public URL needed), xoxb (outbound) + xapp (inbound)

Consultation sync policy

Discord/Slack sync (two-way consultation) requires a BrandWrite key + a single brand. If this is not met, consultation sync is disabled and only the Webhook relay continues.

Webhook sink signing

The CLI Webhook relay supports HMAC signing — when you set a signing secret, signature headers are attached to requests, and the receiving server verifies them the same way as with the hosted Gateway (same signing scheme → use the recipes in the Signature verification document as they are).

# Configure the webhook sink with a signing secret (use the same secret on both sides)
talkbridge setup --webhook-url https://hook.example.com --webhook-secret whsec_xxx --webhook-brand mybrand

• When a secret is set, the X-Bridge-Signature, X-Bridge-Event, X-Bridge-Timestamp, and X-Bridge-Delivery-Id headers are attached.
• When the secret is left empty, the relay is unsigned (for local/trusted-network testing).

A signature is only meaningful if the receiver verifies it

If only the sending (relay) side signs and the receiving server does not verify, the signature is pointless — anyone who knows your URL can send forged requests. Be sure to verify the signature on the receiving server. → Signature verification

CLI relay vs hosted — differences in delivery reliability

The CLI relay's retry is lightweight (in-memory) — on a transient failure it tries up to 3 times with a 1s → 3s backoff, and the process must stay alive during that time. If you need persistent at-least-once delivery (resuming after a Gateway restart) and server-side dedupe, use the hosted Gateway. Idempotent handling on the receiving side (X-Bridge-Delivery-Id) is recommended for both. → Delivery reliability

Configuration

Configure sinks in the Outbound step of setup (TUI) or with non-interactive flags.

# Example: configure a signed webhook sink, then start the Gateway
talkbridge setup --webhook-url https://hook.example.com --webhook-secret whsec_xxx --webhook-brand mybrand
talkbridge gateway start
talkbridge gateway status