Skip to main content

​
Why this matters

The DexPaprika REST API sits behind Cloudflare with caching enabled. The behavior is generally invisible if you are a server-side consumer making fresh requests, but a few headers change what your client should do when the origin is briefly unavailable, and the CORS story is incomplete enough to bite browser-side code. This page documents the headers you will see today.

​
Cache-Control

Every successful GET returns a Cache-Control header that looks like this:
Breaking down what each directive means for your client: The practical effect of stale-if-error=600 is that a brief origin outage does not break your client. If the API is unreachable, your CDN (or a properly configured HTTP cache library) returns the last-good response with Age: <some_number> indicating staleness. The data is not real-time during the outage, but your application keeps working. For agents and SDK consumers: most HTTP client libraries do not honor stale-if-error by default. If your application needs the resilience this directive promises, use a cache layer that implements it (e.g., a CDN in front of your service, or libraries like cachecontrol for Python, node-cache-control for Node.js). For LLM tool calls: the MCP layer does not currently cache between calls, so stale-if-error does not protect MCP-driven flows. The underlying REST cache still helps because Cloudflare serves the stale copy upstream of the MCP.

​
Cf-Cache-Status

A Cloudflare-specific header that tells you whether your request hit the CDN cache:
This is informational. You do not need to act on it. It is useful when debugging stale data: if you see HIT and the data looks old, the cache is doing its job and the response is up to max-age seconds out of date.

​
Age, Last-Modified

Age is the number of seconds since the cached response was generated. Last-Modified is the absolute timestamp of the underlying resource (when the API determined the snapshot).
If you need to tell your user how fresh the price data is, Age is the most direct signal: the data is at most Age + max-age seconds old.

​
CORS

The DexPaprika REST API currently has limited CORS support. Server-side code works without any special handling. Browser-side code that calls the API directly will fail the preflight check. What the API returns today:
What is missing for browser fetches to work:
  • Access-Control-Allow-Origin
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Headers
Without these, browsers reject the response even though the network call succeeds. This is a known limitation. Work-arounds while it is being addressed:
  1. Server-side proxy. Run a small worker (Cloudflare Workers, Vercel Edge, Deno Deploy) that fetches from api.dexpaprika.com and re-serves with the right CORS headers to your frontend.
  2. DexPaprika MCP. Connect through mcp.dexpaprika.com from an agent runtime that handles the CORS layer for you.
  3. Static export. If your data refreshes infrequently, fetch at build time and serve as static JSON.
For real-time browser dashboards, options 1 and 2 are the practical paths.

​
X-Api-Plan

Every response carries the plan the request was evaluated against:
A keyless request returns anonymous. A request authenticated with a key returns that key’s plan: free_registered for a free API key, pro for a Pro subscription, unlimited for partner keys. The same value is returned in the body of GET /usage, alongside credit counts when the request is authenticated on api-pro.dexpaprika.com. Use it to confirm a key is actually being applied: if you set an Authorization header and still see anonymous, the key is not reaching the billing gate.

​
h-hap

You will see this header on every response:
It is an internal infrastructure marker. You can ignore it. Future versions of the API may remove it without notice.

​
Headers not present (today)

Some headers you might expect from a mature API are not currently emitted:
  • Deprecation (RFC 9745) and Sunset (RFC 8594): not set. When DexPaprika deprecates an endpoint or field in the future, these will appear with the relevant dates. Until then, deprecation status is documented in the API reference and in the changelog, not in headers.
  • RateLimit-* (draft-ietf-httpapi-ratelimit-headers): not set. X-Api-Plan is the only billing-related header today. For counts, call GET /usage. See Rate limits for the allowances.
  • ETag / If-None-Match: not set. Use Last-Modified if you need to track resource freshness.

​
Quick reference

All response headers are lowercase per HTTP/2 convention. If you parse them from a library that returns header names verbatim, accept both Cache-Control and cache-control. Some intermediaries normalize, others do not. For error responses (4xx, 5xx), most cache-related headers are absent and cf-cache-status: DYNAMIC is set. The error envelopes themselves are documented in Error handling.