Authentication

Every call sends a token in the X-AUTH-TOKEN header. You get the token by exchanging an API user's access key and secret.

Get a token

1. Create an API user in wxrks and note its access key and secret.
2. Exchange them for a token with Auth API Token. The token comes back in the X-AUTH-TOKEN response header.
3. Send that header, with the same name, on every other call.

The answer to the exchange has an empty body: read the header, not the body.

curl -i -X POST 'https://app.wxrks.com/api/v3/auth' \
  -H 'Content-Type: application/json' \
  -d '{"accessKey": "<access key>", "secret": "<secret>"}'

curl 'https://app.wxrks.com/api/v3/project?size=10' \
  -H "X-AUTH-TOKEN: $WXRKS_TOKEN"

The wx CLI and the MCP server make this exchange for you from a saved access key and secret.

Token lifetime

A token lasts 10 days by default; your account's security settings can make it shorter. Save it and reuse it rather than logging in before every call, and get a new one when a call answers 401.

Host

Call the host you sign in to wxrks with: app.wxrks.com, or your region's host, such as eu.wxrks.com. The examples in these pages use app.wxrks.com.

Permissions

What an API user can do comes from the permission groups it belongs to. A call it is not allowed to make fails with BWX-403 (see Errors).

Each operation lists what it checks:

• Requires or Requires one of: the permission codes, written as the API checks them (for example GLOSSARY_update). The user needs at least one of them.
• Also requires: codes the operation checks in addition, on some paths (for example PROJECT_export_import_file when a TM export is limited to work units).
• Roles: the operation is limited to users with one of these roles instead of a permission code.

A permission applies only to the organizations and org units the user can reach. A call on another account's resource fails with BWX-403 even when the user holds the code.

Give an API user only the permission groups its integration needs.