Manage API keys by purpose
Create, rotate and troubleshoot keys without mixing API families.
Provision the correct key
Merchant and partner portals expose Settings → Security Keys. Add a named key, choose its associated user and permission type, then create it. Keys inherit that user’s permissions. Public keys are for permitted browser operations; private keys belong on the server.
Select the authentication contract
REST operations use the documented Authorization header. Classic APIs put credentials in the request body, but field names vary by operation: follow its contract rather than mechanically copying a generic api_key field. Sign-Up uses OAuth and is a separate family. Purpose Practice Development Use a separate sandbox credential Production Keep live credentials separate Teams and services Use individually scoped keys Permissions Grant only the access the operation requires Configure keys and environments
Rotate and troubleshoot
Create a replacement with the required permissions. Deploy it to your server configuration and verify the intended operations. Revoke the old key and record the change. Signal Check 401 Missing, invalid or inactive credential and header formatting 403 Permission scope and account restrictions; inspect the actual error Unexpected behavior Sandbox versus production, public versus private key and account configuration
Create a key in the correct portal
Use the Merchant Portal for merchant access or Partner Portal for partner access. Open Settings → Security Keys → Add a New Key. Give the key a descriptive name, choose the associated username and required permission, then create it. A key belongs to its selected user and permission scope; partner creation does not turn it into a merchant checkout key. Keep private keys on the server and rotate them through the appropriate portal.