The request returns the node’s entire state at once, as a structure. The format is your choice — XML or JSON, and the structures match field for field, so the reading side can take either.
This is the only endpoint for which the manual gives the full output — and in both formats. For the others the documentation is sparser.
Its coverage is wider than that of the page it mirrors. Besides traffic and queues, the response carries the product name, version, build date and revision; the license serial number; information about the machine; the state of the resolver and the spool; a flag for whether the node is running.
Hence its role: one request gets a snapshot that is enough both for monitoring and for identifying the node — what version, what license, how much is in use.
⚠️ What is not in the response, we do not have either. The license level comes as a serial number, not a tier, so the connection ceiling is unknown to the Hub (licensing). Events between measurements are lost: the poll will miss a queue’s short spell in backoff mode (backoff-mode).
The Hub gets accounting separately — as a stream through a webhook, not with this request. The separation is right: state is queried, events are received.
What to ask with this request and what not:
| Question | Does it answer |
|---|---|
| what is going on with the node now | yes — that is its purpose |
| which version and license | yes, including the serial number |
| how many messages went out in the last hour | no — that is accounting |
| when the queue was in backoff mode | no — that is the queue history |
The format is chosen by the reading side. The structures match, so there is no difference beyond parsing convenience.
The polling frequency is a compromise. More often means fewer missed events and more load; less often, the opposite. Events that must not be missed are more reliably taken from accounting than by polling more often.
# a node snapshot in one request curl -s 'http://127.0.0.1:8080/status?format=json'curl -s 'http://127.0.0.1:8080/status?format=xml'
what people get wrong and how it ends3 mistakes▶
§ 5.3
§ 5.3
§ 5.3
4 relations
Node statusThe same status page, only for a human. § 5.3Node status in the consoleThe same state from the command line. inference
curl -s 'http://127.0.0.1:8080/status?format=json' | head -40 pmta show status
3 articles
◇Exposing metrics to a collectorExposing the node’s metrics to an external collector in its format.◇The activation key is a prerequisite for installation, not a step after itWithout an activation key from SparkPost support the engine neither installs nor runs, and the license tier sets the outbound connection ceiling: on Standard everything above 200 is ignored.◇What the node tells about itself and through which channelsSeven observation surfaces: the web monitor, the console in four formats, the log, accounting, accounting search, metrics and export to external analytics.