erver-to-Server OAuth returns invalid_request for Account 1 despite identical configuration to working Account 2

API and Webhooks Meetings
1

Environment:

  • Two Zoom Workplace Pro accounts
  • Server-side Python application using requests library
  • Both apps: Server-to-Server OAuth type, same scopes, both activated

Account 1 (failing):

  • Plan: Workplace Pro, single user (Owner)
  • App status: Activated
  • Scopes: meeting:write:meeting:admin, meeting:write:meeting:master

Account 2 (working perfectly):

  • Same plan, same scopes, same app configuration

Standard request (identical for both accounts):

python

from base64 import b64encode
import requests

encoded = b64encode(f'{client_id}:{client_secret}'.encode()).decode()
r = requests.post(
    'https://zoom.us/oauth/token',
    params={'grant_type': 'account_credentials', 'account_id': account_id},
    headers={'Authorization': f'Basic {encoded}'}
)

Results:

  • Account 2 → 200 OK + valid access token :white_check_mark:
  • Account 1 → 400 {"reason":"Bad Request","error":"invalid_request"} :cross_mark:

All attempts made for Account 1:

  1. Standard request with URL params → invalid_request
  2. Parameters in POST body with Content-Type: application/x-www-form-urlencoded → invalid_request
  3. Numeric account number as account_id → invalid_request
  4. Deleted app, created brand new S2S OAuth app → invalid_request
  5. Regenerated Client Secret multiple times → invalid_request
  6. Verified base64 encoding is correct — no hidden characters
  7. Tested https://api.zoom.us/oauth/token endpoint → invalid_request
  8. Used Account 2’s working credentials with Account 1’s Account ID → invalid_request
  9. Swapped Account ID and Client ID positions → invalid_client (confirms request format is correct when credentials match)
  10. Cross-test: Account 2 credentials + Account 2 Account ID → 200 OK :white_check_mark:

Key finding:

The most significant test is #8: using Account 2’s known-working credentials but passing Account 1’s Account ID as the account_id parameter still returns invalid_request. This means the Account ID value from Account 1’s App Credentials page is being rejected by Zoom’s server regardless of which credentials are used.

The error invalid_request (not invalid_client) suggests Zoom considers the account_id parameter value itself as invalid, even though it is copied directly from the App Credentials page.

Question:

Is the Account ID shown on the App Credentials page the correct value to pass as account_id in the token request for all Workplace Pro account types? Could there be a different Account ID to use for this specific account configuration?