Static proxy rentals

Static rentals grant access to addresses for paid periods. Each purchase creates an order, including repeated purchases of the same package. Use the returned order ID throughout checkout and fulfillment. Availability depends on the deployment and the authenticated account.

Discover and reserve

1. Read GET /orders/products and GET /orders/availability for products and selectable locations.
2. Read GET /orders/catalog for offers, or submit a selection to POST /orders/purchase/quote to calculate its price.
3. Reserve through POST /orders/purchase. Supply either offer_id, or term_id, quantity and location; do not mix the two forms. Keep the returned order and operation identifiers.
4. Calculate checkout with POST /orders/{id}/checkout/quote, then submit POST /orders/{id}/checkout with the documented payment fields and price confirmation.
5. Read GET /orders/{id}/rental to follow issuance and obtain address access. Payment success alone does not mean an endpoint is ready.

curl 'https://{api_host}/api/v1/orders/catalog' \
  --header 'Authorization: Static {api_key}'

Use API Reference for request bodies, payment gateways, permissions, confirmation fields and retry headers. Reuse an operation key for retries of the same documented operation, and reconcile its result before starting another purchase. Quotes do not reserve addresses. Reservations expire; an unissued reservation can be cancelled through POST /orders/{id}/cancel-reservation.

A payment arriving after its reservation is lost can leave paid_unfulfilled. Keep the invoice and order IDs and request operator resolution; do not blindly repeat the payment. The first paid period starts after successful listener binding is acknowledged.

Renew and replace

Use POST /orders/{id}/renew/quote to price a renewal and POST /orders/{id}/renew to purchase it. Select the endpoints and term using the endpoint’s request schema. Renewal adds a paid period to existing addresses. It is separate from residential traffic top-ups.

GET /orders/{id}/replacement-requests lists replacement requests; POST to the same path requests an IP replacement. A submitted request is not evidence that the address has already changed. Read current rental and endpoint state before delivering replacement connection details.

Manage rented addresses

Operation	Purpose
GET /static/endpoints	Paginated rented addresses visible to the account
GET /static/endpoints/{id}	Address, access and period details
PATCH /static/endpoints/{id}	Update the documented address access settings
GET /static/endpoints/{id}/throughput	Current rental speed
GET /static/export	Export connection URLs using the documented filters and format

Connection URLs contain credentials. Keep exports in trusted storage and redact them from logs. Access changes propagate to the proxy runtime; they are not a synchronous change on every listener.

Existing static routes

GET /static/catalog, GET /static/quotes/{offer_id}, POST /static/purchases, GET /static/purchases/{id} and POST /static/purchases/{id}/checkout remain documented compatibility routes. Purchases and checkout operate on orders; new integrations should use the order workflow above. Endpoint access and export continue using /static/endpoints and /static/export.

Order responses expose fulfillment_kind and rental_status; invoices expose rental_kind, rental_status and nullable rental_order. Use these fields to distinguish rental fulfillment from traffic accounting. See billing and the accounting model.