Developer API

A machine leaves from a datacenter IP, and a large share of the web treats those ranges as hostile. Pass a proxy object to POST /v1/machines to route its outbound traffic somewhere else. Two modes: managed uses Coasty's residential upstream, and custom uses a proxy you supply. Omit the object entirely for no proxy, which stays the default.

# Coasty's residential proxy — one flag, nothing else to supply
curl -X POST https://coasty.ai/v1/machines \
  -H "X-API-Key: $COASTY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "scraper",
    "proxy": { "mode": "managed" }
  }'

# Your own proxy
curl -X POST https://coasty.ai/v1/machines \
  -H "X-API-Key: $COASTY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "scraper",
    "proxy": {
      "mode": "custom",
      "scheme": "http",
      "host": "gate.example.com",
      "port": 10001,
      "username": "user-abc",
      "password": "secret"
    }
  }'

The proxy is proven, not just configured. Before a machine is reported ready, Coasty fetches the machine's egress address twice from inside it — once through the proxy and once directly — and requires them to differ. If traffic is not actually leaving through the proxy, provisioning fails with PROXY_EGRESS_UNVERIFIED rather than handing back a machine that browses from its datacenter IP. That check exists because a successful request through a proxy does not prove much on its own; comparing the two addresses does.

Authentication is handled for you. No browser can be given proxy credentials — Chrome has never parsed them from --proxy-server and supports no SOCKS5 authentication at all, and Firefox raises a modal dialog that hangs the page. Coasty runs a small authenticating forwarder beside the agent and points the browser at it over loopback, so an authenticated HTTP, HTTPS, or SOCKS5 upstream all work the same way.

Managed exits are leased. Each exit in the managed pool is a distinct sticky residential IP, and a machine holds one for its lifetime so a session stays on one address. When every exit is in use you get PROXY_PORTS_EXHAUSTED, which is retryable and safe to retry with the same idempotency key — releasing a machine frees its exit.

Credentials are write-only. proxy.password is encrypted at rest, bound to the machine it belongs to, and never returned by any endpoint. Reads give you a masked username and a fingerprint so you can tell two credentials apart without being handed either:

{
  "proxy": {
    "mode": "managed",
    "scheme": "https",
    "host": "gate.example.com",
    "port": 10001,
    "status": "active",
    "authenticated": true,
    "username_masked": "us**********23",
    "credential_fingerprint": "a1b2c3d4e5f6",
    "egress_ip": "177.185.251.24",
    "verified_at": "2026-07-26T12:28:56Z"
  }
}

Hosts are validated: a custom proxy must be a public address. Loopback, link-local, and private ranges are refused, because inside a cloud guest those address infrastructure rather than a proxy. Credentials must be printable ASCII without spaces, since they are transmitted as an HTTP header. Anything else returns PROXY_CONFIG_INVALID with the specific reason.