Whop API Keys for MCP

Whop MCP is only as safe as the credential behind it. Use this guide to choose between Company API keys, App API keys, OAuth tokens, and local environment variables before an AI client can inspect or change Whop data.

For most seller workflows, start with a company-scoped key and read-only prompts. For app-development workflows, use app credentials only when the work depends on companies that installed your Whop app. For user-authorized actions, OAuth is the better mental model because the action belongs to a user session, not a general company key.

Which Whop credential should MCP use?

Credential	Use when	Avoid when	First safe prompt
Company API key	The agent needs your own company's products, plans, payments, memberships, checkout resources, or reports.	The task is about customers of an installed app across multiple companies.	List read-only tools available for my company. Do not modify data.
App API key	You are developing or debugging an installed Whop app and need app-context API access.	You only need seller operations for one company.	Explain which companies or app resources this key can access before making calls.
OAuth token	The action should happen on behalf of a specific Whop user.	You need a durable backend credential for company operations.	Explain the user context and scopes before using the token.
Sandbox key	You are testing checkout, payment, membership, or write-capable MCP behavior.	You need to inspect live production state.	Confirm this is sandbox before creating or updating anything.

Company API key

A Company API key is the default credential for a seller, operator, or internal developer working with one Whop company. It is the right choice for listing products, checking plans, summarizing failed payments, auditing memberships, or validating checkout IDs used in a codebase.

The main risk is over-broad authority. If the key can refund payments, cancel memberships, update products, or create checkout configurations, then a connected MCP client may be able to request those actions. Start by giving the agent a read-only task and require explicit approval before any write-capable tool call.

Before calling any Whop MCP tool, explain whether the action is read-only or write-capable.
Do not create, update, delete, cancel, refund, retry, pause, resume, message, or modify data without explicit confirmation.

App API key

An App API key belongs in app-development work. Use it when the AI agent is helping build, debug, or validate a Whop app where the app context matters. This is different from seller operations because a mistake can affect resources tied to companies that installed the app.

Do not switch to an App API key just because a Company API key failed. First identify whether the failure is authentication, permission scope, wrong account, wrong resource ID, or a tool argument problem. The wrong credential can make debugging harder and riskier.

OAuth tokens

OAuth is the path for user-authorized behavior. If the action should happen on behalf of a person rather than a company-wide integration or installed app, OAuth gives you a cleaner permission boundary. In MCP workflows, the key question is: whose authority should this tool call represent?

Question	Prefer
"Can the agent summarize my company's failed payments?"	Company API key
"Can the agent debug our installed app across customers?"	App API key
"Can the agent perform an action as this signed-in user?"	OAuth token

MCP config patterns

For remote API MCP clients, authorization usually happens through the client flow. For local @whop/mcp, keep secrets in environment variables or prompted inputs. Avoid committing real keys into project files.

Local environment variable

export WHOP_API_KEY="whop_xxxxxxxxxxxxxxxxx"
npx -y @whop/mcp@latest --tools=dynamic

VS Code prompted secret

{
  "inputs": [
    {
      "id": "whop-api-key",
      "type": "promptString",
      "description": "Whop API key",
      "password": true
    }
  ],
  "servers": {
    "whop_sdk_api": {
      "command": "npx",
      "args": ["-y", "@whop/mcp"],
      "env": {
        "WHOP_API_KEY": "${input:whop-api-key}"
      }
    }
  }
}

Bearer header shape

When debugging outside MCP, the Whop API credential is passed as a bearer token.

curl https://api.whop.com/api/v1/me \
  -H "Authorization: Bearer whop_xxxxxxxxxxxxxxxxx"

Permission planning

Do not give one permanent broad key to every AI client. Map the workflow first, then grant the smallest usable permission set. A reporting workflow should not need payment refund authority. A checkout debugging workflow may need to list products and plans before it ever needs to create a checkout configuration. For concrete recipes, use the Whop API permissions for MCP reference.

Workflow	Likely read needs	Write actions to gate
Checkout debugging	Products, plans, checkout configurations.	Create or update checkout configuration, promo code, payment method behavior.
Payment reporting	Payments, failed payments, fees, disputes.	Refund, retry, void, dispute evidence submission.
Membership support	Members, memberships, access checks, cancellations.	Cancel, pause, resume, message, change access.
App development	App resources, installs, companies, webhooks, access tokens.	Credential changes, webhook changes, app-impacting mutations.

Rotation checklist

Rotate a Whop key if it was pasted into a public issue, committed to git, shared in a screenshot, used on an untrusted machine, or connected to a client you no longer control.

Create a replacement key with the smallest useful permissions.
Update the MCP connector, environment variable, or local config.
Fully restart the MCP client.
Run a read-only test call.
Revoke the old key.
Search local files for accidental copies.

rg -n --hidden --no-ignore "whop_" .

FAQ

Should I put a Whop API key in mcp.json?

Only if the file is private and never committed. Environment variables, prompted inputs, and client secret storage are better defaults.

Why do tools show up but calls fail?

Tool visibility only proves the MCP client can see the server. Calls can still fail because the key lacks permission, the resource belongs to another company or app context, or the agent supplied wrong arguments.

Is an App API key safer than a Company API key?

No. Safety depends on scope and workflow fit. Use a Company API key for company operations and an App API key only when the app context is required.