ProxioDocs
API Reference

API Changelog

Additive-tagged changes to the Proxio API. Under the v1 stability policy, new fields, endpoints, events, and error codes ship continuously without breaking existing clients. Describes the current v1 surface.

Changes to the Proxio API, newest first. Under the v1 stability policy, everything listed here is additive: new fields, endpoints, event types, and error codes may ship at any time, and none of them break existing clients, so long as you ignore fields you don't recognize. A change that would remove or rename anything ships instead as a new major version with 12 months notice.

v1 (additive, since 2026-07-19)

The current v1 surface at https://dashboard.proxio.net/api/v1, live since 2026-07-19. This is a rolling entry, not one snapshot per change: it's updated in place as additive changes ship, so check back here rather than expecting a new dated entry for every field or endpoint that lands.

Conventions

  • One Bearer authentication scheme (pxo_… keys) with read / write / purchase scopes, per-key IP allowlists, and expiry, manageable from the dashboard or from the API Keys endpoints themselves.
  • A single response envelope and a complete error catalog with request_id and doc_url on every error, including IP_UNAVAILABLE for whitelist conflicts. An unsupported HTTP method on a real path answers in the same envelope, with an Allow header, there's no bare framework 405 left anywhere in /v1.
  • Cursor pagination on every growing list, with meta.has_more alongside meta.next_cursor. Several lists (orders, wallet transactions) also take sort, order, and created_after / created_before; a cursor is only valid under the ordering it was issued for.
  • Rate limiting with X-RateLimit-* headers and Retry-After, plus a per-account throttle on whitelist additions (and batch adds), a per-credential throttle on session rotation, and a per-account throttle on webhook redeliver. A request the rate limiter itself refuses doesn't cost budget, and Retry-After on a 429, 502, or 503 is now solved so that honoring it succeeds.
  • Idempotency on mutations, required on the three endpoints that touch money.
  • ETag / If-None-Match conditional requests on the two catalog endpoints (Locations, Products), a 304 on an unchanged catalog costs a header round trip instead of the full body.
  • BigInt-safe byte quantities for all bandwidth fields.

Endpoints

  • Account, Products, Locations, API Keys, and Wallet (balance, transactions, and top-ups: opening one returns a payment link, the balance moves only once the provider confirms).
  • Services: list, detail, connection info with delivery of gateway (residential) or static (ISP/DC), and a PATCH to toggle auto-renewal.
  • Usage: summary and time series with close-reason breakdowns.
  • Proxy list generator with txt / json / csv output, username-embedded targeting including ASN, and connection retry parameters (retry, retry_rotate, session_id).
  • Credentials (create, update, delete, rotate) with quota_mb / quota_gb / quota_kb traffic caps, whitelist IP bindings (single or batch, up to 50 at once), and sticky sessions.
  • Orders: list, detail, quote (price without buying, read scope), wallet-paid purchase, and renewal. Renewal covers top-up (metered) and validity extend. extend is available for unlimited ISP/DC only, a config-driven days extension priced per active IP slot; it returns UNSUPPORTED_OPERATION for metered residential services. Residential packages instead stay current through auto-renewal, which charges the current price for another cycle automatically, there's no manual extend or prepaid billing periods for residential.
  • Webhooks: 14 event types, three delivery formats (json / discord / slack, each registered with a single endpoint URL), signing-secret rotation on json, endpoint management, and test deliveries. Deliveries adds a 30-day per-endpoint delivery log, redelivering a past event (including one that already succeeded), and an account-wide event log across every endpoint.

Tooling

Staying current

Watch this page for additive changes. Nothing in v1 is deprecated yet, so the Deprecation and Sunset headers aren't on the wire today, but log them from the start anyway so the day v1 has its first deprecation, it surfaces in your monitoring well ahead of time instead of catching you at the Sunset date.

On this page