Workspaces
List the workspaces an API key can act inside, select one per request, and use a test workspace to integrate without moving real money.
A trader account owns one or more workspaces. Every resource — payment instances, links, forms, transactions — belongs to exactly one, and each request acts inside exactly one.
A workspace is either live or test. A test workspace behaves identically except that payments run against the gateway's development credentials, so no real money moves.
List workspaces
Returns every workspace this API key can reach, live ones first.
| Method | Endpoint |
|---|---|
GET | /workspaces |
curl https://api.mytpe.app/api/ext/workspaces \
-H "X-Api-Key: $MYTPE_API_KEY" \
-H "X-Api-Secret: $MYTPE_API_SECRET"{
"data": [
{
"id": "7f3a1b2c-8d9e-4f01-a2b3-c4d5e6f70819",
"name": "Boutique Centrale",
"livemode": true,
"is_owner": true,
"is_active": true
},
{
"id": "9b1c2d3e-4f50-4a61-b2c3-d4e5f6a70b81",
"name": "Boutique Centrale (sandbox)",
"livemode": false,
"is_owner": true,
"is_active": false
}
]
}Response fields
| Field | Type | Description |
|---|---|---|
id | string (UUID) | The value to send in X-Workspace-Id. |
name | string | Display name. Not unique — never key off it. |
livemode | boolean | true for live, false for a test workspace. |
is_owner | boolean | true when this account owns the workspace, false when it reaches it through a membership. |
is_active | boolean | true for the workspace this request resolved to. Exactly one entry is true. |
is_active tells you the current default without a second request. Call
GET /workspaces with no X-Workspace-Id and whichever entry comes back
true is what every other endpoint uses by default.
Select a workspace
Send the id in the X-Workspace-Id header. Every endpoint accepts it.
curl https://api.mytpe.app/api/ext/instances \
-H "X-Api-Key: $MYTPE_API_KEY" \
-H "X-Api-Secret: $MYTPE_API_SECRET" \
-H "X-Workspace-Id: 9b1c2d3e-4f50-4a61-b2c3-d4e5f6a70b81"Omit the header and the API uses your earliest live workspace. There is no "all workspaces" view — a request always resolves to exactly one.
Naming a workspace this key can't reach returns 403:
{
"errors": [
{
"status": "403",
"code": "WORKSPACE_ACCESS_DENIED",
"title": "You do not have access to the requested workspace.",
"detail": "The X-Workspace-Id value names a workspace this account cannot reach. Omit the header to use the default live workspace.",
"meta": []
}
]
}What scoping affects
Selecting a workspace changes what a request can see and create:
| Area | Effect |
|---|---|
| Lists | GET /instances, /links, /forms return only that workspace's rows. |
| Reads | Fetching an id from another workspace returns 404, not 403, so the API never confirms it exists. |
| Creates | New resources belong to the selected workspace. |
| Transactions | Live and test transactions are stored separately and never appear together. |
A resource created in one workspace is invisible from another. A 404 on an id
you know exists almost always means the request resolved to a different
workspace — check X-Workspace-Id before anything else.
Test workspaces
A test workspace is one with livemode: false. Point X-Workspace-Id at it to
exercise a full integration without moving money:
- Payments route to the gateway's development credentials.
- Test data is isolated from live data in both directions.
- Everything else — endpoints, payloads, statuses, webhooks — behaves the same.
This is enforced on the server. A payment in a test workspace uses the development credentials even if the underlying payment instance is configured for production, so a misconfigured instance cannot charge a real card from a sandbox.
There is no per-request test flag and no test API key. The mode follows the workspace you select, which means the same credentials and the same code path serve both — you change one header.
Go live
Once the integration works against the test workspace, switch X-Workspace-Id
to the live one, or drop the header to fall back to the default live workspace.
No other change is required.