Developer reference · v1
Riftbound API documentation.
Read-only JSON access to stored USD prices, sets and variant history. Data requests read RiftStorm’s database; they never trigger a fresh upstream collection.
1. Create a server-side key
Sign in to the developer dashboard, create a key and save it when shown. Only a SHA-256 hash is stored. Send keys in the Authorization header; keep them out of URLs and public app bundles.
curl 'https://riftstorm.gg/api/v1/prices?limit=20' \
-H 'Authorization: Bearer YOUR_RIFTSTORM_API_KEY'2. Pick an endpoint
| GET endpoint | Parameters and response |
|---|---|
| /api/v1/prices | Optional ids (comma-separated card IDs), set (set ID), limit, offset. Returns prices and variant fields. |
| /api/v1/history | Required variant_id; optional days (1–90, default 30), limit, offset. Returns available historical observations. |
| /api/v1/sets | No parameters. Returns up to 100 set records: ID, name, code and release date. |
Price/history pages default to 50 rows on paid plans and 20 on Sandbox. Maximums are 100 and 20 respectively. Follow data.pagination.next_offset until null. IDs are opaque; preserve exact values from responses and don’t assume a card name identifies a printing. Offset is limited to 100,000.
3. Read prices without losing meaning
{
"data": {
"prices": [{
"card_id": "example-card",
"variant_id": "example-normal-nm",
"name": "Example card",
"market_price": "12.34",
"low_price": null,
"currency": "USD",
"source": "source-identifier",
"observed_at": "2026-10-18T12:00:00Z"
}],
"pagination": { "limit": 20, "offset": 0, "next_offset": null }
},
"meta": {
"request_id": "example-request-id",
"remaining": 499,
"reset_at": "2026-11-01T00:00:00.000Z"
}
}Illustrative values. Price amounts are decimal strings, never binary floats. Null means unavailable; do not replace it with zero. USD is the source currency. The sync runs on a six-hour schedule; observed_at records the stored observation time, not a promise of a recent market trade. The price source is preserved in the response.
Quotas, retries and errors
A successful data call costs one request, even when it returns no records. All keys for your account share monthly, daily and minute limits. Invalid requests, authentication failures, rejected quotas and server errors are not billed. Authenticated attempts, including errors, still count toward the minute rate limit. Quotas use calendar UTC boundaries, independently of your subscription renewal date. Rotating keys doesn’t reset usage.
400: fix the parameters.401: supply a valid active key from a verified, active account.429: wait the seconds inRetry-After. Monthly limits require a reset or a plan upgrade; no overage charges apply.503: access is not enabled, billing/data configuration is incomplete, or the service is temporarily unavailable. Retry with exponential backoff and jitter.
Successful responses include X-Request-Id, X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset. Limit and remaining refer to monthly requests; reset is ISO 8601 UTC. Responses are private/no-store, capped at 100 KB, and are intended for server-to-server use. No cross-origin browser access is enabled. Cache data in your backend according to your permitted use; respect source timestamps.
Operational expectations
No guaranteed uptime SLA during launch. Not every card or variant has a price or 90 days of history. These endpoints provide observations, not executable quotes, graded valuations or sales-volume estimates. Use request IDs when reporting issues.
Download OpenAPI schema →