# 

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 `parent_id` relationship set when
the client was created — 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)