Also known as: Authentication Key, API Token, Access Key
An API Key is a unique secret string that a program presents to an API to prove who it is, so the server knows the request comes from an authorized caller. In a Forex partnership it works like a machine password that lets an IB's software request client, volume, and commission data from the broker's server.
When your integration calls a broker endpoint, it attaches the API key — usually in a request header. The broker's server looks up the key, confirms it is valid and active, checks what that key is permitted to access, and only then returns data. Without a valid key the request is rejected, which is exactly what keeps random actors from reading your clients' commission and registration records.
Keys carry scope and identity, which is why they are more than a login. A single IB may hold several keys — one for the reporting integration, one for the sub-IB portal, one for a test environment — each with limited permissions. If one leaks, you revoke and reissue just that key without disturbing the others, and because every call is tied to a key, the broker can trace and rate-limit activity per integration.
The entire security model rests on the key staying secret. A leaked key is a leaked password: whoever holds it can pull your client data until it is revoked. That is why keys belong in server-side secret storage, never in frontend JavaScript, never hardcoded into a public GitHub repo, and should be rotated on a schedule and immediately after any staff or vendor change.
The broker issues you a key from the partner portal and stores a matching record on its side. Your software attaches the key to each API request, typically in an HTTP header; the server validates it, checks the key's permissions and rate limit, and returns data only if all three pass.
Because the key both identifies and authorizes, the broker can scope each key to specific endpoints and revoke it independently. Every request is attributable to a key, so suspicious volume or a leaked credential can be traced to one integration and shut off without breaking the rest.
Operationally, keys should live in a secrets manager or environment variable on the server, be transmitted only over HTTPS, and be rotated periodically. Compromise handling is simple by design: revoke the key in the portal, issue a new one, and update your secret store.
Create the API key inside the broker's partner portal, scoping it to only the endpoints your integration actually needs.
Put the key in a secrets manager or server environment variable — never in frontend code, a config committed to git, or a chat message.
Send the key in the request header over HTTPS so the broker's server can authenticate each call.
Use separate keys for reporting, portals, and testing so a leak is contained to one function.
Regenerate keys periodically and immediately after any staff or vendor departure to close stale access.
If a key is exposed, revoke it in the portal at once and issue a replacement before any data can be misused.
Why it matters for partnership: The API key is the credential that makes secure IB-to-broker data transfer possible — and the single point of failure if it leaks. Guard it like a bank password: only authorized partner software can then pull sensitive commission, volume, and registration data, keeping the integration compliant and secure.
To connect your custom rebate portal to a Vantage partner CRM, the broker issues an API key scoped to the reporting endpoints. You store it in AWS Secrets Manager and reference it server-side, so nightly commission pulls run securely. When a contractor leaves the project, you rotate the key in the portal within minutes and the old credential stops working immediately.
| Attribute | API Key | OAuth Token |
|---|---|---|
| What it identifies | The application/integration | A user granting delegated access |
| Lifespan | Long-lived until revoked | Short-lived, refreshed |
| Typical use | Server-to-server data pulls | User-authorized app access |
| Revocation | Regenerate in portal | Revoke token or consent |
| Risk if leaked | Full scoped access until revoked | Limited by short expiry |
Never hardcode a key — load it from an environment variable or secrets manager, and add a pre-commit scanner so a key can never be pushed to a repository by accident.
Exposing the key in client-side JavaScript or a committed config file — anyone who views source or clones the repo can pull your entire client dataset until you notice and revoke, which may be weeks later.
Immediately revoke it in the broker's partner portal and generate a new one. Until you revoke it, whoever holds the key can access whatever data it is scoped to.
Functionally yes for machines — it authenticates a program rather than a person — but it should be treated with even more care because software calls run automatically and at scale.
In a server-side secrets manager or environment variable, never in frontend JavaScript, a mobile app binary, or a config file committed to version control.
On a regular schedule — many teams choose every 60-90 days — and always immediately after a developer, contractor, or vendor with access departs.
Only if you reuse one key everywhere. Issuing a separate, least-privilege key per function contains a leak to that single integration.
For server-to-server reporting pulls an API key is standard and simplest; OAuth suits flows where an end user grants your app delegated access to their own account.