Get your configuration

What your api client is enabled for: every `assetId` it may use, and who pays the network fee on each. There is **no request body** — no `userId`, no `assetId`. The answer is the same for every user you hold. ## Read this instead of hardcoding the asset table Your api client may be enabled for only some of the assets in the [Asset IDs](/get-started/assets) table, and a call for one you are not enabled for is a `403`. This endpoint is the list that will not `403` — resolved against the running service, so an asset that is *limited* on your environment is absent here too rather than failing later with `400 Unknown assetId`. It is also the list `/create`, `/extend` and `/addresses` filter their address maps to: a chain appears there while you have at least one enabled asset on it. Call it at startup and cache it. It changes only when your operator changes your account, so poll it on the order of minutes if you poll it at all. ## Who pays the fee `feePayer` says who covers the network fee on a transfer of that asset: - `USER` — the fee comes out of the sending wallet. For a native asset it is taken from the `amount`; for a token it is paid in the chain's native coin, which the wallet must therefore hold. - `PLATFORM` — you cover it, so your user can move the token without holding any of the chain's native coin. The top-level `feePayer` is `PLATFORM` when at least one of your assets is, and `USER` when none are. <Warning> `feePayer` describes your arrangement, not a guarantee for the next transfer. A `PLATFORM` asset can still fall back to `USER` on an individual send. **`/fee` is the only quote** — call it before a transfer and show your user what it returns. </Warning>