Pricing

Pricing determines whether an AI agent needs to pay before using an operation and how the amount is calculated. Configure the pricing model on the operation you make available through MCP.

Some operations can remain free, while others can use a fixed amount or calculate a price for each request. Choose the model that matches how your product already determines what something costs.

Pricing models

Pricing is separate from customer authentication. An operation can be free and still require a signed-in customer, or it can be paid and available without a customer account.

Free

Use free when an operation does not require payment. The agent calls the operation and your API processes it normally without a payment requirement or settlement step.

Free operations are useful for capabilities an agent may need before deciding whether to perform a paid action, such as browsing a catalogue, checking availability, retrieving delivery zones or reading public information.

A free operation can still require customer authentication when it accesses account-specific information. Configure authentication separately using requires_auth.

Learn more about MCP authentication.

Fixed pricing

Use fixed when every call to an operation costs the same amount. Configure the price on the operation and Mitu uses that amount whenever an agent attempts to use it.

name: company_report
method: POST
path: /reports
pricing_type: fixed
price: 5.00
currency: USD

When the agent calls the operation, Mitu presents the payment requirement and handles the payment before sending the request to your API. Your backend is called to perform the paid work only after payment has been confirmed.

Fixed pricing works well for operations such as a lookup, a single report, access to a known digital resource or another action whose price does not depend on the contents of the request.

Learn more about Agent payments.

Dynamic pricing

Use dynamic when your API needs to determine the amount for each request. This is useful when the final price depends on information such as quantity, selected items, delivery fees, record count, availability or other request-specific data.

Dynamic pricing has two stages. First, Mitu asks your API for the price without asking it to perform the paid work. After the agent pays that amount, Mitu sends the request again so your API can fulfil it.

Return a quote

During the quote stage, your endpoint receives the request without x-mitu-amount-charged. Calculate the amount from the request and return 402 with the price.

POST /orders
x-mitu-signature: t=1757601046,v1=9f3c4a...
x-mitu-request-id: req_5f13b916

{
  "amount": "43.20",
  "currency": "USD"
}

amount is the amount the agent needs to pay. Return it as a positive decimal value without a currency symbol. currency identifies the currency for the quote and can use the currency configured for the operation when one is already defined.

If your API determines that a particular request does not require payment, it can return the appropriate non-402 response instead. That response is returned to the agent without starting the payment flow.

Fulfil the paid request

After the agent completes the payment, Mitu sends the request to your API again with x-mitu-amount-charged containing the amount that was paid.

POST /orders
x-mitu-amount-charged: 43.20
x-mitu-signature: t=1757601046,v1=9f3c4a...
x-mitu-request-id: req_5f13b916

Verify the request before performing the paid work. The amount header provides payment context, but it should not be trusted on its own because headers can be supplied by any caller reaching your API directly.

const amount = req.get('x-mitu-amount-charged')
if (!amount) {
  return res.status(402).json({
    amount: priceFor(req.body),
    currency: 'USD'
  })
}
if (!verify(req, SIGNING_SECRET)) {
  return res.sendStatus(401)
}
return res.json(await doTheWork(req.body))

Keep quote calculation and fulfilment separate. The quote determines what should be charged, while the paid request is where your application performs the work the agent paid for.

See Request verification for the complete verification process.

Handle quote errors

A dynamic quote must return a valid amount before Mitu can present the payment requirement to the agent. If the response cannot be interpreted as a valid quote, the payment cannot continue.

Return normal application errors when the request itself cannot be priced, such as an unavailable item or invalid configuration. This gives the agent useful information about why the operation cannot proceed instead of presenting a payment requirement for something your application cannot provide.

Tiered pricing

Use tiered when the amount changes according to volume, size or another measurable usage threshold. This works well for products where charging the same amount for every request would not reflect the actual value or cost of the operation.

For example, a data-processing operation might use one rate for smaller workloads and another for larger workloads. Configure the tiers around the unit your product measures so the resulting price remains predictable for the payer.

If the price needs to be calculated from more complex request-specific information rather than predefined tiers, use dynamic pricing instead.

Session pricing

Use session when the payer should fund a balance once and use it across multiple paid interactions rather than completing a separate payment for every call.

This model works well for long-running or metered interactions where many small paid actions may occur during the same workflow. The session keeps track of the amount made available and how much is consumed as the interaction continues.

Use session pricing when the calls belong to the same ongoing paid interaction. For independent operations where each request should be priced and settled separately, use fixed, dynamic or another per-request pricing model instead.

Learn more about Payment experiences.

Changing pricing

Changes to an operation’s pricing configuration apply to subsequent payment attempts. If the amount changes frequently or depends on current information from your system, dynamic pricing is a better fit than repeatedly changing a fixed price.

Dynamic pricing calculates the amount for each request, which helps avoid relying on a previously configured amount when the current price depends on inventory, quantity, delivery, availability or another value that can change.

Pricing and payment are separate

Pricing determines how much should be paid. Agent payments determine how the payer satisfies that amount.

Your API does not need to calculate a different price because an agent uses x402, MPP or another supported payment method. Once the amount is known, Mitu handles the payment flow and sends the paid request to your API for fulfilment.

This separation lets your product keep ownership of its pricing logic while Mitu handles the payment interaction with the agent.

Related