Skip to main content
Stored configuration alone is too slow to be a control. The gateway notices a database change on its next poll, up to thirty seconds later — and toggling something off and back on inside that window nets to no difference at all, so the gateway never hears about it. These verbs apply immediately.

​
They mean different things on a vendor and on a listener

Both kinds of worker take the same verbs, and the same verb does a different job on each — which is the point. A vendor is somewhere traffic goes; a listener is where traffic comes from, and it also carries receipts back to a customer. So “stop sending” on one is not the same act as on the other.
Before 0.9.21 the controls did not act on a listener’s own traffic at all. Stop sending and Hold on a listener paused only the loop carrying receipts back to bound customers; submitted messages kept going out. If you are running an earlier build, this is the release to take.

​
On a vendor

​
On a listener

​
Choosing between them

The right default for a vendor problem. New traffic finds an alternative route immediately and the session stays bound, so you can test it without a fresh bind.Expect total outbound volume to stay flat, because the traffic went somewhere else rather than stopping — look at the other vendors’ counters, not the total, to confirm it worked.
For a short window where you would rather hold a customer’s traffic than refuse it: a route being edited, a vendor being swapped. The customer sees nothing wrong, and every message is delivered when you resume.
Parked messages are charged and are held in memory. The customer has been told the message was accepted, so it is owed — but the parked copy does not survive a restart, and the parked count is capped. Past the cap the listener refuses further submits before charging them. Watch the parked count on the worker’s health block and do not leave a listener parked for long.
The stronger control, and the safer one for anything longer than a moment. Nothing is accepted, nothing is charged, and nothing accumulates on this gateway. The customer’s own stack holds their backlog and retries, which is where a backlog belongs.
The worker leaves /ops/health completely, which is worth knowing before you go looking for it in a dashboard and conclude something has crashed.Use it when you want the worker gone rather than paused.
A held vendor’s queue grows, so watch queue_depth and queue_capacity. Under a capacity limit the gateway eventually refuses new traffic rather than growing — reaching customers as ESME_RMSGQFUL or a 503. Holding is not free; it converts a vendor problem into an ingress problem if you leave it long enough.

​
These are runtime state, not configuration

A disabled or suspended worker returns on restart unless the stored configuration says otherwise.These verbs exist to act now; they do not edit the configuration. If you want the change to survive a restart, make it in the panel as well — and if you want it only until the restart, that is exactly what these give you.

​
Testing a vendor before you trust it

Dials once and reports the outcome, without waiting for the reconnect cycle.
It is refused while the vendor is already bound, deliberately. A second bind on the same systemId can cost you the live session, and many carriers allow only one.Use it before traffic depends on the vendor, or after suspending it — suspending keeps the session, so suspend then test is not the sequence that works. Disable, then test.

​
Dropping one customer’s bind

A listener session can be disconnected by id. A vendor session cannot — that answers 409, because the guard is the worker kind rather than the presence of a session id. Disabling a login also drops its live binds, which is the difference between “they cannot reconnect” and “they are gone now”.

Live health

Reading queue_depth, bound_transmittable and last_error.

Reloading configuration

The other way to change what the gateway is doing.