# 

A platform needs to do things for its merchants: run a transaction, pull a report, board an integration. It does not need their credentials.

`X-Acting-As-Client-Id` names the merchant. You keep authenticating as yourself.

## How it works

Three headers, and only the third changes.

```http
Api-Key: $d48045e5-f017-4633-a5e7-4efb56f70afa
Client-Id: CLIENT-01KFDKXMQ637EKEAY410MSQSXB
X-Acting-As-Client-Id: CLIENT-01KFDKXMQ637ETEAY410MSQTUH
```

`Api-Key` and `Client-Id` stay the reseller's. The request is then carried out as though the named client had made it: its integrations are used, its transactions are created, and a report returns its data.

The header is accepted on **every** operation in the API.

## The three rules

**It works from a parent to its own children, and no further.** Naming a client you do not own is rejected. Ownership is the client's `parent_id` relationship — see [How accounts work](/docs/platforms/how-accounts-work).

**A merchant never sends it.** Merchants have no children, so there is nobody to act as. A merchant calling for itself omits the header entirely.

**Sending your own client ID is not the same as omitting the header.** This is the one that catches people. It reads like a harmless no-op, and some operations reject it. If you mean "act as myself", leave the header out.

## The one exception

`POST /v1/clients` cannot use it, because the client you would be acting as does not exist yet.

Boarding works the other way round: you authenticate as the reseller and set `parent_id` in the body to your own client ID. See [Create and update a client](/docs/platforms/create-and-update-a-client).

## A worked example

Boarding a merchant and taking its first payment, as a platform:

1. `POST /v1/clients` with `parent_id` set to your ID. No acting header. Store the `api_key` and `id` it returns.
2. `POST /v1/integrations` with `X-Acting-As-Client-Id` set to the new client, or with `client` in the body naming it.
3. `POST /v1/transactions` with `X-Acting-As-Client-Id` set to the new client. The transaction belongs to the merchant, routed through the merchant's integration.
4. `GET /v1/transactions` with the same header to read that merchant's activity alone — or without it, plus `client_id` as a filter, to read across your portfolio.


## Next steps

* [How accounts work](/docs/platforms/how-accounts-work)
* [Client reports](/docs/platforms/client-reports)
* [Authentication](/docs/get-started/authentication)