InterServer: "pending" does not mean unpaid

If you integrate InterServer's VPS API and you read one status field to decide whether a machine is ready, you will tell customers their paid server is still waiting for payment. We know because we did the experiment: ordered a real machine, paid it from prepay, and watched what the API said while it came to life. This is what we found, and why the fix is to read three fields instead of one.

Everything here was measured against a live InterServer account with a real order and a real payment. It is one machine, so treat the timings as an observation and not a guaranteed ceiling.

The measurement

We placed an order, paid it, and polled. The field named vps_status (the obvious one, the one you would reach for first) reported "pending" for 46 minutes. For all 46 of those minutes, the invoice's service_payment_status read "Paid".

So vps_status: "pending" and "the customer has not paid" are two completely different things that happen to share a word. pending on this API does not mean "awaiting payment". It means "not provisioned yet": the order is paid, InterServer simply has not finished building the machine. An integration that maps pending to "awaiting payment" shows a paid customer a "please complete payment" screen for the better part of an hour, which is the fastest possible way to earn a support ticket from someone who already paid.

Three fields, three meanings

The mistake is trying to answer three separate questions with one field. InterServer actually gives you three, and each answers exactly one question:

Read them together and the machine's real state is unambiguous at every moment. Read vps_status alone and you conflate "not paid", "not built" and "not running" into one word that means none of them cleanly.

The full timeline

Here is the whole lifecycle we timed, from payment to a usable machine:

t+0        payment accepted    service_payment_status: Paid
t+0        vps_status: pending          (stays here ~46 min)
t+46.3m    vps_status: pending-setup    (~6 min)
t+~52m     IP address appears
t+~52m     vps_status: active

About 52 minutes, end to end, of which 46 were spent in pending with nothing visibly happening. The public IP address showed up roughly half a minute before active, so even "the machine has an address" arrives late. If you are building a product on this, the customer-facing promise has to be "ready within the hour", and your provisioning logic has to be an observer of a slow status transition, not a command that blocks until the machine is up. A command that waited would hang open for 52 minutes.

vps_status also lies about power

The status split matters after provisioning too, and this is the second half of the trap.

Once a machine is active, it stays active, even when you power it off. Turning the machine off does not move vps_status back to anything; only vps_server_status changes, from running to shut. So an integration that reads vps_status to render the power indicator shows a switched-off machine as running, forever, with no error anywhere. The field that tracks power is vps_server_status, and it is the only one that does.

There is a related edge we hit when a machine was cancelled. A cancelled VPS (vps_status: "canceled") still keeps a valid vps_server_status. Our first cut read canceled as "state unknown" and threw away the on/off reading in the process; a cancelled machine that is still running until its paid-through date then showed as neither on nor off. The correct reading is that vps_server_status means the same thing regardless of vps_status: power is its own axis, and it stays meaningful even after cancellation.

The same shape of mistake elsewhere in the API

Once you have been bitten by a field that reads like an answer but isn't, you start noticing others on the same API. Two we had to work around while building the integration:

• serviceMaster describes the physical node, not your machine. It reported vps_cores: 96 for a VPS built from a single slice. Those 96 cores are the host's, not yours. The per-machine specs live in a different object; read that one.
• slice_hd is 0 on the high-storage platform, where the catalogue says the slice carries 1000 GB. A zero reads like a real measurement, which is worse than a missing value: a disk that should be 1000 GB showing as 0 would sail past any sanity check that only guards against absurd sizes, because 0 is not absurd, it is just wrong. We derive the disk size from the catalogue constant for the platform instead of trusting that field.

Neither of those is a status field, but they are the same lesson: on this API, a populated field is not automatically a truthful one, and the fix is always to read the field that actually carries the fact.

What to do with it

If you are integrating InterServer yourself, three rules cover the cases above:

1. 01Never decide "paid?" from vps_status. Read service_payment_status for payment, vps_status for provisioning, vps_server_status for power. Three questions, three fields.
2. 02Provision as an observer. Poll the status transition; do not issue a command and wait on it. Budget for an hour.
3. 03Treat a populated field as a claim, not a fact, and read the field that carries the thing you actually want: the per-machine specs object, not serviceMaster; the catalogue constant, not slice_hd.

How Provibr handles it

Provibr models InterServer with a status that means "paid, provisioning" precisely so that a machine which is paid-but-not-yet-built never renders as "awaiting payment". Power comes from vps_server_status, so a machine you switched off reads as off rather than running. The specs come from the per-machine object and the platform catalogue, not from the node's field or the zero. And because delivery can take the better part of an hour, ordering and the machine going live are two separate things: the order answers immediately, and the machine coming up is something the panel observes.

We support InterServer live, and a machine on it pays us the same €0.20 per month to manage as a machine anywhere else, so this is written to help you integrate rather than to sell you a verdict on InterServer. One disclosure belongs here in full: we earn an affiliate commission when someone opens an InterServer account through our link, and you will see that link marked as such. The API is perfectly usable once you know which field means what; the cost is entirely in finding that out, which is what this page is for.

Read next

• How to sell VPS with InterServer: the slice model, the single API key, and what ordering spends.
• Hetzner Cloud vs InterServer: the two suppliers side by side.
• InterServer setup: the API key and what the connection test checks.

Measured against a live InterServer account in August 2026, with a real order and a real payment. One machine was timed, so the durations are an observation rather than a bound. No account, machine or network identifiers from that account appear here.