API documentation

Read-only access to Pearl transactions, addresses, blocks and mining data.

Quickstart

1. Create an account, verify your email and create an API key.
2. Store the key in a server-side environment variable and send it with each request.

curl --fail-with-body --silent --show-error \
  'https://api.prlscan.com/v2/status' \
  -H "Authorization: Bearer ${PRLSCAN_API_KEY}"

Authentication & key rotation

Send Authorization: Bearer <your-api-key> on every request. Never put a key in a URL, public frontend bundle, analytics event or source control. The key grants access to these read routes; it does not authorize profile changes, account management, chat or swaps.

Each account can have up to five active keys. All keys share the same quotas. To rotate, create a replacement, migrate your integration, then revoke the old key. Revocation prevents new admissions after it commits; already admitted requests may finish.

Official responses are private, no-store. Authentication and quota checks run even when the server can satisfy the request from its own data cache.

Endpoints

All plans include these twelve GET endpoints. Paths are relative to /v2. Unknown, duplicate and unsupported parameters return 400 before admission. Response schemas are in OpenAPI.

Classifications

Supported categories: otc_settlement, private_otc, facilitated_transfer, bridge_withdrawal, bridge_deposit, pool_payout, compute_payout, batch_payout, peel_chain, wallet_churn, consolidation, large_direct and routine_transfer.

Categories are PRLScan interpretations from transaction structure, indexed labels and known activity patterns. They are not consensus types, ownership claims or proof of a payment’s purpose. The complete transaction feed returns classification source/method, heuristic confidence and update time; transaction-label source/confidence describe that label separately. Categories can change as evidence improves.

Classification is asynchronous and historical coverage can be incomplete. An empty classified page, or a missing classification, does not establish that no transfer occurred. Use the complete transaction feed and follow block confirmations/reorganizations when completeness matters.

/v2/txs?type=coinbase&limit=25
/v2/txs?category=pool_payout&day=2026-10-27
/v2/transfers?category=bridge_deposit&sort=amount
/v2/addresses?sort=transfer_out&limit=100

Market data

The former /v2/market/prl CMC-backed price feed is unavailable pending documented redistribution rights. It returns 410 market_data_unavailable and does not consume your account allowance.

Market aggregation is not currently supported. The explorer’s website price display is separate.

Pagination, amounts & freshness

All pageable lists return items and, when another page is available, next_cursor. Treat the cursor as opaque. Send it URL-encoded in the next request, and stop when it is absent. Discovery cursors are bound to their endpoint, filters and sort; page size may change. Restart after changing filters. Do not create arbitrary offsets. The dataset remains live: reorgs, new transactions and changing balances can move rows between requests. Cursor pagination is not a frozen export.

# ADDRESS and NEXT_CURSOR come from your integration.
curl --fail-with-body --silent --show-error --get \
  "https://api.prlscan.com/v2/addresses/${ADDRESS}/txs" \
  -H "Authorization: Bearer ${PRLSCAN_API_KEY}" \
  --data-urlencode 'limit=25' \
  --data-urlencode "cursor=${NEXT_CURSOR}"

• Integer monetary amounts are in grains. Use a JSON parser that preserves 64-bit integers. JavaScript’s default number parsing may lose precision.
• Empty arrays may be null. Clients should accept additional response fields and handle chain reorganizations.
• Snapshots may be stale while refreshing or after an upstream failure. Check observation timestamps and indexer status. cache_max_age_sec, where present, is a refresh cadence, not a guaranteed maximum data age.
• There is no streaming endpoint, arbitrary analytics interface or write operation in this API contract.

Limits & usage

All account keys share one monthly allowance and the same short-term limits. The account allowances are:

These are account ceilings. Independent IP/firewall limits and shared server capacity may reject a request earlier. These numbers are not reserved throughput.

Short windows are fixed: 10-second windows, UTC minutes and UTC days. Traffic can cluster around a boundary; these are not rolling-window guarantees. Free monthly allowances reset on UTC calendar-month boundaries. Paid allowances use confirmed billing-cycle dates and require a successful renewal. Unused requests do not roll over; there are no automatic overage charges.

What consumes an allowance?

Every admitted request consumes one unit, including cache hits and later handler errors. Invalid credentials, invalid queries, quota denials and other pre-admission rejections do not count. An uncertain network result may consume a unit without returning data; a retry is a new admission. These counters measure admissions, not successful responses.

Signing in, rotating keys or changing a tier does not replenish an already-used period. Returning to Free resumes its existing calendar-month usage.

Response headers

Quota headers are sent on admitted responses. Concurrent requests may observe different remaining values; headers are not a replacement for the server’s shared account ledger.

Errors & retries

Admission errors have error, code and request_id fields. Handle HTTP status even when a firewall or proxy returns an empty or non-JSON body. Data-handler errors may use a simpler body.

Prefer incremental history reads and cache data in your application when appropriate. Avoid retry storms, particularly after a quota or capacity error.

Migration from v1

The anonymous /v1 API is deprecated. It continues returning its existing data during the notice period. Move integrations to the supported, authenticated /v2 API; create an account and key and start with the Free plan, or choose a paid allowance.

Endpoint migration map

This is not a universal prefix replacement. Use the documented parameters for each supported endpoint and restart pagination using its returned cursors.

Website search, chart/history interfaces, mempool, news/signals, event streaming and interactive profile/chat/swap operations are not part of the twelve-read developer contract. Their presence on the explorer does not make them supported developer API endpoints. Do not move integrations onto undocumented website routes.

Migration checklist

1. Create an account and API key. No plan purchase or billing change happens automatically.
2. Match each request against the map and OpenAPI contract. Add Authorization: Bearer <your-api-key> server-side.
3. Cache data where appropriate, respect account quotas, and use capped backoff for retryable failures. Keys share one account allowance.
4. Remove the legacy calls after verifying the authenticated responses. Report missing integration capabilities before the cutoff is announced.

During the notice period, legacy responses include Deprecation, a Link to this guide and X-PRLScan-Legacy-API: deprecated. API-generated errors also carry migration instructions: JSON error objects add a migration object with signup, documentation and OpenAPI links; plain-text errors append signup and guide URLs. Existing error fields, HTTP status and retry headers remain unchanged. Successful responses and streams are unchanged. A future retirement response will use HTTP 410 with machine-readable signup and documentation links. There is no automatic cutoff timer.

Public website data remains scrapeable; API credentials provide supported, accountable access and do not reserve server capacity.

Questions or a persistent error? Email hi@prlscan.com with the endpoint, HTTP status and request ID. Never send an API key.