Documentation Index
Fetch the complete documentation index at: https://mintlify.com/pacifica-fi/docs-migrate/llms.txt
Use this file to discover all available pages before exploring further.
Pacifica enforces rate limits using a credit-based system measured over a 60-second rolling window. Every API action consumes a number of credits, and when your available credits are exhausted the API returns HTTP 429 Too Many Requests. Credits replenish continuously as time passes within the rolling window — there is no hard reset at a fixed clock boundary.
Credits are shared across a main account and all of its subaccounts. If a subaccount consumes credits, that reduces what is available to the main account and every other subaccount within the same 60-second window.
Base Quotas by Connection Type
The starting quota depends on whether the request includes a valid API config key:
| Connection Type | Base Credits / 60s |
|---|
| Unidentified IP | 125 |
| Valid API Config Key | 300 |
Fee-Tier Quotas
Accounts that qualify for a higher fee tier receive an elevated rate limit that scales with their tier. These limits apply when requests are made with a valid API config key associated with the account.
| Tier | Credits / 60s |
|---|
| Tier 1 | 300 |
| Tier 2 | 600 |
| Tier 3 | 1,200 |
| Tier 4 | 2,400 |
| Tier 5 | 6,000 |
| VIP1 | 20,000 |
| VIP2 | 30,000 |
| VIP3 | 40,000 |
Obtaining an API config key is the single most impactful step for increasing your rate limit. Even at the base tier, an identified key triples the unidentified IP quota from 125 to 300 credits per 60 seconds — and unlocks fee-tier scaling on top of that.
Credit Costs Per Action
Not all requests cost the same number of credits. Cancellations are cheap; heavy data-fetching requests cost more.
| Action | Unidentified IP | API Config Key |
|---|
| Standard request / order action | 1 | 1 |
| Order cancellation | 0.5 | 0.5 |
| Heavy GET requests | 3 – 12 | 1 – 3 |
All credit values in response headers and WebSocket fields are multiplied by 10 to support fractional costs. For example, r=1200 means 120.0 credits remaining.
WebSocket Limits
In addition to credit-based limits, WebSocket connections are subject to two hard caps:
- Maximum 300 concurrent connections per IP address
- Maximum 20 subscriptions per channel per connection
Checking Your Remaining Credits
Every REST response includes rate limit headers:
ratelimit: "credits";r=1200;t=32
ratelimit-policy: "credits";q=1250;w=60
WebSocket — Action Response Field
Authenticated WebSocket action responses include an rl field:
{
"rl": {
"r": 1200,
"q": 1250,
"t": 32
}
}
| Field | Description |
|---|
r | Remaining credits (×10) |
q | Total quota for the window (×10) |
t | Seconds until the window refreshes |
ratelimit-policy header additionally includes a w field indicating the window size in seconds (always 60).
API Config Keys
An API config key is a short-lived credential attached to an HTTP request header that associates the request with a Pacifica account. Unlike signing keys, config keys are not used for cryptographic authentication — they are purely for rate-limit attribution.
Getting a Config Key
Config keys are generated via the REST API. Each account can hold up to 5 active API config keys at one time. The Python SDK provides ready-to-run examples for creating, listing, and revoking keys.
POST /api/v1/account/api_keys/create
POST /api/v1/account/api_keys/revoke
POST /api/v1/account/api_keys
{
"data": {
"api_key": "AbCdEfGh_2mT8x..."
}
}
"{8_char_prefix}_{base58_encoded_uuid}". The 8-character prefix enables fast server-side lookup.
For custom quota discussions or limits beyond the standard tiers, reach out in the Discord API channel.
Using a Config Key
Pass the key in the PF-API-KEY header alongside your requests.
REST:
import requests
headers = {
"Content-Type": "application/json",
"PF-API-KEY": "AbCdEfGh_2mT8x...",
}
response = requests.get("https://api.pacifica.fi/api/v1/orders", headers=headers)
websockets library):
import websockets
async with websockets.connect(
"wss://ws.pacifica.fi/ws",
extra_headers={"PF-API-KEY": "AbCdEfGh_2mT8x..."},
) as ws:
...
Handling 429 Too Many Requests
When you exceed your credit quota the server responds with HTTP 429. The correct strategy is to back off and retry — never tight-loop on a 429 response.
import time
import requests
def request_with_backoff(url, payload, headers, max_retries=5):
delay = 1.0 # seconds
for attempt in range(max_retries):
response = requests.post(url, json=payload, headers=headers)
if response.status_code == 429:
print(f"Rate limited. Retrying in {delay:.1f}s (attempt {attempt + 1}/{max_retries})")
time.sleep(delay)
delay *= 2 # exponential back-off
continue
return response
raise RuntimeError(f"Request failed after {max_retries} retries due to rate limiting.")
Retrying immediately after a 429 wastes credits and deepens the quota deficit. Always wait at least the number of seconds indicated by the t field in the rate limit header before retrying.
- Monitor the
r (remaining) value in response headers and slow down proactively before hitting zero
- Batch multiple order operations into a single batch-order request where possible
- Use WebSocket subscriptions for streaming data rather than polling REST endpoints repeatedly
- Assign an API config key to unlock fee-tier scaling even at lower trading volumes