Here is our sign-up app's Cloudflare Worker, src/index.js: (then paste the file) Our club talks on Discord. I want a slash command, /nextshift, that replies with the next shift that still has spots left, handled by this same Worker at the path /discord. Explain the setup in the Discord Developer Portal, how the Worker should verify that requests really come from Discord, how to register the command, and where the bot's secrets go. Use no packages in the Worker if you can.send

This is a good multi-part task. I'll walk through it in order: Portal setup, how verification works, the Worker code, registering the command, and where secrets live.

One reminder up front: you'll be calling Discord's API and running a bot inside their platform, so it's worth glancing at Discord's Developer Terms of Service and Developer Policy to make sure a simple club sign-up bot fits within them (it should — this is exactly what the interactions API is for).

Part 1: Discord Developer Portal setup

1. Go to https://discord.com/developers/applications and click New Application. Name it something like "Garden Shifts".
2. On the General Information page, note two values you'll need:
   • Application ID
   • Public Key (this one isn't secret — it's used to verify signatures, not create them)
3. Leave the Interactions Endpoint URL field blank for now — you'll fill it in after the Worker is deployed, because Discord immediately tests it.
4. Go to the Bot tab, click Add Bot if there isn't one, and copy the Bot Token. This is secret — treat it like a password. You only need it to register the command (Part 4), not while the Worker is running.
5. Go to OAuth2 → URL Generator, check the scope applications.commands (you don't need the "bot" scope just to reply to slash commands), copy the generated URL, open it, and add the app to your club's server.

Part 2: How verification works

Every request Discord sends to your endpoint is signed with a private key only Discord holds. Your Worker checks the signature using the public key from step 2. Two headers arrive with each request: X-Signature-Ed25519 (the signature) and X-Signature-Timestamp. The rule is: take the timestamp joined with the exact raw text of the request body, and check that against the signature.

Two things here are new for you, so I want to flag them rather than use them silently:

• crypto.subtle is part of the Web Crypto API, a built-in cryptography toolkit available in both browsers and Cloudflare Workers. We'll use importKey (load the public key in a usable format) and verify (check the signature).
• parseInt(text, base) reads text as a number in a given base — we need base 16 because the keys and signatures arrive as hex text. It's like Number() but lets you pick the base.

One honest caveat: I'm fairly confident Cloudflare Workers support the algorithm name "Ed25519" with raw-format keys in crypto.subtle, since Cloudflare added this a while back — but I haven't personally run this exact code against Discord's endpoint check. Deploy it, then try setting the Interactions Endpoint URL in the Portal — if Discord reports it can't verify the endpoint, tell me, and we'll fall back to the discord-interactions package (published by Discord itself on npm, widely used) which does the same check.

Part 3: Worker code

Add this to src/index.js:

// checks that a request to /discord was really signed by Discord
async function verifyDiscordRequest(request, publicKeyHex) {
  const signature = request.headers.get("x-signature-ed25519")
  const timestamp = request.headers.get("x-signature-timestamp")
  const body = await request.text() // raw text - the signature covers these exact bytes
  if (signature === null || timestamp === null) {
    return { valid: false, body }
  }
  const key = await crypto.subtle.importKey(
    "raw",
    hexToBytes(publicKeyHex),
    { name: "Ed25519" },
    false,
    ["verify"]
  )
  const message = new TextEncoder().encode(timestamp + body)
  const valid = await crypto.subtle.verify("Ed25519", key, hexToBytes(signature), message)
  return { valid, body }
}

// turns hex text like "1a2b" into raw bytes
function hexToBytes(hex) {
  const bytes = new Uint8Array(hex.length / 2)
  for (let i = 0; i < bytes.length; i++) {
    bytes[i] = parseInt(hex.slice(i * 2, i * 2 + 2), 16)
  }
  return bytes
}

// handles Discord's interactions - both its "are you alive" check and /nextshift
async function handleDiscord(request, env) {
  const { valid, body } = await verifyDiscordRequest(request, env.DISCORD_PUBLIC_KEY)
  if (valid === false) {
    return new Response("Bad signature", { status: 401 })
  }
  const interaction = JSON.parse(body)

  // type 1 is Discord's endpoint check - answer it the same way, every time
  if (interaction.type === 1) {
    return json({ type: 1 })
  }

  // type 2 is someone running a slash command
  if (interaction.type === 2 && interaction.data && interaction.data.name === "nextshift") {
    const shift = await env.DB.prepare(
      `${SHIFT_QUERY} GROUP BY slots.id HAVING COUNT(slotSignups.id) < slots.capacity ORDER BY slots.date, slots.start LIMIT 1`
    ).first()
    const content = shift === null
      ? "No upcoming shifts have open spots."
      : `Next open shift: ${shift.task} on ${shift.date}, ${shift.start}–${shift.end} (${shift.spotsFilled}/${shift.capacity} filled)`
    // type 4 means "reply immediately with this message"
    return json({ type: 4, data: { content } })
  }

  return json({ error: "Unhandled interaction" }, 400)
}

And add a route in fetch, alongside your other routes:

if (method === "POST" && parts.length === 1 && parts[0] === "discord") {
  return handleDiscord(request, env)
}

The HAVING COUNT(slotSignups.id) < slots.capacity line filters after grouping, keeping only shifts that aren't full — HAVING is needed instead of WHERE here because it checks a totalled (aggregate) value.

Part 4: Registering the command

Registering a command is a one-time (or occasional) call to Discord's REST API, done with your bot token — not something the Worker itself needs to do. Run it locally as a small script, separate from the Worker:

// register-command.js
// Run with: node --env-file=.env register-command.js

const appId = process.env.DISCORD_APP_ID
const guildId = process.env.DISCORD_GUILD_ID // your club's server ID - guild commands show up instantly, global ones take up to an hour
const token = process.env.DISCORD_BOT_TOKEN

const command = {
  name: "nextshift",
  description: "Show the next shift that still has open spots",
  type: 1 // a slash command
}

const url = `https://discord.com/api/v10/applications/${appId}/guilds/${guildId}/commands`

const response = await fetch(url, {
  method: "POST",
  headers: {
    "Authorization": `Bot ${token}`,
    "content-type": "application/json"
  },
  body: JSON.stringify(command)
})

if (response.ok === false) {
  throw new Error(`Discord replied with ${response.status}: ${await response.text()}`)
}

console.log("Command registered:", await response.json())

Find your server's ID by right-clicking the server icon in Discord with Developer Mode on (User Settings → Advanced → Developer Mode).

Part 5: Where secrets go

Value	Secret?	Where it lives
Bot Token	Yes	.env file next to register-command.js, read as process.env.DISCORD_BOT_TOKEN. Never in the Worker. Add .env to .gitignore.
Application ID, Guild ID	Not really secret, but config	Same .env file, for convenience
Public Key	Not secret (it's for verifying, not signing)	Set as a Cloudflare Worker secret with wrangler secret put DISCORD_PUBLIC_KEY, read in the Worker as env.DISCORD_PUBLIC_KEY

The Worker never needs the bot token, since it only replies to interactions directly — it doesn't call Discord's API itself.

Part 6: Testing it

1. Deploy the Worker first: wrangler deploy.
2. In the Portal's General Information page, set Interactions Endpoint URL to https://your-worker.workers.dev/discord and save. Discord sends a type-1 PING right then — if verification fails, it'll refuse to save and tell you.
3. Run register-command.js once.
4. In your club's Discord server, type /nextshift and confirm it replies with a shift.
5. Try editing a slot's capacity or filling it completely in D1, then run /nextshift again to confirm it skips full shifts.

Let me know how the endpoint verification step goes — that's the part I'd like you to actually test, since I flagged some uncertainty about the exact Web Crypto call.