MEXC API Key and Sub-Account Security: Permissions, IP Whitelists, Fund Segmentation and Integration Audits

An API connection can let a tax application read MEXC history, a portfolio tracker collect balances or a trading system place orders without an interactive login. That convenience creates a separate security boundary: the integration may keep working after the browser is closed, and its permissions determine the damage possible if its credentials are exposed. This guide develops a least-privilege design for MEXC API keys, IP restrictions and sub-accounts, then explains testing, troubleshooting, rotation and incident response.

Last reviewed: October 16, 2026. MEXC can change API permissions, eligibility, verification requirements, limits, interfaces and regional availability. Confirm every setting in the authenticated MEXC interface and current official documentation. This independent educational guide is not affiliated with MEXC and is not financial, legal, tax or cybersecurity advice.

1. Begin with the task, not the API screen

Do not start by selecting every permission that might be useful. Write down the exact job first: read balances for a portfolio view, import transaction history for reconciliation, place spot orders for one strategy or administer a controlled group of sub-accounts. The task should determine the key rather than the key determining what the application is allowed to do.

Ask four questions: what information must be read, what actions must be written, from which system will requests originate, and for how long is access needed? If one answer is unknown, postpone creation. A vague “full API access” requirement is a reason to investigate the integration, not a permission set.

2. Understand the credential pair

An API integration generally uses an Access Key to identify the credential and a Secret Key to authenticate signed requests. The Access Key is not harmless merely because it is sent as an identifier, but the Secret Key is the critical signing secret. It should never appear in a public repository, screenshot, support post, analytics event, browser note or ordinary chat.

MEXC’s setup material says the Secret Key is displayed only once. Save it directly into the destination secret store during creation. If that opportunity is missed, do not search browser history or screenshots; create a replacement key and delete the unusable one.

3. An API key is not a normal password

A password opens an interactive account session and may be protected by a second factor. An API credential is designed for software and may authorize repeated requests without a new code for each action. Changing the MEXC login password should not be treated as proof that every existing API credential has been revoked.

Maintain API keys as a separate inventory. During an incident, secure the login, email and multifactor authentication, but also inspect and revoke API credentials independently. A clean browser login does not demonstrate that an old bot, server or vendor has lost API access.

4. Decide whether an API is necessary

Some jobs can be completed with a manual export or a short-lived import. A periodic tax reconciliation may need transaction data but not permanent live access. Compare the operational benefit of automatic synchronization with the exposure created by a long-lived credential.

Manual workflows have their own risks—stale files, missing rows and insecure downloads—but they remove a continuous remote access path. Prefer the least powerful method that reliably completes the task. Never enable trading just because a vendor’s onboarding wizard makes it the fastest option.

5. Use one integration, one key

A shared key makes attribution and revocation difficult. If a tax tool, portfolio dashboard and bot use the same credential, an unusual request cannot be mapped confidently to one system. Removing one vendor also interrupts the others, encouraging administrators to leave an unnecessary key active.

Create a dedicated key for each integration and environment. A clear note such as tax-readonly-2026 or spot-bot-prod communicates purpose without containing the secret. Separate production from experiments so a test script cannot affect the live strategy.

6. Apply least privilege

Permission names in the interface and documentation can change. Read the description displayed at creation and map each selected permission to a written requirement. “The connection failed without it” is not enough: identify the endpoint that needs it and decide whether the feature is worth the extra authority.

7. Read-only is the correct default

A read-only key is appropriate for many reporting integrations. It can still expose balances, activity patterns and account relationships, so it deserves secure storage, but it should not be able to create an order merely to produce a dashboard.

Test the smallest read scope first. Confirm that the vendor can retrieve the needed balances and history. Add another read permission only when a documented missing function requires it. Do not solve a read error by selecting every box.

8. Trading permission changes the risk

A key without withdrawal authority can still cause financial harm if it can trade. An attacker or faulty system may create repeated orders, cross a wide spread, concentrate the account in an unwanted asset or interact with a thin market. “Withdrawals disabled” is a valuable control, not a guarantee that funds cannot lose value.

Limit the balance exposed to a trading integration, restrict the strategy to expected markets in the application and add independent alerts. Where practical, isolate the bot in a sub-account instead of allowing it to trade the entire main account.

9. Treat transfer permissions as high impact

Transfer access can move assets among account sections or between supported account structures. Even when an internal transfer is not an onchain withdrawal, it can change which balance supports a strategy, position or margin obligation. It can also complicate monitoring and incident reconstruction.

Enable transfer write only when the documented workflow truly requires automatic movement. A tax tool or portfolio viewer normally should not move funds. If a bot requests transfer access for “convenience,” ask whether a manual funding process can preserve a smaller blast radius.

10. Separate spot and futures authority

MEXC documents distinct account and deal permissions for spot and contract functions. Do not grant futures access to a spot-only workflow. Derivatives add leverage, margin and liquidation exposure, making accidental or malicious orders potentially more consequential.

Use separate credentials and preferably separate sub-accounts for strategies with materially different risk. This article does not replace a futures risk plan; it limits which integration can reach that environment.

11. What an IP whitelist does

An IP whitelist limits where requests using the key may originate. A stolen credential used from an address outside the list should fail the IP check. MEXC recommends adding IP restrictions when creating a key, and its spot documentation identifies a specific non-whitelisted-IP error.

This is an additional condition, not encryption and not malware protection. If an attacker controls the allowed server, or can send requests through it, the whitelist may still be satisfied. Combine it with minimal permissions, protected secrets, hardened infrastructure and monitoring.

12. Choose whitelist addresses deliberately

A managed server or vendor may provide stable outbound addresses. Verify them in the vendor’s authenticated documentation or administration console. Do not copy an IP supplied by an unsolicited support message. Record who controls each address and why it is trusted.

Home connections, mobile networks and consumer VPN exit nodes may change unexpectedly. Adding a long list of shared VPN exits merely to prevent interruptions weakens the control. If the integration cannot offer predictable egress, decide whether its benefit justifies operating without an IP restriction.

13. Know what happens without an IP binding

Current MEXC spot API documentation states that an API key without a linked IP address is valid for 90 days and recommends IP restrictions. Do not depend on automatic expiry as the primary defense: conditions may change, and a leaked key can be abused before expiration.

Record a review or removal date at creation. If a temporary unbound key is unavoidable, reduce its permissions, shorten the operational window yourself and delete it as soon as the task is complete.

14. Store the Secret Key correctly

For a personal integration, use a reputable password manager or encrypted secret store with tightly controlled access. For a server, use environment-specific secret management rather than embedding the value in source code, a container image or a deployment script. Ensure logs redact authorization headers and signed query details.

• Never commit a Secret Key to Git, including a private repository.
• Do not place it in a spreadsheet or shared project document.
• Do not transmit it through ordinary email or messaging.
• Do not include it in screenshots or screen recordings.
• Do not paste it into an AI assistant, debugging forum or support post.
• Limit which people and processes can retrieve it.

15. Protect configuration backups

A secure production secret can be undermined by an unencrypted backup, copied .env file or developer laptop. Inventory every place the credential may have traveled during setup. Exclude secret files from version control and application support bundles.

When rotating a credential, remove obsolete copies from active systems and retention locations where feasible. A rotation is incomplete if the old secret remains usable and available in a forgotten automation account.

16. Use sub-accounts to reduce blast radius

A sub-account can separate balances, trading activity and strategies under the main account’s administration. MEXC currently documents an API-only type without direct login and a standard type with independent web login. Availability and behavior should be confirmed for the specific account and region.

Isolation is useful when a bot needs trading access. Fund its sub-account with only the amount assigned to that strategy. Keep long-term reserves and unrelated operations outside the automation boundary.

17. Sub-account design examples

Do not create many unlabeled sub-accounts without ownership and review rules. Segmentation improves security only when administrators can tell which account, key, server and strategy belong together.

18. Understand the limits of segregation

A MEXC sub-account is not a separate self-custody wallet. Assets remain within the exchange environment, and the main account retains administrative relationships with its sub-accounts. Platform, account-recovery and main-account compromise risks do not disappear.

Use sub-accounts to contain operational mistakes and integration authority, not as a substitute for deciding how much value should remain on an exchange. Funds not needed for exchange activity require a separate custody decision.

19. Fund a sub-account carefully

MEXC’s current sub-account guide describes transfers between the main account and sub-accounts and between sub-accounts. These internal movements differ from onchain deposits and withdrawals. Check the source, destination, asset and amount before confirmation.

Transfer only the working balance needed for the planned interval. Replenishing an account automatically whenever it loses money defeats the containment purpose. Establish a maximum exposure and require a deliberate review before increasing it.

20. Build a key register

A small register prevents forgotten access. It must not contain Secret Keys. Record the public key suffix, descriptive name, owner, integration, environment, permissions, bound IPs, sub-account, creation date, last review and planned retirement.

21. Safe creation workflow

1. Open MEXC through a trusted bookmark and verify the domain.
2. Secure the main account, email and multifactor authentication first.
3. Create or select the intended sub-account.
4. Write the integration’s exact required endpoints and actions.
5. Create a dedicated, clearly named API key.
6. Select the minimum matching permissions.
7. Add verified static outbound IP addresses where practical.
8. Store the Secret Key directly in the approved secret store.
9. Record non-secret details in the key register.
10. Test reads before enabling or testing writes.
11. Use a small controlled balance for the first live operation.

22. Verify the third party before connecting

Phishing pages often imitate tax tools, bot dashboards and exchange support. Reach the vendor through an independently verified domain, inspect its documentation and understand where credentials are stored. A polished API form does not prove legitimacy.

Check whether the vendor supports read-only operation and IP restriction, how it encrypts secrets, who can access them, how deletion works and how incidents are reported. Avoid services that demand unrelated permissions or ask users to disable security controls without a specific technical explanation.

23. Connect a portfolio tracker

Start with balance and necessary history reads. Confirm the tracker can display expected accounts without any order or transfer permission. Compare a sample balance and several transactions against MEXC rather than assuming a successful connection means complete data.

Some trackers poll frequently. Monitor rate-limit behavior and disable unnecessary refresh intervals. If the tracker is abandoned, delete its MEXC key; deleting the mobile application alone does not revoke server-side access.

24. Connect tax or accounting software

Tax software usually needs historical orders, trades, deposits, withdrawals and transfers—not authority to trade. Import a defined period, then reconcile opening and closing balances. API synchronization can omit unsupported products or old records, so retain exports and verify totals.

Never treat a generated tax report as proof that the API imported everything. Review warnings, unmatched transfers and missing cost basis with the original exchange and wallet evidence. Tax rules vary by jurisdiction; a software label is not professional tax advice.

25. Connect a trading bot

Use a dedicated key and sub-account. Enable only the market and write access required by the strategy. Configure symbol allowlists, maximum order size, maximum daily activity and a stop condition in the bot when those controls are available.

Begin with a test endpoint if supported, then use a small real order in a liquid market. Verify side, type, quantity, price, fees and resulting balances in MEXC. Never assume sandbox-style validation reproduces every live liquidity or risk condition.

26. Test in layers

1. Authenticate and read basic account information.
2. Read one expected balance or history endpoint.
3. Confirm a deliberately forbidden action fails.
4. Validate the IP restriction from the approved origin.
5. Confirm the same key fails from an unapproved origin when safe to test.
6. Use an order-validation endpoint where applicable.
7. Place the smallest suitable live test order.
8. Reconcile the result in both the integration and MEXC.

Negative testing matters. A key that successfully reads data has not yet demonstrated that trading and transfer writes are blocked.

27. Create independent monitoring

Do not rely solely on the bot to report its own mistakes. Use MEXC history and alerts to review unexpected orders, transfers and login activity. Define thresholds for order count, traded value, new symbols and balance changes.

An alert should lead to a documented response: pause the strategy, revoke the key if necessary, preserve evidence and inspect exposure. Notifications without an owner or action threshold produce noise rather than control.

28. Troubleshoot authentication failures

29. Handle IP whitelist errors safely

Do not remove the whitelist immediately when a connection reports an IP error. Determine the real outbound address of the integration. A cloud server may use a gateway address rather than the address shown on its local network interface, and a vendor may maintain several documented egress addresses.

If an address changed unexpectedly, investigate why. Confirm it through the provider’s official channel before updating MEXC. An attacker may use a fake troubleshooting message to persuade the owner to whitelist attacker-controlled infrastructure.

30. Handle permission errors precisely

An authorization error can be a successful security control. Find the failing endpoint and its documented permission. Decide whether the feature is part of the approved purpose. If not, leave the failure in place and disable that feature in the integration.

When adding access is justified, change only the relevant scope, retest and update the register. Avoid turning on all write permissions temporarily; temporary broad access can outlive the debugging session.

31. Understand timestamps and signatures

Signed requests use request data and the Secret Key to produce an authentication signature. Common failures include incorrect encoding, modified parameters, an unsuitable receive window and a server clock that differs from expected time. Use the official documentation and maintained libraries where appropriate.

Never debug by sending the Secret Key or complete signed request to a public forum. Create a disposable minimal-permission test key if external debugging is unavoidable, redact credentials and revoke it after use.

32. Respond correctly to rate limits

MEXC documents HTTP 429 responses for excessive request frequency and instructs clients to back off. Retrying immediately in a tight loop can extend disruption or trigger an IP ban. Respect response information, use exponential backoff with jitter and avoid duplicate parallel pollers.

Cache data that does not need second-by-second updates. Separate business retries from order submission logic: an unknown server result should not automatically create another order. First query the order state using a unique client identifier where the interface supports it.

33. Treat uncertain order responses carefully

A timeout or server error does not always prove that an order failed. The matching system may have accepted it before the response was interrupted. Blindly submitting the same intent again can double the position.

After an uncertain result, pause new actions, query order and trade history and reconcile balances. Design idempotency and unique client order identifiers into custom automation when supported. Escalate with timestamps and non-secret identifiers, never the Secret Key.

34. Rotate keys without losing control

1. Create a replacement with the same documented minimum scope.
2. Apply the verified IP restriction.
3. Store it under a new secret version.
4. Test reads and a controlled write if required.
5. Switch the integration to the replacement.
6. Monitor for expected operation.
7. Revoke the old key promptly.
8. Update the register and remove obsolete secret copies.

Do not leave the old key active indefinitely as a fallback. Define a short rollback window and an owner who will complete revocation.

35. Review access on a schedule

Review active keys monthly or quarterly depending on their authority and exposure. Confirm that the owner, vendor, sub-account, permissions and bound IPs are still correct. Compare actual use with the original purpose and remove dormant credentials.

Also trigger a review after staff changes, vendor termination, server migration, security incidents, strategy retirement or unexpected account activity. Calendar review complements event-driven review; neither replaces the other.

36. Decommission an integration completely

Stop the application, cancel unwanted open orders, export necessary records and revoke its MEXC key. Verify that subsequent test requests fail. Remove the secret from deployments and document the retirement date.

Inspect balances, recent trades and internal transfers before redistributing funds. If the sub-account has no remaining purpose, freeze or retire it using the current MEXC controls rather than leaving an unlabeled empty environment.

37. Incident response for a leaked key

1. Delete or revoke the exposed key immediately.
2. Pause associated bots, workers and scheduled jobs.
3. Review open orders and cancel unauthorized ones.
4. Review trades, balances, transfers and relevant sub-accounts.
5. Preserve timestamps, logs and public identifiers.
6. Determine where the secret was exposed and who could retrieve it.
7. Secure the MEXC login, email and multifactor authentication if broader compromise is possible.
8. Contact MEXC through the official Help Center when account action is required.
9. Create a replacement only after the exposure path is closed.

Do not merely edit the IP whitelist of a known-compromised credential. Revocation creates a cleaner boundary. If the secret appeared in Git, assume it was copied even if the commit was quickly deleted or the repository was private.

38. Distinguish API compromise from account compromise

Unexpected API orders may originate from a leaked credential or defective integration without an interactive account takeover. Unrecognized logins, changed security settings, new API keys or email alerts can indicate broader compromise. Investigate both paths.

If the linked email is compromised, recover and secure it independently. Use a known-clean device, change reused passwords and review sessions. Never disclose a two-factor code, password, API secret or wallet recovery phrase to someone claiming to investigate the incident.

39. Common failure scenarios

A tax tool asks for trading access

Stop and verify the official integration instructions. A reporting workflow should normally work with reads. If a product genuinely combines tax and trading functions, decide whether to use only its reporting component or a different service.

A bot works only after the whitelist is removed

Identify and verify its real outbound IPs. Do not accept a permanent unbound key by default. If stable egress is unavailable, reduce the balance and permissions and decide explicitly whether the remaining risk is acceptable.

A developer committed the key

Revoke it immediately; deleting the line or making the repository private is insufficient. Search build logs, forks, caches and deployed configuration, then rotate any related credentials.

A strategy needs both spot and futures

Consider separate keys and sub-accounts. This makes permissions, balances, monitoring and shutdown clearer than one credential controlling every market.

40. Complete audit checklist

• Every key has one documented integration and owner.
• No Secret Key appears in code, logs, screenshots or shared documents.
• Read-only tools have no write permission.
• Trading keys cannot reach unrelated account functions.
• Verified static IPs are bound where practical.
• Bot balances are limited through deliberate funding and sub-account design.
• Production and testing use different credentials.
• Actual activity is monitored outside the integration.
• Dormant and expired-purpose keys are deleted.
• Open orders and transfers are included in incident checks.
• Rotation and emergency revocation have named owners.
• The register contains no secret material.

Frequently asked questions

Is a read-only MEXC API key safe to share?

No. It may expose balances and detailed activity and could help profile the account. Give it only to an approved integration and store it securely.

Does disabling withdrawal permission make a bot harmless?

No. Trading authority can still create losses through unwanted orders, fees, spread or illiquid markets. Limit permissions and the available balance.

Should every key have an IP whitelist?

Use one where the integration has trusted, stable outbound addresses. Confirm the real origin rather than adding broad or shared ranges merely to avoid errors.

Can a sub-account protect the main account completely?

No. It can reduce operational blast radius, but it remains part of the exchange account structure and does not remove platform or main-account risk.

How often should API keys be reviewed?

Use a risk-based monthly or quarterly schedule and review immediately after vendor, staff, server or strategy changes and any security event.

What should I do if the Secret Key was exposed?

Revoke the key immediately, stop its integration, inspect orders and transfers, close the exposure path and issue a minimally scoped replacement only if still required.

Why does MEXC reject a whitelisted key?

The request may leave through a different public IP than expected. Verify the actual outbound address and compare it with the configured list.

Can I deposit directly to every sub-account?

Do not assume so. Current MEXC instructions describe managing sub-account assets through internal transfers. Follow the live interface and official guidance for the account type.

Final takeaway

The safest MEXC integration is not the one with the most permissions. It is the one whose purpose, key, origin, sub-account, balance and owner are easy to identify. Start with read-only access, add only necessary writes and use an IP restriction when the request origin can be controlled.

Sub-accounts contain strategy exposure but do not replace account security or custody planning. Test every boundary, monitor activity independently, rotate deliberately and delete access when the job ends. If a credential leaks, revoke first and investigate second.

Official MEXC resources

Use these official pages to confirm current controls, permissions and platform behavior:

• MEXC Official Blog: platform announcements, product updates and educational material.
• MEXC Spot API Documentation: authentication, permissions, IP restrictions, endpoints, errors and rate limits.
• MEXC Sub-Account & API Key Setup Manual: official creation workflow and Secret Key handling guidance.
• MEXC Guide to Managing Sub-Accounts: account types, APIs, asset management, transfers and login history.
• MEXC Automated Trading Rules: current authorization and enforcement information for API automation.
• MEXC Help Center: official support and current account instructions.