Paddle MCP integration for AI agents.
Connect AI agents to Paddle through 12 structured actions, including get customer, create customer, and create price. Review authentication, inputs, workflow…
- ACTION CONTRACTS
- 12
- AUTHENTICATION
- API key
- SOURCE STATUS
- Provider-backed
CATALOG SOURCE REVIEWED AUGUST 23, 2026 / ACTION NAMES AND SCHEMAS DERIVED FROM WORKING MACHINES PROVIDER SOURCE
CAPABILITY PROFILE
What the Paddle integration exposes
The Paddle Agent App exposes 12 provider-backed actions for finance work. Its current contract lets an authorized agent get one paddle customer by id, create a paddle customer, and create a paddle price for a product. These operations are called through Working Machines as typed capabilities rather than through browser navigation or copied UI steps.
A connection uses API key. Before execution, the agent can inspect the selected action, its required fields, declared scopes, and expected output contract. Provider credentials remain inside the Working Machines runtime; the calling agent receives the capability and its structured result, not the underlying secret.
For reliable operation, start with the narrowest action that satisfies the task, resolve stable provider identifiers before changing state, and validate the returned object or status after execution. Availability still depends on the connected Paddle account, granted provider permissions, workspace policy, region, plan, and upstream API behavior.
VERIFIED ACTION SAMPLE
Real Paddle capabilities.
Showing 12 of 12 actions. Risk labels are conservative signals based on operation names, not substitutes for provider documentation or runtime policy.
get_customerREADGet one Paddle customer by ID.
INPUTS: id
create_customerWRITECreate a Paddle customer.
INPUTS: name / email / locale / custom_data
create_priceWRITECreate a Paddle price for a product.
INPUTS: product_id / description / unit_price / type / name
create_productWRITECreate a Paddle product in the catalog.
INPUTS: name / description / tax_category / type / image_url
get_priceREADGet one Paddle price by ID.
INPUTS: id
get_productREADGet one Paddle product by ID.
INPUTS: id
list_customersREADList Paddle customers with optional email, status, search, and pagination filters.
INPUTS: after / perPage / orderBy / skipCount / ids
list_pricesREADList Paddle prices with optional product, status, recurring, and billing filters.
INPUTS: after / perPage / orderBy / skipCount / ids
list_productsREADList Paddle products with optional filtering, pagination, and price inclusion.
INPUTS: after / perPage / orderBy / skipCount / ids
update_customerWRITEUpdate a Paddle customer, including archiving or reactivating it through status.
INPUTS: id / name / email / locale / custom_data
update_priceWRITEUpdate a Paddle price, including archiving or reactivating it through status.
INPUTS: id / product_id / description / unit_price / type
update_productWRITEUpdate a Paddle product, including archiving or reactivating it through status.
INPUTS: id / name / description / tax_category / type
INPUT CONTRACTS
Know what the action needs before it runs.
get_customer
idOPTIONAL- Paddle customer ID, prefixed with `ctm_`.
create_customer
nameOPTIONAL- Full name for this customer.
emailREQUIRED- Email address for this customer.
localeOPTIONAL- IETF BCP 47 locale tag for this customer.
custom_dataOPTIONAL
create_price
product_idREQUIRED- Paddle product ID, prefixed with `pro_`.
descriptionREQUIRED- Internal description for this price.
unit_priceREQUIRED- Money amount in Paddle's lowest currency denomination.
typeOPTIONAL- Paddle entity type.
nameOPTIONAL- Name of this price.
create_product
nameREQUIRED- Name of the product.
descriptionOPTIONAL- Short description for the product.
tax_categoryOPTIONAL- Paddle product tax category.
typeOPTIONAL- Paddle entity type.
image_urlOPTIONAL- Image URL for this product.
PROVIDER-SPECIFIC WORKFLOWS
Jobs this Agent App can support
Inspect Get Customer
Get one Paddle customer by ID. Use this as a bounded discovery step, retain the returned identifier, and avoid expanding the read beyond the task's stated scope.
get_customerControl Create Customer
Create a Paddle customer. Resolve the target first, present material changes for confirmation, and make retries idempotent where the provider supports it.
create_customerVerify with Get Price
Get one Paddle price by ID. Compare the returned provider state with the intended outcome and preserve stable IDs or canonical links in the run record.
get_priceSAFETY BOUNDARY
Operate Paddle with explicit limits
- Authorize Paddle with API key and grant only the provider access required by the selected actions.
- 6 actions are change-capable by name. Confirm the target identity and material parameters before allowing a write.
- Do not infer permission from catalog visibility. Workspace policy, connection identity, and upstream authorization still govern execution.
- The sampled contract declares provider scopes including `customer.write`, `price.write`, `product.write`, and `customer.read`; verify the complete action contract before execution.
- After a call, inspect the structured result and execution record before reporting that the Paddle task completed successfully.
CONNECTION MODEL
API key
Paddle API key sent as a Bearer token. Create or copy it from Paddle > Developer Tools > Authentication: https://developer.paddle.com/api-reference/about/authentication.
Working Machines stores provider credentials behind the execution boundary. An agent can use an authorized connection identity, but catalog discovery alone does not reveal OAuth tokens, API keys, or provider secrets.
- READ SIGNALS
- 6
- WRITE SIGNALS
- 6
- HIGH IMPACT
- 0
- REVIEW SIGNALS
- 0
EVIDENCE AND AVAILABILITY
Provider reference
Action names, input fields, authentication types, and counts on this page are generated from the Working Machines provider catalog. Provider behavior, quotas, object semantics, account eligibility, and regional availability remain governed by Paddle.