Exchange API key without withdrawal: a guide

An exchange API key is a credential the venue will accept in place of a logged-in person, inside the permissions you ticked when you created it. It is not a password for the whole website, and it is not a seed phrase for a wallet. Those distinctions get blurred in chat messages, which is how keys end up with powers nobody meant to grant. This note keeps the distinctions sharp, and it keeps one fact sharper: the Captay website does not take a key.

Scopes are a list, not a vibe

Venues split access into bits with local names. The bits that matter for this design are roughly: see balances and orders, place and cancel orders, move funds inside the venue, and withdraw to an address. A careful setup turns the first two on and the last two off. The labels on the screen win over any paraphrase on a product page. If a bit is named in a way you do not understand, the bit stays off until you do.

Some venues hide withdrawal behind a second confirmation or an address book. That is their control, and it is useful, and it is not a reason to enable the bit 'just in case' the product later wants it. Captay's design never wants it. A product that asks you to enable withdrawal so that automation can 'manage funds' is describing custody. Captay is describing the opposite.

Read-only is the wrong tool

A key that can only read is the right tool for a dashboard and the wrong tool for a strategy that must place an order. Automation without a trade bit can watch a limit get breached and then send you a notification you might be asleep for. That can be a product. It is not this product. Captay's strategies are order-placing rules. They need the trade bit, and they need to be wrapped in limits because the trade bit is enough to do harm.

The harm is not theatrical. A loop that buys a thin market can walk the price against itself. A repeated market order can pay the spread all afternoon. A bug that ignores a position cap can keep going until the quote balance is gone. None of those outcomes require a withdrawal. If your threat model stops at 'they cannot steal the coins to another chain,' you have modeled theft and ignored loss.

Withdrawal is the wrong extra

The withdrawal bit lets the key ask the venue to send coins to an address. Combined with a leaked key, it is a direct path off the account. Leaving it off does not make the rest of the key cute. It does mean a faulty or hostile process that holds only that key cannot invent a transfer the venue will honor. The venue is the enforcer. Captay's software, however careful, is not a second enforcer of a permission it was never given.

Internal transfers are easy to overlook because they feel like rearranging your own furniture. If the bit can move funds to a sub-account you do not watch, it is not furniture. Treat it as withdrawal-adjacent and leave it off unless you have a reason that survives a reread the next morning.

Leakage and rotation

A trade key pasted into a chat, a ticket, or a form has the same power as a trade key stored in a vault, until you delete it. The paste is the leak. Deleting the key on the exchange ends that credential even if a copy remains in someone else's logs. Creating a new key with the same careful bits is the rotation. Writing the old secret into a password field 'so support can see the error' is how the rotation fails.

IP allow lists, where a venue offers them, shrink the set of networks that can present the key. They do not shrink what the key can do once presented from an allowed network. They are worth using later, on the venue's screen, as your control. They are not a control Captay can promise, because Captay does not operate your allow list and does not, today, have an address to put on one.

Storage that does not exist yet

A future cabinet would have to keep a trade key in order to sign orders. The privacy note says that store would be encrypted and is not built. Encryption answers a storage question: a disk image should not contain a usable secret in the clear. It does not answer a behavior question. The process that can decrypt the key can also send the order. The limits and the halt are the behavior controls. They are designs, not a running process, and they do not make a stored key harmless.

This website has no key field, no upload, and no support chat that will ask you to paste one 'temporarily.' If you find such a field, it is not this release. The contacts form accepts text that looks like an email and then keeps it in the page. A key is not an email. Do not discover what the validator does with one.

A checklist you can do without Captay

Create nothing while the cabinet is closed. A key with no consumer is a key waiting for a leak.
When a consumer exists, tick trade and read, and leave withdrawal and internal transfer off.
Prefer a fresh key over reusing one that has already lived in another tool.
Delete the key on the venue the moment the experiment ends or the moment you cannot explain where copies are.
Never send the secret to a person who offers to 'check the permissions for you.'

The checklist is ordinary hygiene. It is not a claim that following it makes automation safe, and it is not a claim that Captay has reviewed your venue's screen. No orders are leaving this site while you read. The useful outcome of the note is a smaller key, later, not a key today.