What It Takes to Connect a Platform to Something Else

Two shapes of interface, used for different things

A broker’s programming interface generally comes in two shapes. One answers a question each time it is asked and says nothing in between: a request goes out, a response comes back, and until the next request nothing further is known. The other holds a connection open and sends updates as they happen, so information arrives without being asked for.

Brokers commonly offer both, and they are not alternatives in the way a menu of options would suggest. They answer different questions. Anything that needs a definite answer about a specific thing at a specific moment — the state of this order, what the account currently holds — is a question, and questions belong to the first shape. Anything that needs to know as things change belongs to the second.

Polling has a floor it cannot get under

Asking repeatedly for a price rather than subscribing to it gives a picture that is never fresher than the interval between requests. Halving the interval halves the staleness and doubles the request count, and there is a point past which the broker will not accept the count. So there is a floor under how current a polled view can be, and where that floor sits is decided by someone else.

It matters more than it sounds, because staleness travels. Any decision, any display, any comparison made from a polled figure inherits the age of that figure without carrying a label that says so. A system that polls and then acts is acting on a number whose age it usually has not written down anywhere.

One limit is usually several limits

A rate limit is a cap on how many requests an account may send within a period, and it is rarely a single number. Different endpoints are counted separately, and the allowance for reading prices is typically not the allowance for sending orders. A system sized against the generous one can be refused on the strict one, and it will be refused at the least convenient moment, because order traffic tends to cluster exactly when price traffic does.

Which limits apply and how they are counted is documented by the broker rather than discoverable by experiment. Finding the wall by walking into it means spending refusals to learn where it stands, on a live account, at whatever moment the walking happens to occur.

The expensive way to handle a refusal

Retrying immediately makes a rate limit worse, because the retries are counted too, and a system that responds to being throttled by trying harder throttles itself further. Backing off rather than pushing is the whole of the correct behaviour here, and it is unintuitive precisely because most other kinds of failure reward persistence.

The more serious problem is that a refusal is not always distinguishable from other failures. A request that timed out on the client side may still have been received and acted on, and treating no answer as no order is how a system sends the same order twice. Anything that trades through an interface has to establish what actually happened — by reading the account back — before it acts again. That is a different operation from retrying, and it is the one that has to come first.

A stream that is open and silent

Streaming removes the polling floor and brings its own work in exchange. Connections drop and have to be re-established. Updates missed while disconnected have to be recovered from somewhere, which usually means asking the other kind of interface for the current state rather than assuming the gap contained nothing.

The difficult failure is neither of those. It is a connection that is still open and has stopped delivering, which looks exactly like a quiet market — because a quiet market also delivers nothing. Examining the content of what arrived cannot separate them, since in both cases nothing arrived. What separates them is time: the age of the last message rather than anything in it. Software that consumes a stream needs something that goes stale on its own and says so, or it will read a dead connection as calm conditions for as long as the condition lasts.

An alert sent to an address is one-way

A webhook alert is the platform sending a message to a web address the reader supplies when a condition defined on a chart is met, instead of — or as well as — showing it on screen. It is the usual bridge between analysis in one place and action in another, and the appeal is obvious: a condition expressed on a chart becomes an input to some other piece of software.

What is worth understanding is that it is fire-and-forget. The sender generally learns whether the message was accepted and nothing whatsoever about what was done with it. Deliveries can arrive late, out of order, or more than once. A message that fails may or may not be retried, and that policy belongs to the sender rather than to the reader. None of this makes the mechanism a bad one. It makes it a mechanism whose guarantees are weaker than they look, and assuming the stronger ones is how a quiet failure gets built in at the start.

The address is not a credential

A receiver has no way of telling who sent it a request unless the request proves it. The address is therefore the only thing standing between the alert and anybody else who learns the address, and addresses leak in ordinary ways: pasted into a support ticket, copied into a shared document, left visible in a screenshot.

So a receiver that acts on what arrives carries two obligations, and both follow from everything above. It has to authenticate the message rather than trusting the fact of its arrival, and it has to tolerate seeing the same message twice without doing the thing twice. Neither is interesting work, both are easy to defer while a setup is still being tested, and together they are the difference between a bridge and a hole.