Call the merchant backend

Once your MCPMCPModel Context Protocol: a standard way for AI agents to call tools and data sources exposed by a server./UCP service has the merchant access tokenMerchant access tokenA token issued by the merchant's own authorization server. Only the MCP/UCP service sees it, never the agent., use it as the merchant API expects. AIGW is deliberately upstream of the merchant's existing API authorization layer; the merchant backend should not need to accept a new agent-specific bearer-token format if it already accepts tokens from its own authorization server.

Example

GET /products?q=shoe HTTP/1.1
Host: api.merchant.example
Authorization: Bearer <MERCHANT_ACCESS_TOKEN>

The exact path, method, and scopes are merchant-specific.

Keep the trust boundaries clear

At this point there are three separate credentials with different audiences:

Credential	Held by	Used for
AIGW access token	Agent, then MCP/UCP service	Proves the user/agent authorization to AIGW/MCP flow
Proxy token	MCP/UCP service	Proves the server/project identity to AIGW
Merchant access token	MCP/UCP service	Authorizes the downstream merchant API call

Never forward these to the agent

The agent must never receive the proxy tokenProxy tokenA short-lived token the MCP/UCP service gets with its Proxy client, sent as X-Proxy-Token when redeeming a merchant token. or the merchant access token. The merchant backend should normally see only the merchant token it already trusts.

Scope handling

Requested AIGW resource scopes are intersected with the scopes exposed by the resource before AIGW sends them to the merchant authorization server. The merchant AS must define the same scope names and decide how those scopes map to API permissions.

For example, an MCP tool search_products might map to search:read, while a checkout tool could require a different merchant scope. Keep the mapping explicit in your MCP/UCP implementation so a tool cannot silently use a broader token than necessary.

Token lifetime and caching

AIGW caches the merchant token and refreshes/re-asserts when required. Your MCP/UCP service should also avoid repeatedly asking for a new proxy token on every request. Keep local caching bounded by the token expiration and your security policy.

Failure handling

Distinguish downstream failures from AIGW authorization failures. Examples:

• credential redemptionCredential redemptionPOST /api/credentials/token: the MCP/UCP service trades the user's AIGW token plus its Proxy token for the merchant access token. fails → do not call the merchant API;
• merchant token lacks a required scope → return an authorization error rather than retrying blindly;
• merchant API returns 401 because the token expired/revoked → obtain/redeem again according to your token policy;
• merchant API returns a business error → pass a suitable MCP/UCP-level error back to the agent without exposing internal credentials.

After you can complete one successful downstream call, your basic MCP/UCP integration is complete. Use Troubleshooting for common setup failures.