Customers
A customer represents one of the people or accounts your business already serves. The customer record gives Mitu a consistent identity that can be associated with MCP access, Agent Wallets, payments and events without replacing the customer records you already maintain in your own system.
Your application remains the source of truth for customer profiles, permissions, purchases, subscriptions and other business data. Mitu only needs enough information to identify the customer and associate activity on the platform with the correct account.
Connect customers to your system
Use client_reference_id to associate a Mitu customer with the corresponding record in your own system. This should be a stable identifier your backend already understands, such as your internal user or account ID.
For example, if your application knows a customer as your_user_8841, you can use the same value when creating their Mitu customer record. That reference can then be used to connect Mitu activity back to the customer in your own system without making the Mitu customer ID your primary identity.
Keep the reference stable for the lifetime of the customer. It exists to connect the Mitu record to the account you already manage, while the Mitu customer ID identifies that resource inside Mitu.
How customers are created
Customers can be created explicitly by your backend or through your existing sign-in flow.
Both paths result in the same customer model. Once the customer exists, you can associate other capabilities with that record, such as Agent Wallets. The method used to create the customer does not automatically determine which other products or capabilities they receive.
See Customer API and OAuth for the two flows.
A customer and an Agent Wallet are separate resources. Creating or signing in a customer does not automatically create a wallet, balance or funding address. You decide separately which customers should receive Agent Wallets.
Customer authentication
When an AI agent needs to act on behalf of a specific customer, the connection must identify who that customer is. Customers can connect using a customer key or, where configured, by signing in through your existing OAuth identity provider.
Customer authentication answers who the AI agent is acting for. It does not replace the authorisation rules in your own application. Your backend should continue deciding what that customer can see or do using the permissions and business rules you already enforce.
See Customer keys and OAuth for the available authentication models.
Customer identity in requests
For operations associated with an identified customer, Mitu can include customer context with the request sent to your API. This lets your backend associate the agent’s action with the corresponding customer in your own system.
Do not trust these headers on their own. Verify that the request came through Mitu before using Mitu-specific customer context in your application. Request verification confirms where the request came from, while customer authentication identifies who the AI agent is acting for.
If OAuth is being used, the signed-in customer’s access token can also be forwarded so your existing authentication, authorisation and account rules continue to apply.
See Request verification for the verification process.
Customers and Agent Wallets
Agent Wallets belong to customers, but they are issued separately. A customer can have no wallets, one wallet or several wallets depending on how your product is designed.
The customer owns the funds in those wallets, while your business decides which customers receive wallets and configures the controls available for them. An AI agent acting for the customer can use supported wallet capabilities without gaining administrative control over the customer’s funds.
See Agent Wallets for the wallet model.
Customer events
Customer events let your application react when customer-related activity happens on the platform. For example, customer.created can be emitted when a customer record is created through a supported customer flow.
Keep event payloads, delivery behaviour and implementation status on the Events reference rather than duplicating those details here. This keeps the customer overview focused on identity while the Events page remains the source of truth for webhook behaviour.