How to Track HTX Without Your Key Dying Every 90 Days

Most exchange API keys live until you delete them. HTX made a different choice, and it is the first thing to understand before you connect the account to anything, because otherwise you will set this up twice a year and never work out why.

The rule is short: a key with no bound IP address expires after 90 days. Bind an address and the clock does not apply. Leave the field blank and the key works perfectly for three months and then stops, with no warning and no way to revive it.

Why does HTX kill my API key after 90 days?

Because an unbound key is a bearer token. Anyone who obtains the key and secret can use them from anywhere on earth, and HTX's answer is to force a decision: either you tell us where requests will come from, or we assume the credential will eventually leak and we retire it on a timer.

That reasoning is sound. It also creates an awkward problem for anyone using a phone-based tracker, because you do not know the address your tracker connects from. The tracker's servers make the request, not your handset, and your home IP is worse than useless in that field — entering it blocks every sync while looking like a broken connection rather than a misconfiguration. This is the same trap covered in read-only API keys, and it accounts for a large share of connections that never work at all.

So the honest options are two. If the service you are connecting publishes the addresses it calls from, bind those and the key becomes long-lived. If it does not, leave the binding empty, accept the 90-day life, and put a recurring note in your calendar to regenerate. Regenerating is a two-minute job and it has a side benefit: rotating credentials on a schedule is good practice you would otherwise never get round to. Revoking an API key covers the clean-up half of that cycle.

What you must not do is solve the expiry problem by ticking more permissions. Expiry has nothing to do with scope, and a key with Trade enabled dies on exactly the same schedule while carrying far more risk.

Which HTX permission is the read-only one?

HTX splits permissions three ways at creation: Read, Trade and Withdraw. Read queries balances, order status and history. Trade creates and cancels orders. Withdraw manages withdrawal requests. They are independent checkboxes, and the one a tracker needs is Read.

Tick Read. Leave trading and withdrawal permissions off, and they stay off for the life of the key, because HTX fixes the scope at creation. A key issued with Read alone cannot place an order regardless of who holds it, since HTX evaluates the permission on every request before it evaluates anything else. A read-only key cannot move funds off the exchange, full stop. That is not a promise a tracker makes to you, it is a constraint the exchange enforces, which is the distinction that matters and the one is it safe to connect an exchange is built around.

The sequence:

1. Sign in to HTX on the web and open API Management from the profile menu.
2. Choose the key type. HTX offers a system-generated key pair and a self-generated option where you create the key material yourself and upload only the public half. The self-generated route means your secret never crosses the network, which is a real improvement if you are comfortable with it; the system-generated route is what most people pick.
3. Name the key after the application that will use it, not after yourself. In six months "portfolio tracker" tells you what to revoke and "key1" does not.
4. Tick Read. Leave Trade and Withdraw untouched.
5. Bind an IP if you have one to bind. If not, leave it blank and diarise the 90-day renewal.
6. Complete the verification step and copy both strings. The secret is shown once.

One caution before you paste anything: HTX credentials are a common phishing target, and the pages that ask for them are easy to imitate. Create the key on the exchange's own site in a tab you opened yourself, never from a link in a message, and never type a key into anything that also asks for your login password or a recovery phrase. Fake crypto apps covers what the imitations look like.

Why can a tracker only see part of what I hold on HTX?

Because HTX is not one account. It is several, and a spot read key reads one of them.

Spot sits in its own wallet. Cross margin and each isolated margin pair sit in theirs. Contracts run on a separate business with a separate API domain, so a spot key does not reach a futures balance even in principle. Earn products, locked staking and pool positions hold assets in states that a plain balance query does not return. The result is a tracker reporting a number that is precisely, honestly too low, which is the single most common complaint about connecting any large exchange and is worked through in why your portfolio balance is wrong.

Locked and staked positions are the ones people forget, because they were deliberately parked and then dropped out of mind. Tracking staked assets explains what each position type looks like from the outside. When something genuinely will not resolve — a locked term product, a pool position with no readable balance — the fix is not to keep hunting for a key that sees it. Enter it as a manual position with its real acquisition price so your cost basis survives, as described in adding a manual position, and revisit it when the term ends.

Before you accept any of this as a limitation, do the boring check. Open HTX, write down the balance each section reports, and compare. A gap you can name is a gap you can fix; a gap you assume is a gap that quietly corrupts your allocation for a year.

Do I connect the master account or a sub-account?

Whichever one holds the money, and possibly both.

HTX sub-accounts are fully separate identities. Each has its own login credentials and issues its own API keys, and a parent-account key does not read across into them. The allowance is generous, so people who trade several strategies often end up with holdings scattered across three or four sub-accounts, each invisible to the others. HTX also restricts sub-account keys to reading and trading, with no withdrawal permission available at all, which is a sensible default and irrelevant to tracking since you are not enabling withdrawal anywhere.

The practical answer is one read-only key per account you want visible. That means one per sub-account plus one for the parent, each named after what it reads, each created with Read only, each either IP-bound or on your quarterly renewal list.

That sounds like housekeeping because it is. The alternative is a portfolio total that is confidently wrong, and the cost of confidently wrong compounds every time you decide how much of something to buy on the strength of it.

Get the connection right once and HTX becomes a line in a total rather than a tab you check. The next question worth answering is not how to see the number faster, but what should reach you when it changes enough to matter.