Discourse Multi-Site API Key Pitfall: Key Created in the Wrong Database

Issue

When configuring the forum-cli tool for each VM to access the Wenpai Community (wpcommunity.com), API key authentication returns HTTP 403:

ERROR: Post failed: ["You do not have permission to view the requested resource. The API username or key is invalid."]

Searching works, but posting fails; eventually even GET /categories.json returns 403.

Troubleshooting Steps

  1. Tested with Wenpai’s old API key → succeeded (200)
  2. Tested with newly generated Weixiaoduo API key → 403
  3. Both keys have identical format (64-character hex string), ruling out formatting issues
  4. Key difference: the old key was created early on in the correct site’s admin panel; the new key was generated in bulk

Root Cause

wpcommunity.com uses Discourse’s multisite configuration, with its own dedicated wpcommunity database—fully isolated from the default database. The bulk-generated API keys were created in the default database and thus are invalid for the wpcommunity.com site.

In Discourse’s multisite mode, each site maintains its own separate database, and API keys are not shared across databases.

Solution

Regenerated Global API keys for all VMs within the correct wpcommunity database, then deployed and verified—all now succeed.

Follow-up Recommendations

  • When generating API keys for a Discourse multisite instance, ensure the browser URL matches the target site’s domain (e.g., wpcommunity.com/admin/api/keys).
  • If an API key returns 403, first verify that the key was created in the correct database.
  • Include the site name in the API key’s description field to aid future debugging.
  • Exercise caution during bulk key operations—avoid accidentally revoking keys belonging to other sites (in this incident, keys for the Cyber Forum were also mistakenly revoked).