The wxrks REST API lets you build integrations and scripts against your workspace — creating projects, pulling translation memory, managing users, and more — outside the Portal UI. Every request to the API must carry an authentication token in the X-AUTH-TOKEN header, which you get by exchanging a permanent API key pair for it.
​

💡 Who is this for? This guide is for the Account Admin who needs to generate API credentials and authenticate requests to the wxrks REST API.

API credentials are generated per user, from that user's own profile — there is no separate admin screen for issuing keys to other people. Only users with the User API Token permission can generate them. By default this is the Account Admin role; an Account Admin can grant the permission to another user through a Permission Group.
​

The Age in Days field is informational — once you have a key pair, it shows how old that pair is, so you know when it might be worth rotating.
​

Generating a new pair immediately invalidates the old one. If you're setting up a shared integration (a CI pipeline, a connector, a bot), create a dedicated wxrks user for it first and generate the key from that account — not from a personal admin account whose key might get regenerated later for unrelated reasons. See Limit what an API key can do.
​

ℹ️ Note: To test an integration without touching production work, use a dedicated Organizational Unit or, on Quantum and above, a sandbox account. See API - limits and conventions.

Requests to the wxrks API don't use your API ID and API Secret Key directly. Instead, you exchange them once for a token, then use that token on every subsequent request.
​

Send a POST request to /api/v3/auth on your workspace's host, with your credentials as JSON:

Most workspaces use https://app.wxrks.com; European workspaces use https://eu.wxrks.com.
​

A successful response returns your authentication token in the X-AUTH-TOKEN response header — not in the response body, so make sure your client is reading response headers (with curl, that means passing -i or -D -).

Copy the token from that header and send it back as a request header, named the same way, on every call you make to the API:

You don't need to repeat step 2 for every request — reuse the same token until it expires.

The token from X-AUTH-TOKEN is valid for 10 days. There is no refresh call: when it expires, your requests start failing authentication — at that point, repeat step 2 (POST /api/v3/auth with the same API ID and API Secret Key) to get a fresh one.
​

You never need to generate a new key pair just because a token expired — the API ID/API Secret Key pair itself stays valid until you explicitly click Generate again on the Security tab. A long-running integration should catch the authentication failure and automatically re-run the exchange in step 2, rather than hardcoding a single token.
​

⚠️ Warning: The token is a JWT whose exp value is in milliseconds, not seconds as the JWT standard says, so a library that decodes it by the standard shows a date thousands of years away. Don't use exp to schedule renewals; renew when a request fails authentication.

An API key can do exactly what the user it belongs to can do. A key generated from an Account Admin user has the access of the Account Admin role, so for an integration that needs only part of that, don't use an admin user.
​

ℹ️ Note: If you deactivate the user, the key stops working: exchanging its API ID and API Secret Key for a token fails, and a token issued earlier stops working within about 5 minutes. This is the quickest way to cut off an integration.