Skip to main content
Use this when you need to score many wallets at once — for example, ranking a candidate-leader list. The endpoint returns one result per wallet, processed in parallel so 50 wallets don’t take 50× single-wallet time.

Request body

The from/to window applies to every wallet in the batch — pass per-wallet windows by making separate calls. ?period= preset is not supported in the batch body. Use explicit from/to.

Response

Per-result fields are identical to the single-wallet response.

Example: 3 wallets over a 10-day window

Request:
Response (200 OK, abridged):
Note the second wallet — no on-chain trading activity in the window — returns the standard zero-shape with slippage_cost_rate_pct: null (denominator unstable per the spec edge case). Wallets that error individually return {"wallet": "...", "error": "..."} instead of the full shape, so a single bad wallet won’t fail the whole batch.

Errors

400 Body must include "addresses": [...]:
400 Invalid wallet:
400 Too many addresses:
Auth errors (401, 403) and rate-limit errors (429) are identical to the single-wallet endpoint — see Backtest Copy PnL.

Limits and behavior

  • Max 100 addresses per call.
  • Typical batch latency — a 100-wallet batch with average ~1.5s per wallet completes in roughly 20s.
  • 45-second total timeout. Heavy batches (many high-volume wallets) may exceed — split the address list across multiple calls if so.
  • Same rate limit as the single endpoint: 1 request per 5 seconds per API key. The batch counts as one request regardless of how many wallets are inside.
  • Per-wallet errors don’t fail the batch. A wallet that errors during processing returns {"wallet": "...", "error": "..."} in its slot. Other wallets still return their full result.
  • Same partial: true behavior per wallet as the single endpoint — extreme high-frequency wallets may flag partial inside their result.