Livepeer Agent · Discord Go-Live · Your side

Flip on the Discord onboarding bot

The Discord admin has created the app and sent you four values. This is the ~5 minutes on our side: put them in Vercel, deploy, register the command, flip the flag, test. The bot code, endpoint, pipeline, and email are already built and merged — nothing to write.

Time ~5 minYou need the Vercel project + the four values

What the Discord admin handed you

Checklist

  1. Add the env vars in Vercel — flag OFF

    Project → Settings → Environment Variables (Production + Preview). Add the three secrets and set the flag to 0 for now so nothing goes live before you've tested:

    DISCORD_APP_ID             = <Application ID>
DISCORD_PUBLIC_KEY         = <Public Key>
DISCORD_BOT_TOKEN          = <Bot Token>      # mark as Sensitive
DISCORD_ONBOARDING_ENABLED = 0               # flip to 1 in step 4

    No channel IDs are needed — the bot replies in the thread where /announce was run.

  2. Redeploy, then tell the Discord admin to save the endpoint URL

    Redeploy so the endpoint picks up the keys. The endpoint is:

    https://agent.livepeer.org/api/discord

    Once the deploy is green, tell the Discord admin to paste that into Interactions Endpoint URL (their step 6). It only verifies after this deploy, because Discord's signed test needs DISCORD_PUBLIC_KEY to be live.

  3. Register the slash commands

    The command-registration endpoint reads the app ID + bot token from the env you just set. One call:

    curl -X POST https://agent.livepeer.org/api/discord/setup \
  -H "Content-Type: application/json" -d '{}'
# → {"ok":true}   (registers /announce and /deactivate)

    These register globally (up to ~1h to appear everywhere). To have them show instantly in the admin's server, pass the guild ID they gave you — or just wait the hour. Re-running is harmless (idempotent).

  4. Flip the flag on

    Set DISCORD_ONBOARDING_ENABLED = 1 and redeploy. Until now the endpoint verified pings but 200-noop'd every command; this is the switch that makes /announce actually onboard.

  5. Verify the loop

    In the server, run /announce with a real discovery URL (use a known-good one, e.g. a test orch). You should see the modal open, a thread created, and an onboarded / skipped summary posted back. Then confirm in Claude Desktop with the admin MCP: "list the community orchestrators" — the new one should appear at registered.

Done. A provider now self-serves: /announce → their healthy caps land registered and routable via merit + admission, and they get an email. This closes the last manual gap — the same orch_onboard pipeline you run by hand in Claude Desktop, now behind a Discord command.

Two things to know about the trust model

/announce auto-registers — it does not auto-promote to live. New caps land at registered (routable through the admission list), not verified-live. Promotion to live, and removing a bad actor, stay admin-only — from Claude Desktop (orch_update / "deactivate X") or the /deactivate command. So keep an eye on "who's registered" after you open it up.
Control who can announce. Anyone who can use slash commands in the server can run /announce. If you want a gate, ask the Discord admin to restrict the command to a single onboarding channel (Server Settings → Integrations → the bot) and limit who can post there.

Env var reference

VarFromPurpose
DISCORD_APP_IDDiscord adminIdentify the app; register commands; send follow-ups
DISCORD_PUBLIC_KEYDiscord adminVerify Discord's signed requests (endpoint won't go green without it)
DISCORD_BOT_TOKENDiscord admin secretAuthenticate command registration + bot actions
DISCORD_ONBOARDING_ENABLEDYou1 = live · 0 = endpoint no-ops (your kill switch)
Rollback / pause. Set DISCORD_ONBOARDING_ENABLED = 0 and redeploy — the endpoint stays up and signature-verifies, but every command becomes a no-op. No need to touch Discord or delete anything.
The Discord-side setup (app, bot, invite, endpoint URL) is the Discord admin's guide. Onboarding internals (probe → classify → register → email) are the orch_onboard pipeline — the same one in the admin MCP guide.