Connect customer accounts

Choose which operations require a customer

Decide which MCP operations need to know who the agent is acting for. Authentication is configured per operation, so public capabilities can remain available without a customer while account-specific capabilities require one.

For example, an agent might be allowed to browse a public catalogue without signing in, while viewing saved addresses, retrieving order history or creating something against a customer account requires authentication.

Configure those operations with customer authentication enabled.

name: create_booking
method: POST
path: /bookings
requires_auth: true

When an authenticated operation is used, Mitu requires the AI client to establish a customer identity before the request can continue.

Learn more about MCP authentication.

Connect customers with a customer key

Use customer keys when you want to provision access directly. Create or identify the customer in Mitu and provide them with the customer key returned for their account.

curl --request POST \
  --url https://api.mitu.ai/v1/customers \
  --header "x-api-key: $MITU_API_KEY" \
  --header "Content-Type: application/json" \
  --data '{
    "client_reference_id": "your_user_8841",
    "first_name": "Ada",
    "last_name": "Obi",
    "email": "ada@example.com"
  }'

A successful response identifies the customer and provides the information they need to connect.

{
  "id": "cus_ds9hazr8jd3l",
  "client_reference_id": "your_user_8841",
  "key": "mcpk_3a6f9d2a6bbc816b11d524fe052b26b7e75fb7b5fa7a1a7d",
  "mcp_url": "https://mcp.yourdomain.com/mcp"
}

Use client_reference_id to associate the Mitu customer with the corresponding customer in your own system. The mcpk_... value is the customer’s connection credential, not your merchant API key, and should only be given to that customer.

The customer adds the MCP URL to their AI client and authenticates with their customer key. Once connected, Mitu knows which customer the agent is acting for whenever it uses an operation that requires customer authentication.

Learn more about Customer keys.

Connect customers with OAuth

Use OAuth when customers already sign in to your product and you want the same account identity to carry into the agent experience. Instead of giving the customer a separate key, configure your existing identity provider for the MCP integration.

The customer adds your MCP URL to a compatible AI client and signs in using the account they already have with your product. Mitu uses the authenticated identity to create or associate the corresponding Mitu customer record.

With OAuth, the customer’s access token can be forwarded to your API when an authenticated operation is called. Your backend can validate that token and continue applying the same account rules, permissions and entitlements it already uses for your website or application.

This means a customer who cannot access a resource through your existing product should not gain access to it simply because they are using an AI agent.

Learn more about OAuth.

Keep your customer records connected

Whichever authentication method you use, keep the Mitu customer associated with the corresponding customer in your own system.

With customer keys, use client_reference_id to provide your existing customer identifier when creating the customer. With OAuth, the authenticated identity is used to associate the customer with their existing account.

This mapping lets your backend understand which customer an incoming agent request belongs to and lets your server perform customer-level actions through the Mitu API, such as issuing an Agent Wallet.

Avoid creating another customer record simply because an existing customer starts using an AI agent. The agent is another way for that customer to access your product, not a new customer identity.

Learn more about Customers.

Authorise the request in your backend

When an authenticated operation reaches your API, use the customer identity associated with the request to apply your normal account and authorisation rules.

With a customer key connection, Mitu identifies the customer associated with that key so your backend can resolve the request to the corresponding customer record. The mcpk_... credential itself is not forwarded to your API.

With OAuth, the signed-in customer’s access token is forwarded with the request so your existing authentication and authorisation logic can continue to determine what that customer is allowed to access or do.

Customer authentication answers who the agent is acting for. Your application should still decide what that customer is allowed to do based on the rules you already enforce.

Verify requests from Mitu

Customer identity should only be trusted after your backend has verified that the request came through Mitu. When you connect your API, Mitu provides a signing secret that your server uses to verify forwarded requests.

Request verification and customer authentication serve different purposes. Verification establishes that Mitu sent the request, while customer authentication establishes which customer the AI agent is acting for.

Verify the request first, then use the customer identity or OAuth access token to apply your normal authorisation rules.

See Request verification for the verification process and implementation examples.

Test customer access

Connect a test customer through the authentication method you configured and call an operation that requires a customer. Confirm that your backend resolves the request to the correct customer and applies the same account rules you expect from your existing product.

Test with more than one customer to make sure customer-specific data remains correctly separated. Also test an unauthenticated request to confirm that protected operations require the customer to connect before they can be used.

If you support both customer keys and OAuth, test each flow independently because they establish the same customer context in different ways.