Skip to main content
Terminal operations let you send administrative commands to a registered payment terminal and read the results. Use them to run an end-of-day close, ask the terminal to upload its logs, check for software updates, open the terminal menu, or ping the terminal to see whether it is reachable, without physically touching the device. Operations are asynchronous. You send a command, the API dispatches it to the terminal and returns immediately with a PENDING operation, and the terminal processes the command in the background. You then poll the operation to see how it finished.
Terminal operations are administrative commands. They do not start a payment. To take a payment on a terminal, see creating a terminal session.

Available operations

If the terminal’s status does not allow the operation, the API responds with 400 Bad Request. poll_terminal is never rejected on status, so it is the safe way to check a terminal you are unsure about.

Send a command

The request body identifies the terminal and the operation to run.
The response is returned as soon as the command is dispatched to the terminal. The terminal’s response is processed asynchronously, so the operation starts with status PENDING.
See POST /admin/terminals/operations for the full schema.

Idempotency

Pass an Idempotency-Key header to ensure the same command is only executed once, for example when retrying after a network error.

Check that a terminal is reachable

The poll_terminal operation pings the terminal without changing anything on the device. Use it to confirm that a terminal is online and responding, for example before you send another operation or when you are investigating a terminal that customers report as unresponsive.
poll_terminal can be sent regardless of the terminal’s status, so you can also use it on a terminal that is not ACTIVE. The operation ends as COMPLETED when the terminal answers, and as TIMEOUT when no answer arrives within the timeout window.

One operation at a time

A terminal processes one operation at a time. If an operation is already pending for the terminal, the API responds with 409 Conflict and a Retry-After header indicating how many seconds to wait before retrying.

List operation results

Poll operations to see how a command finished. The endpoint returns operations and supports filtering by terminal_id and operation_id.
To check a single operation, filter by the id returned when you sent the command.
Operations are returned most recently created first. Use limit (default 100) and starting_after with the id of the last operation you saw to page through older ones. See GET /admin/terminals/operations for the full schema.

Operation status

Which of these an operation can reach depends on the operation. open_menu and poll_terminal are never FAILED - the terminal does not report a failure for them, so an unreachable terminal ends the operation as TIMEOUT. end_of_day, send_logs and check_update are FAILED when the terminal answers but reports a problem, and the result says what it was.

Operation result

An operation that reaches COMPLETED or FAILED carries a result object whose contents depend on the operation - on FAILED it is what tells you why. A TIMEOUT operation never has a result. The examples below show only that field of the operation.
The fields inside result are camelCase, unlike the rest of the operation. The end_of_day counts and amounts are the strings the terminal reported, not numbers, and are only present when the terminal included them.
poll_terminal and open_menu report only that the terminal answered:
send_logs reports whether the terminal reached the log destination. connectionError means it did not, and the operation is FAILED:
check_update adds whether the terminal will reboot to apply an update. When terminalReboot is true, the terminal is unavailable for payments until it is back online - use poll_terminal to see when it is reachable again:
end_of_day reports the outcome and the batch totals:

Scopes

Last modified on September 18, 2026