How to rotate a Skinloop API key without changing the merchant account
Replace a merchant API key safely: compare GET /v1/me account IDs, check scopes, preserve existing orders and revoke the old credential.
A new key can belong to the same account—or a different one
Rotating a Skinloop API key means replacing a server credential, not changing which merchant owns an order. A storefront that only checks whether the new key works can accidentally connect a different merchant account. The safe approach is to compare merchant identity before replacing the saved credential.
Skinloop provides GET /v1/me for this purpose. Call it from your server with the candidate key as a bearer credential. Its successful response contains account_id: the stable Skinloop merchant identifier. This is not the dashboard user ID or the upstream payment provider’s account identifier.
Use account_id to distinguish rotation from an account switch
Store the account ID when a merchant first connects. Before accepting a replacement key, call GET /v1/me again and compare its account_id with that stored value. A match identifies the same merchant account across a key change. A different value identifies a different account and requires a deliberate account-switch decision.
- Same account_id: continue the credential-rotation flow, subject to permission checks.
- Different account_id: stop automatic replacement and require an explicit account-switch flow.
- Invalid or revoked key: reject the candidate; a 401 is not a reason to overwrite a working credential.
The identity endpoint requires a valid, non-revoked merchant key with a supported scope; there is no additional identity-specific scope to add. Do not expose the key to the customer’s browser just to run this check.
Matching identity does not prove matching permissions
A replacement key can belong to the correct account and still lack permissions your storefront needs. Skinloop documents separate checkout:create, checkout:read, payments:read and payouts:read scopes, together with game access. Check the actual functions your integration uses before switching production traffic.
If your checkout offers CS2 and Rust, confirm that the key allows the requested games. A key restricted to one game is not interchangeable with a two-game key just because both return the same account ID. A 403 can indicate an authorization problem; repeatedly resending the same request will not grant a missing scope.
Use the least access needed for the integration. A read-only reporting component should not receive a broader credential simply because another component creates checkouts. Keep identity, scope and game configuration as distinct checks.
A practical routine-rotation checklist
- Create the replacement key with the permissions and game access the integration actually needs.
- Verify its account_id against the merchant already connected to the store.
- Update the server-side secret through your normal controlled deployment process; do not commit the key to source code.
- Verify the relevant authenticated operations after traffic moves to the replacement credential.
- Revoke the old key after the transition is confirmed, and remove obsolete copies from deployment configuration.
This sequence follows Skinloop’s documented routine rotation flow. The reviewed documentation does not promise a particular overlap window, key-count limit or grace period. Do not copy another provider’s seven-day rotation window into your Skinloop integration.
Keep existing orders and webhook associations bound to their merchant
An account mismatch must not silently reassign existing checkouts, payment records or webhook associations. Preserve the merchant identity captured when each order was created. If the store genuinely changes merchant accounts, treat future configuration and existing order recovery as separate decisions.
For a multi-merchant storefront, save credentials and account identity per merchant rather than using one mutable global key. Validate the connected merchant before saving a configuration change. A successful identity check is not permission to read or act on another merchant’s order.
Do not rotate a webhook signing secret merely because a merchant API key changes. They serve different authentication purposes. Follow the relevant webhook configuration procedure if that secret or destination actually needs to change.
If the key was exposed, revoke first
A suspected leak is not an ordinary planned rotation. Skinloop’s guidance says to revoke the exposed key first and investigate its requests. Re-establish the connection with a new server-only credential after checking the merchant account and required permissions. Do not keep a compromised key active just to preserve convenience.
Keep full key values out of logs, support tickets, screenshots, browser bundles and mobile apps. Log a safe credential identifier and the connection outcome instead. If a server update fails, do not solve it by asking the customer to paste a secret into public chat.