Introduction

The ProxyHat API lets you manage residential proxies programmatically — create and control sub-users, generate ready-to-use proxy connection strings, browse locations, track traffic, and handle plans and billing.

New here? Two pages will get you connected fastest:

  • Connecting to a Proxy — how the proxy username encodes country, session, and AI-filter options, and how to turn a sub-user into a live connection.
  • AI Version (llms.txt) — a plain-text dump of these docs for pasting into an LLM or feeding to a coding agent.

Base URL

All API requests are made to:

https://api.proxyhat.com/v1

Authenticate with an API key sent as a Bearer token:

Authorization: Bearer YOUR_API_KEY

Make Your First Request

Two steps take you from zero to a live API call.

1. Get an API key

Create a key in your dashboard API settings, or programmatically after authenticating — see Authentication for the full flow. Keys are passed as a Bearer token on every request.

2. List your sub-users

A sub-user is a proxy identity you route traffic through. This call returns all of them for your account:

curl https://api.proxyhat.com/v1/sub-users \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Accept: application/json"

To fetch a single sub-user, pass its UUID as a query filter — ?uuid= — to the same endpoint. There is no GET /sub-users/{id} route. Once you have a sub-user, generate a usable connection string with Sub-Users and Connecting to a Proxy.

Response Format

Resource endpoints — sub-users, sub-user-groups, proxy-presets, proxy-descriptors, isp-proxies, and isp-store — return a consistent envelope. For example, GET /v1/sub-users responds with:

Response 200
{
  "success": true,
  "payload": [
    {
      "uuid": "9f1c2a4e-7b3d-4c8a-9e21-0a5b6c7d8e9f",
      "user_id": "3a2b1c0d-4e5f-6a7b-8c9d-0e1f2a3b4c5d",
      "name": "scraper-01",
      "proxy_username": "user-9f1c2a4e",
      "proxy_password": "abc123def456",
      "traffic_limit": 5000000000,
      "used_traffic": 128374912,
      "is_traffic_limited": true,
      "lifecycle_status": "active",
      "provisioning": false,
      "stats_used_traffic": 128374912,
      "created_at": "2026-07-01T12:00:00.000000Z"
    }
  ],
  "meta": {
    "regular_bytes": 10000000000,
    "subscription_bytes": 0,
    "total_bytes": 10000000000
  },
  "errors": [],
  "description": "Sub-users retrieved"
}

The envelope is not universal. Auth and several read endpoints return their own flat shapes — do not expect success/payload from them:

  • POST /auth/login, POST /auth/register, GET /auth/user return flat objects (token, user fields).
  • Analytics (traffic, requests, domain-breakdown), profile, plans, payments, subscription, and coupon return bespoke shapes.
  • The location dropdowns (locations/countries, regions, etc.) return { "data": [...], "meta": { "has_more": bool } }.

Each reference page shows the exact shape that endpoint returns — copy from there, not from the envelope above.

Explore the API

Rate Limiting

Only a handful of routes are rate-limited today, and the limits differ per route. There is no single global "N requests per minute" cap.

Most authenticated resource endpoints — sub-users, sub-user-groups, proxy-presets, proxy-descriptors, analytics, profile, plans — are not throttled at present. Do not treat that as a contract: budget for future limits and handle 429 Too Many Requests defensively.

X-RateLimit-Limit and X-RateLimit-Remaining headers are returned only on the throttled routes listed above. When a throttled route is exceeded it responds 429 with a Retry-After header. Unthrottled routes send no rate-limit headers.

Content Type

Send these headers on every request:

Accept: application/json
Content-Type: application/json

Request bodies must be valid JSON for POST, PUT, and PATCH requests.