Whop API Permissions for MCP Workflows

Use this page to plan the smallest useful Whop permission set before connecting an MCP client to checkout, payments, memberships, products, app resources, or finance workflows.

This is not the complete Whop permission catalog. Whop's API reference remains the source of truth for each endpoint. This page translates commonly used permissions into MCP operating decisions: what can be read, what can change customer state, and what should stop for approval.

Three permission rules for MCP

Separate inspection from mutation. A read-only audit should not use the same key as a refund, cancellation, transfer, or checkout creation workflow.
Match the credential to the actor. Company API keys fit company operations; App API keys fit app-development context; OAuth fits user-authorized actions.
Ask the agent to name the permission it needs. If the agent cannot explain the required permission and customer-facing effect, it should not call the tool yet.

Checkout permission recipes

Checkout is the first place to be concrete because it has a direct path from MCP to customer-facing purchase links.

Workflow	Representative permissions	What the agent may do	Approval gate
Inspect checkout configurations	`checkout_configuration:basic:read`	List and retrieve configurations, IDs, metadata, redirect URLs, and purchase URLs.	None beyond read-only confirmation.
Create checkout configuration	`checkout_configuration:create`, `plan:create`, `access_pass:create`, `access_pass:update`, `checkout_configuration:basic:read`	Draft or create a configuration that can produce a `/checkout/plan_xxxx?session=ch_xxxxxxxxxxxxxxx` URL.	Confirm company, plan, mode, redirect URL, metadata, affiliate code, and environment.
Inspect setup intents	`payment:setup_intent:read`, `member:basic:read`, `member:email:read`	Diagnose saved-payment-method setup without charging anyone.	Do not treat setup success as final fulfillment.
Inspect payment methods	`member:payment_methods:read`	Debug stored payment method availability.	Gate any follow-up off-session charge separately.

Products and plans

Most MCP product/plan work should start as lookup. The agent's job is to connect human names to live IDs and status before changing pricing or checkout code.

Workflow	Representative permissions	What the agent may do	Approval gate
Product lookup	`access_pass:basic:read`	List and retrieve products by ID or route.	None beyond read-only confirmation.
Product changes	`access_pass:create`, `access_pass:update`, `access_pass:delete`	Create, update, or delete products.	Confirm visibility, attached plans, and customer impact.
Plan lookup	`plan:basic:read`	List and retrieve prices, intervals, currencies, and active state.	None beyond read-only confirmation.
Plan changes	`plan:create`, `plan:update`, `plan:delete`	Create, update, or delete pricing plans.	Confirm price, currency, interval, product, and whether existing memberships are affected.

Payments, refunds, and disputes

Payment permissions deserve strict separation. A reporting key should not also be a refund key unless the workflow genuinely requires it.

Workflow	Representative permissions	What the agent may do	Approval gate
Payment reporting	`payment:basic:read`, `plan:basic:read`, `access_pass:basic:read`, `member:basic:read`, `member:email:read`	List and retrieve payments, summarize failed payments, inspect fees.	Keep customer-level detail limited to the support case.
Refund, retry, or void	`payment:manage` plus supporting read permissions.	Refund, retry, or void a payment.	Confirm payment ID, amount, reason, customer communication, and downstream membership effect.
Off-session charge	`payment:charge` plus plan, product, promo, member, and payment-method read permissions.	Charge an existing member using a stored payment method.	Confirm consent, amount, plan, member, payment method, and webhook handling.
Dispute review	`payment:dispute:read` plus supporting payment, company, product, plan, and member read permissions.	Retrieve or list disputes.	None beyond read-only confirmation.
Dispute evidence	`payment:dispute` plus supporting read permissions.	Update or submit dispute evidence.	Submitting evidence should require explicit final approval.

Membership and member support

Membership permissions determine who can see customer records and who can change access or billing state. In MCP workflows, make the agent summarize first and mutate only after approval.

Workflow	Representative permissions	What the agent may do	Approval gate
Member lookup	`member:basic:read`, `member:email:read`, `member:phone:read`	Find members and support context.	Only expose personal details needed for the case.
Membership lookup	`member:basic:read`	List or retrieve membership state and access context.	None beyond read-only confirmation.
Membership changes	`member:manage`, `member:basic:read`	Update, cancel, pause, or resume a membership.	Confirm timing, access effect, billing effect, and customer communication.

Apps and webhooks

App permissions are for app-development context. Do not use an App API key as a workaround for a missing Company API key; identify the resource and actor first.

Workflow	Representative permissions	What the agent may do	Approval gate
App inspection	`developer:manage_api_key`	Retrieve or list app-related resources where the API requires developer app context.	Confirm the app ID and target company context.
App creation or update	`developer:create_app`, `developer:update_app`, `developer:manage_api_key`	Create or update app resources.	Confirm production impact and install behavior.
App builds	`developer:manage_builds`	List, create, retrieve, or promote builds.	Promoting a build should require explicit release approval.
Webhook setup	Endpoint-specific webhook permissions from the official API reference.	Audit webhook URLs, event choices, and handler code.	Confirm destination URL, selected events, secret storage, and API version before creating or updating.

Finance and payout permissions

Finance calls should be treated as owner-level operations. Read-only balance or payout diagnosis can be useful; transfers and withdrawals should not be routine agent actions.

Workflow	Representative permissions	What the agent may do	Approval gate
Ledger lookup	`company:balance:read`	Retrieve ledger-account context.	Summarize before showing detailed rows.
Transfers	`payout:transfer:read`, `payout:transfer_funds`	List or create transfers.	Require owner approval, origin, destination, amount, and purpose.
Withdrawals	`payout:withdrawal:read`, `payout:withdraw_funds`, `payout:destination:read`	List, retrieve, or create withdrawal requests.	Require finance-owner approval and destination verification.
Fee markups	`company:update_child_fees`	Create, list, or delete connected-account fee markups.	Confirm connected account and fee impact.

Approval prompts

For this Whop MCP task, list the exact endpoint or tool you want to call, the required permissions, and whether the call is read-only or write-capable. Do not call it yet.

Reduce this workflow to the smallest permission set. Separate read-only setup from write actions. Show which permissions are only needed for the final approved call.

Before using a write-capable Whop permission, show the target company, resource ID, customer-facing effect, required permission, and rollback or cleanup path.

FAQ

Is this a complete list of Whop permissions?

No. It is a workflow map for MCP usage. The official Whop API reference documents the required permissions for each endpoint.

Why can a visible MCP tool still fail?

The client may see a tool schema even when the active credential lacks the permission, actor context, or resource access needed for a successful call.

Should I give an MCP client broad write access?

Only for a narrow, supervised workflow. Most discovery, reporting, troubleshooting, and setup tasks should start with read-only permissions and approval prompts.