Platform setup guide

Add a connection under KEDA → Bot Studio → select your bot → Platform connections. This guide separates operations in the official platform from operations in KEDA. Official portals and API documentation were checked on October 23, 2026; platform menu names may change.

Before you start

1. Create a KEDA bot, select an available model, set its instructions and budgets, save and complete AI review. You can save a platform connection before publishing; real messages require a published bot, an enabled connection and available hosting.
2. Fund your wallet. Platform messages use the bot's model, tool and database pricing and spending limits.
3. Choose who can use the bot. Connections are private by default: enter allowed user IDs, separated by commas. You may explicitly select Allow everyone to use this bot. Accessible platform users can then trigger calls against your wallet and budgets; platform restrictions still apply.
4. Default QQ connections need AppID and AppSecret; Discord needs a bot token. KEDA maintains and reconnects the connection. Advanced HTTP modes support existing callback integrations.
5. Keep tokens, AppSecrets and signing secrets in their credential fields. KEDA encrypts platform credentials and does not return them after saving. To rotate credentials, remove the old connection and create one with the current credentials.

QQ

Official sources: QQ quick setup, official QQ bot integration guide, authentication and events and WebSocket.

In the official QQ portal

1. Open QQ quick setup and sign in with your QQ account.
2. Under My bots, create a bot as directed by the portal, or select an existing bot.
3. Copy its AppID, reveal AppSecret and copy that value. Both must belong to the same bot.
4. Use the bot card's chat QR code to open the bot conversation in mobile QQ. For group use, the group owner can add the created bot using a current QQ client and configure its permissions.

Connect and test in KEDA

1. Open Platform connections → Add platform → QQ.
2. Enter Application ID (AppID) and Application secret (AppSecret). QQ defaults to Persistent connection (recommended), with no callback URL to configure.
3. Set access. A private allowlist uses user_openid or member_openid from QQ events, rather than QQ account numbers. If you do not have an openid, check the bot's accessible audience in QQ before deciding whether to allow everyone. KEDA will not open access automatically.
4. Save, complete review and publish the KEDA bot. Keep the connection enabled.
5. Wait for Connected to QQ, then send a direct message or explicitly mention the bot in a group. Inspect KEDA run history for receipt, completion and delivery.

There is no callback field on quick setup

The quick setup screen provides AppID and AppSecret for the default persistent connection. KEDA obtains an access token, connects to the official WebSocket and maintains heartbeats and reconnection. You do not need to find or fill a callback URL.

For an existing traditional HTTP integration, expand Advanced settings (optional) and select HTTP callback. Only if the official QQ application exposes an HTTP event callback setting, copy the URL from the KEDA connection card there, complete verification and subscribe to the required message events. Keep the default mode for the quick setup page without this setting.

QQ troubleshooting

• QQ says the bot is offline: Publish the KEDA bot, enable its connection and wait for the online state. Check that AppID and AppSecret identify the same bot.
• Invalid credentials: Copy the current values from QQ. A reset AppSecret requires recreating the KEDA connection with the new secret.
• Duplicate application: Use one active KEDA persistent connection per AppID. Disable duplicates and check other hosting services for conflicting use.
• Online without replies: Test with a DM or explicit group mention. Check QQ usage permissions and the KEDA allowlist; a QQ number is not an openid. Then inspect wallet, budget, review and delivery errors in run history.

Discord

Official sources: Developer Portal, creating and installing an app, Gateway and message intents, bot authorization and Get Current Application.

In the official Discord portal

1. Choose New Application, name it and create it, or open an existing application.
2. Open Bot. Obtain its Bot Token in the Token section; use Reset Token when first generating it or replacing a lost token, and complete Discord's confirmation. Resetting invalidates the old token, so other services using it need an update.
3. Open Installation and enable Guild Install in Installation Contexts. A member with permission to manage the destination server must complete installation.
4. Leave Message Content Intent at its default setting initially. Direct messages and explicit channel mentions are the default KEDA flow.

Connect and test in KEDA

1. Choose Platform connections → Add platform → Discord, and enter only the Bot Token. KEDA verifies it using official GET /applications/@me and detects the application ID.
2. Set access. For private connections, use Discord user IDs. Enable User Settings → Advanced → Developer Mode, then right-click the user or open their additional actions and choose Copy User ID. Usernames and nicknames do not serve as user IDs.
3. Save, then click Add to a Discord server on the connection card. Select the server and authorize in Discord. This official bot authorization flow does not require an OAuth callback URL.
4. The install link requests View Channel, Send Messages and Read Message History. Check channel-specific permission overrides, and use a normal text channel for the first test.
5. Complete AI review and publish. Wait for Connected to Discord, then mention the bot in the server or send it a direct message. If server privacy settings prevent DMs, test a channel mention first.
6. Check KEDA run history to confirm receipt and successful delivery.

Read ordinary channel messages (optional)

To let the bot participate based on keywords or context without a mention, enable Bot → Privileged Gateway Intents → Message Content Intent in Developer Portal and save. When adding the KEDA connection, expand Advanced settings (optional) and check that the intent is enabled. Also choose the desired dialogue participation mode in bot settings. Apps subject to Discord verification or intent review must meet those requirements.

The KEDA checkbox does not grant Discord permissions. Leave it off when ordinary channel content is unnecessary; test DMs and explicit mentions using the default flow first.

Existing /ask HTTP applications (advanced)

Select Advanced settings → Discord connection mode → HTTP command callbacks (existing /ask apps). Enter Application ID and Public Key from General Information in Developer Portal. Save, then copy the KEDA callback into the application's Interactions Endpoint URL and complete verification.

Register /ask separately using the official application command API, with a string option named message, and authorize application commands for the destination server. KEDA does not register /ask automatically in this mode. This mode receives HTTP command interactions; create a default bot-token connection for the usual chat flow.

References: Application Commands API and receiving and verifying interactions.

Discord troubleshooting

• Invalid bot token: Use the current Token from the Bot page. Recreate a connection after a reset. Application ID, Public Key and Client Secret cannot substitute for a bot token.
• Server missing in authorization: Check the current account's server management permissions and the application's Guild Install support. Private bots follow Discord's owner-installation rules.
• Connected but ordinary messages are absent: Test an explicit mention first. For ordinary messages, check both Discord Message Content Intent and KEDA's advanced option.
• Messages arrive but replies fail: Check channel visibility, sending and history permissions and overrides. Threads require the separate Send Messages in Threads permission; test in a normal text channel first.
• Intent or duplicate-token state: Fix official intent permissions or disable duplicate active KEDA connections.

Telegram

Official sources: @BotFather, creating and managing bots and Privacy Mode and group messages.

In the official Telegram client

1. Open the official @BotFather, send /newbot, and follow its naming and username instructions.
2. Copy the returned Bot Token. For an existing bot, use /mybots to manage its API token. Reset tokens also need updating in the KEDA connection.
3. Open your new bot's chat and press Start or send /start. Add the bot to your group when needed.

Connect and test in KEDA

1. Choose Platform connections → Add platform → Telegram, enter the bot token and set allowed user IDs or explicitly allow everyone. Private allowlists use Telegram numeric user IDs.
2. Save, complete review and publish.
3. Click Register Telegram callback on the connection card. KEDA registers the site's URL with Telegram; you do not need to paste a URL into a Telegram portal.
4. Send a DM, then inspect KEDA run history. Test group use with a mention or reply to the bot first.
5. If ordinary group messages are necessary, use BotFather's /setprivacy, check group permissions and re-add the bot as required by Telegram. Select a suitable dialogue participation mode in KEDA as well.

Telegram troubleshooting

• Registration fails: Check the current token and KEDA availability. A missing public origin requires administrator configuration. You can register again to restore the callback.
• DMs work but groups do not: Test a mention or reply, then check permissions and Privacy Mode. KEDA does not respond to every ordinary group message by default.
• Another service stops receiving: Use one receiving service for the bot. Telegram Webhooks and getUpdates polling cannot be active together.
• Unknown user ID: Usernames and bot IDs do not replace numeric user IDs. Obtain them from your own official Bot API update data; keep tokens out of third-party ID services. Choose the intended access scope explicitly before testing.

Webhook

This mode connects your own server-side application and has no third-party bot portal.

1. Choose Add platform → Webhook, set access and save.
2. Save the callback URL and the one-time signing secret immediately. Store the secret on the caller's server. Remove and recreate the connection if it is lost.
3. Publish the KEDA bot. Generate a unique event_id, sender, conversation and message, then compute HMAC-SHA256 over the exact JSON body you send.
4. Send X-Bot-Timestamp as Unix seconds and X-Bot-Signature as the signature of timestamp + "." + body. Synchronize clocks; timestamps are accepted from five minutes in the past to 30 seconds in the future.
5. After receiving run_id, sign a POST request to the connection's /results URL with the same secret. Generate a new timestamp and signature for each query; inspect state, output and cost_cny.

import { createHmac, randomUUID } from 'node:crypto'

const endpoint = process.env.KEDA_BOT_WEBHOOK_URL
const secret = process.env.KEDA_BOT_WEBHOOK_SECRET
async function signedPost(url, value) {
  const body = JSON.stringify(value)
  const timestamp = String(Math.floor(Date.now() / 1000))
  const signature = createHmac('sha256', secret)
    .update(timestamp + '.' + body)
    .digest('hex')
  const response = await fetch(url, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'X-Bot-Timestamp': timestamp,
      'X-Bot-Signature': signature,
    },
    body,
  })
  if (!response.ok) throw new Error(`Webhook HTTP ${response.status}`)
  return (await response.json()).data
}
const run = await signedPost(endpoint, {
  event_id: randomUUID(),
  sender: 'alice',
  conversation: 'private',
  message: 'Hello',
})
const result = await signedPost(endpoint + '/results', { run_id: run.run_id })
console.log(result.state, result.output, result.cost_cny)

Use 1–120 letters, digits, underscores or hyphens for sender, matching the private allowlist when applicable. Preserve the event ID, sender, conversation and message when retrying the same event. Query again later while the state is queued or running; use the actual returned terminal state.

Troubleshooting

Saved, but no reply

Saving stores credentials and access settings. Check publication, connection enablement, platform state, allowed sender, wallet and budget. After editing instructions, code or grants, follow the UI to save, review and publish again.

Try the KEDA preview first, then send an explicit DM or mention on the platform. No new run usually points to connection, event type or access settings; an existing failed run has its own actionable error.

The connection keeps connecting

Status refreshes automatically. Check current official credentials, duplicate applications/tokens, permissions and hosting availability. Retry later for network or rate-limit problems rather than repeatedly creating duplicate connections. For persistent issues, send support the platform, bot name, time and a status screenshot with credentials removed.

Which connection mode should I choose?

Keep the default for a first QQ or Discord connection. Advanced HTTP modes support existing event callbacks or /ask apps. Telegram callbacks are registered from its KEDA card; Webhook is called by your own signing server.