Slack integration
Three steps: create a branded agent → install into Slack → test send & receive
1
Create your branded agent
We create a Slack app carrying your brand name and icon automatically (platform-hosted, zero setup for the customer)
Advanced: use my own config token instead of platform hosting
Go to api.slack.com/apps, hit Generate Token at the top, and grab the token starting with
xoxe.xoxp-.2
3
Test send & receive
Sending needs a target conversation; incoming messages show up live in the Inbound events panel at the bottom
WhatsApp via 360dialog official BSP · one API key · no OAuth
360dialog is a Meta Business Solution Provider: the WABA lives under their Meta app and their host proxies the Cloud API one-to-one, so there is no app to create, no Embedded Signup, and no OAuth round trip. The
D360-API-KEY already identifies the sending number, which is why every path drops the /{PHONE_NUMBER_ID} prefix.1
Credential & sending health
Reads
/health_status, the business profile and the approved templates — this alone proves the number can send.Set D360_API_KEY in .env, then click.
2
Inbound: point the WABA webhook here
360dialog pushes Meta-format payloads to one URL per number. It must be public https — no localhost, no port, no underscore in the hostname — so run the tunnel first and put it in PUBLIC_BASE_URL.
Inbound endpoint:
No hub.challenge handshake and no body signature here; if D360_WEBHOOK_TOKEN is set it is registered as a request header and enforced on every push.
No hub.challenge handshake and no body signature here; if D360_WEBHOOK_TOKEN is set it is registered as a request header and enforced on every push.
3
Outbound: send a WhatsApp message
Free-form text only works inside the 24h service window, i.e. after the recipient has messaged this number. For a first contact, name an approved template instead.
4
Onboard a client's own number
360dialog does not hand out numbers — each client brings their own. We mint a signup link; they complete Meta Embedded Signup in their browser; we take it from there. If their number already runs the WhatsApp Business App, Coexistence keeps the app and the chat history, with no OTP at all.
Live progress — polls every 3s while a signup is in flight
5
Bind a number you already have
The path that needs no partner credentials. Sign a number up at
hub.360dialog.com as an ordinary client, generate its API key there, and paste it here — we read the number's own phone_number_id, adopt its profile and point its webhook at us. Leave the key blank to adopt the number this panel is already using.6
Tenants & routing
A tenant with its own
phone_number_id routes by number — no tokens, no sticky bindings, no cold-start ambiguity. Tenants without one fall back to shared-number routing via a #ag_id deep link.iMessage · connect & messaging LinqApp · token · no authorization step
Click above to test; the numbers on the account will be listed.
⚠️ Forces
preferred_service=iMessage. The recipient must have iMessage enabled on an Apple device, otherwise it falls back to SMS and will not reach a mainland China number.Inbound · webhook subscription
Linq only pushes to registered target URLs. Until a subscription exists,
/linq/webhook never fires. The URL must be a public https host Linq can resolve — localhost and tunnels that are down get rejected with 1005 invalid target_url.Once subscribed, text the Linq number from your phone and it will appear in the Inbound events panel below.
📋 iMessage numbers / white-label findings from Linq's official docs
1. Numbers cannot be provisioned via API. Straight from Linq's docs: "Numbers are provisioned by your Linq representative — there is no self-serve create or delete endpoint on the V3 API." The V3 API only exposes read-only
2. How to get a number: for testing, a free Linq sandbox account comes with one number; for production or multiple numbers, contact Linq sales/support for manual provisioning.
2b. Reading a chat ≠ being allowed to send from it. A key can return
3. The white-label identity on iMessage is the number — not an app name or icon, since iMessage has no app concept. A dedicated number per customer is the white-label.
4. White-labeling cannot be fully automated here: unlike Slack's
GET /phone_numbers.2. How to get a number: for testing, a free Linq sandbox account comes with one number; for production or multiple numbers, contact Linq sales/support for manual provisioning.
2b. Reading a chat ≠ being allowed to send from it. A key can return
GET /chats rows whose is_me handle it has no send rights on — sending then fails with 403 code 2006 "You do not have permission to send from this phone number". The authoritative check is GET /phone_numbers: if it is empty, outbound is blocked no matter what the chats look like.3. The white-label identity on iMessage is the number — not an app name or icon, since iMessage has no app concept. A dedicated number per customer is the white-label.
4. White-labeling cannot be fully automated here: unlike Slack's
apps.manifest.create, every customer number goes through Linq manually. Worth asking Linq whether a bulk or private provisioning endpoint exists.
WeChat integration Official Account · Open Platform third-party platform
The only WeChat shape with a real hosted-authorization flow, so it is the one that matches the Slack and WhatsApp white-label model: one platform-side component, N customer Official Accounts authorized into it. Personal WeChat has no official API.
1
White-label readiness
Checks the component credentials and whether
component_verify_ticket has arrived — WeChat pushes it every 10 minutes and it cannot be fetched on demandClick above to check.
Set this as the authorization event receiver URL in the Open Platform console:
/wechat/component/callback2
Connect a customer's Official Account
Mints a consent-page link; the customer's Official Account admin scans it and confirms, and we exchange the returned auth_code for a lasting token
The link expires in 10 minutes. Prerequisites need a human: register a third-party platform on the WeChat Open Platform, which requires a verified business and review. Once that exists, every customer connection is automatic.
3
Send a message
Customer-service message, deliverable only within 48 hours of the user's last inbound message. Leaving the selector on the direct account sends with WECHAT_APPID / WECHAT_SECRET instead of a platform-authorized one.
4
Receive messages
Set the message callback URL in the Open Platform console; WeChat substitutes the account's appid for the placeholder
Message callback URL:
Both plaintext URL verification and the encrypted (AES) mode are implemented. An inbound message appears in the Inbound events panel below along with the sender's openid — paste that openid into step 3 to reply.
/wechat/callback/$APPID$Both plaintext URL verification and the encrypted (AES) mode are implemented. An inbound message appears in the Inbound events panel below along with the sender's openid — paste that openid into step 3 to reply.
5
Direct single-account mode (testing only)
Bypasses the third-party platform entirely — set WECHAT_APPID / WECHAT_SECRET in .env to sanity-check network and credentials without any white-label setup
Feishu / Lark integration custom app + self-hosted OAuth
Switch between open.feishu.cn and open.larksuite.com by changing
FEISHU_BASE in .env1
Custom app connectivity
Reads FEISHU_APP_ID / FEISHU_APP_SECRET from .env, exchanges a tenant_access_token, then reads the bot info back
Click above to test.
2
Send a message
Use open_id or email to reach a person, chat_id to reach a group
3
Self-hosted OAuth (user identity)
Redirects to the Feishu consent page, exchanges the returned code for a user_access_token, and reads back the user's open_id — feed that into step 2 to message them
/go/feishu
Add
/feishu/oauth/callback to the redirect URL allowlist first, under Feishu Open Platform → Security settings.4
Receive messages (event subscription)
Open Platform → Events & callbacks → choose "send events to developer server"
Callback URL:
The
/feishu/webhookThe
url_verification handshake is implemented, and the Encrypt Key strategy is supported — just put the Encrypt Key and Verification Token in .env. Subscribe to the im.message.receive_v1 event.5
White-label: store app (multi-tenant)
One branded app installed into N customer tenants: app_ticket → app_access_token → per-tenant tenant_access_token
Same shape as the WeChat third-party platform: Feishu has no API for creating apps, so one branded store app serves every tenant. Listing the app on the Feishu app directory requires review by a human. Once it is live,
app_ticket arrives at the callback above every hour and tenant onboarding is automatic.WhatsApp · Meta direct Tech Provider · Embedded Signup
We are the Tech Provider: the client's WABA is created under their own Meta business and we talk straight to graph.facebook.com. Independent of the 360dialog route — both can stay configured at once. open in its own tab ↗
Telegram integration Bot API · token only
No OAuth, no review, no encryption — the @BotFather token is the whole credential. Multi-tenant means one bot per customer, so every call below accepts that customer's token instead of the one in .env.
1
Connectivity
getMe proves the token; getWebhookInfo shows which inbound mode this bot is in
Click above to test.
2
Send a message
A bot cannot initiate contact: the user must press Start (or the bot must be in the group) first, otherwise this fails with "chat not found"
3
Receive — long polling (works from localhost)
getUpdates pulls instead of being pushed, so no tunnel is needed. Only available while no webhook is registered.
4
Receive — webhook (production)
Registering a webhook makes getUpdates return 409; the two are mutually exclusive
Telegram signs nothing. Set
TELEGRAM_WEBHOOK_SECRET in .env and it is registered as the secret_token, then enforced on every push via X-Telegram-Bot-Api-Secret-Token. Without it, anyone who learns the URL can inject fake updates.Discord integration bot token · OAuth2 install
Outbound is plain REST. Inbound is the awkward part: ordinary messages only arrive over the Gateway WebSocket, so the HTTP paths here are the interactions endpoint (slash commands only) and REST polling.
1
Connectivity
Reads the bot user, the application, and which servers the bot is installed in
Click above to test.
2
Install into a server
Real OAuth2: the customer's server admin opens this link and picks a guild. There is no code exchange — Discord installs on consent.
3
Send
Enable Developer Mode in Discord to copy channel and user ids
4
Receive
Two partial options; neither is a webhook for normal messages
Interactions endpoint:
Plain messages need the Gateway WebSocket plus the privileged MESSAGE_CONTENT intent — a persistent connection this test panel deliberately does not open.
/discord/interactions — paste into the app's Interactions Endpoint URL. Ed25519 verification is implemented (DISCORD_PUBLIC_KEY), including the 401-on-bad-signature probe Discord runs before accepting the URL. It carries slash commands and buttons only.Plain messages need the Gateway WebSocket plus the privileged MESSAGE_CONTENT intent — a persistent connection this test panel deliberately does not open.
LINE integration Messaging API · Module white-label
Two credentials that are not interchangeable: the channel access token signs outbound, the channel secret verifies inbound signatures. Mixing them up is the usual cause of a 401 on every call.
1
Connectivity
/v2/bot/info is the only whoami; also reports quota and the current webhook endpoint
Click above to test.
2
Push a message
Costs quota and only reaches users who added this official account as a friend. Ids are channel-scoped — a userId from another channel will be rejected.
3
Reply with the newest token
Replies are free and bypass the friend requirement — the cheapest proof the round trip works. Message the bot, then click this within a few seconds.
4
Receive (webhook)
Setting the endpoint also asks LINE to probe it and reports the status code LINE itself saw
Callback:
/line/webhook. X-Line-Signature (HMAC-SHA256 over the raw body, base64) is enforced when LINE_CHANNEL_SECRET is set. If the account's response mode is Chat rather than Bot, LINE never fires the webhook at all — switch it in the LINE Official Account Manager.5
White-label: Module channel
One platform-side module attaches to the customer's own channel after they consent at manager.line.biz, returning a token scoped to their channel
/go/line
LINE gates this: a module channel must be reviewed and approved before the authorize URL works for anyone outside the module's own developer account. Until then, one Messaging API channel per customer is the only shippable route.
Facebook Messenger integration Page token · Facebook Login
Same Graph API as WhatsApp, but the sending identity is a Facebook Page and the credential is a page access token a Page admin grants. Two subscriptions must both be in place — app level and page level.
1
Connectivity
Checks the Page, the page-level subscription, the app-level webhook, and the token's scopes in one shot
Click above to test.
2
Onboard a customer Page
Facebook consent → user token → one page access token per Page they administer → subscribe our app to each Page
/go/messenger
Add
/messenger/oauth/callback to Valid OAuth Redirect URIs under the app's Facebook Login settings first. Scopes needed: pages_messaging (send) and pages_manage_metadata (subscribe) — without the second one onboarding looks fine but inbound stays silent forever.3
Send to a PSID
PSIDs are page-scoped and cannot be looked up — the user has to message the Page first
4
Receive (webhook)
App dashboard → Webhooks → page object
Callback URL:
Verify token: whatever is in
/messenger/webhookVerify token: whatever is in
META_WEBHOOK_VERIFY_TOKEN (shared with the WhatsApp webhook). The GET handshake and X-Hub-Signature-256 verification are both implemented. Subscribe the fields messages, messaging_postbacks, message_deliveries, message_reads.Microsoft Teams integration Azure Bot Service · AAD · signed activities
There is no "Teams API". A bot registers with Azure Bot Service and Teams relays through it — so there is no whoami, and outbound depends on inbound: sending needs a conversation reference, which only an inbound activity can supply.
1
Connectivity
An AAD token for the Bot Framework scope is the only proof the credentials are self-consistent
Click above to test.
2
Wire up the bot
Register the messaging endpoint on the Azure Bot resource, then sideload an app package into Teams
Messaging endpoint:
Inbound activities are validated as real JWTs: signature against the Bot Framework JWKS, then
/teams/messages — paste into Azure portal → your Azure Bot → Configuration.Inbound activities are validated as real JWTs: signature against the Bot Framework JWKS, then
iss, aud = your app id, exp, and the serviceUrl claim matched against the activity body.3
Reply into a conversation
Populated from inbound activities. Empty until someone messages the bot in Teams — that is the expected order here, not a bug.
4
Proactive 1:1
Creates a fresh personal chat. Still not cold outreach: the Teams user id (29:…) and tenant id both come from an earlier inbound activity, and the app must be installed for that user.
5
Incoming Webhook fallback (send-only)
One channel, no bot, no AAD — proves the network path in seconds
Needs
TEAMS_INCOMING_WEBHOOK. Microsoft has announced the retirement of Office 365 connectors in Teams — this is a smoke test, not an integration.📥 Inbound messages / events Slack · iMessage · WeChat · Feishu · Telegram · Discord · LINE · Messenger · Teams
Message any connected channel and it shows up here live. Requires the public tunnel to be up, otherwise nothing can be pushed in.
No events yet.