Alongside the new panel, you can now talk to your account in code. The new developer API is a clean, versioned REST interface for listing your sites, reading their status, managing projects and working with your DNS, all without clicking through the panel. It runs on its own address and speaks JSON only, so it slots straight into your scripts, deploy pipelines and dashboards.
This first release is deliberately read-heavy and built to be safe to automate against.
What you can do today
The API mirrors what the panel already shows you, and nothing more. With a token you can:
- List and inspect your sites: every site, its live status, PHP version, SSL state and whether WordPress is installed.
- Read and change your DNS: list every record in a zone (the ones we manage for you are clearly flagged), and add, edit or remove your own records.
- Organise your account: list, create, rename and delete projects, and move a site between them.
- Provision new work: create a site, switch its PHP version, turn SSL on, and install WordPress.
Everything is versioned under /v1, so as the API grows your scripts keep working. A whoami call tells you which team a token belongs to and what it’s allowed to do. Handy for confirming a key is wired up correctly.
The API is intentionally read-mostly. There are no destructive operations: you can’t delete a site or wipe a WordPress install through it. Anything irreversible still lives in the panel, behind a confirmation. More write actions are coming.
Safe by design
A public API touching your live sites has to be careful. A few choices keep it that way:
- Team-scoped tokens. Every token is tied to one team, the boundary it can never cross. A request only ever reaches that team’s sites, projects and records, so there’s no way to address someone else’s data.
- Scopes for least privilege. By default a token has full access, like most APIs you use. But you can lock one to a specific job: a read-only key for a status dashboard, or a
dns:write-only key for a deploy script. The scopes aresites,dns,wordpressandprojects, each in a read and a write flavour. - UUID addressing. Sites, records and projects are referenced by their UUID, never a guessable number, so you can’t walk the API by counting upward.
- Idempotency-Key for safe retries. Send this header when you create a site or install WordPress. If your script retries after a dropped connection, we return the original result instead of starting a second site. A request still running gets a clear
409.
The API also enforces rate limits so a runaway loop can’t run away with your account. Reads are generous, writes are tighter, and provisioning calls get the strictest budget. Go over and you’ll get a 429 with a Retry-After header.
A quick taste
Authenticate with a bearer token and call the API host. Listing your sites looks like this:
curl https://api.ip-networx.com/v1/sites \
-H "Authorization: Bearer ipxapi_your_token_here" \
-H "Accept: application/json"Responses come back as JSON with a data envelope, and lists add a meta block with pagination. The full endpoint reference, status vocabulary, and worked examples ship with the API documentation you get when your token is issued.
Getting a token
Tokens are minted on request to start with. Tell our team which team it’s for, give it a name, and say whether you want full access or a restricted set of scopes. We’ll issue it and hand you the secret once. Store it somewhere safe: the token is shown a single time and can’t be recovered afterwards (we only keep a hash). If a key leaks, we revoke it and issue a fresh one.
Self-service token management (create, list and revoke your own keys from the panel) is coming soon. Until then, our team will walk you through requesting one, how scopes work, and how to keep your credentials safe.