The workspace this credential belongs to
Request
Synthetic example for the production API. Replace YOUR_API_KEY and the ids. Do not send it against a live account until you mean to.
curl -X GET "https://api.fxapis.com/v1/workspace" \
-H "Authorization: Bearer YOUR_API_KEY"Its plan, and whether trading is switched off. Our staff switch trading off for a whole workspace only during an incident; this is where to see it.
Authorization
apiKey Authorization: Bearer fx_live_<id>_<secret>.
A key is shown once, at creation. We cannot show it again or recover it for you.
Keys carry a label (live or test) in the key itself, so each configuration is easy to tell
apart. Both reach real brokers: test with a broker demo account.
Scopes are per key. A key without accounts:write can read accounts and nothing else.
In: header
Response Body
application/json
application/json
curl -X GET "https://api.fxapis.com/v1/workspace"{ "data": { "id": "497f6eca-6276-4993-bfeb-53cbbbba6f08", "name": "string", "plan": "string", "planName": "string", "planAssigned": true, "tradingDisabled": true }}Read one event GET
Exactly as a webhook delivery carried it.
Create a key POST
**Needs an admin key** (`fx_admin_…`), made by the workspace owner in the console — or a signed-in owner or admin. Ordinary API keys are refused with `ADMIN_KEY_REQUIRED`. Returns the key in `key`, **once**. We cannot show a key again after creation, or recover it. A lost key is replaced, not recovered. `admin`, `keys:manage`, `members:manage` and `billing:manage` cannot be granted here, not even by an admin key. Issue narrow keys: an integration that only reads positions should hold `trading:read` and nothing else. A console session confirms it's you first (`403 STEP_UP_REQUIRED`) only when the key can move money or accounts — `trading:execute`, `trading:reduce` or `accounts:write`. A read-only key, or one that only manages webhooks, is created without one.