Caching to cut your API bill

Every call you do not repeat is a call you do not pay for. Deterministic calculations are safe to cache forever. This guide shows what to cache, what not to, and how to key it.

A common worry when you scale a spiritual app is that the API bill grows linearly with daily active users: more users, more horoscopes, more charts, more calls. It does not have to. Most of what RoxyAPI returns is deterministic, meaning the same input always produces the same output, so you only ever need to compute it once. Cache those results in your own store and your bill flattens while your traffic keeps climbing.

Two facts shape the strategy:

• Only successful responses count. A 2xx response is one billable call; 4xx and 5xx are not billed.
• Data responses are not edge-cacheable. RoxyAPI sends private, no-store on /api/v2/* responses so a CDN will not transparently cache them. The cache that saves you money is the one you run, keyed by the request inputs.

What is safe to cache forever

A result is permanently cacheable when nothing in the answer depends on the current date or time. Same inputs, same answer, for years. Cache these in your own Redis, database, or KV with no expiry and key them by the request body or path parameters.

Because the inputs are immutable, a cache hit here is correctness-neutral: you are returning the exact bytes the API would have returned.

What to cache briefly or not at all

Time-sensitive endpoints change with the clock. Cache them with a short TTL that matches their natural cadence, keyed by the date, or skip the cache entirely for live data.

How to key a cache entry

The rule is simple: the cache key must contain every input that changes the output, and nothing that does not. For coordinate-dependent endpoints, that is the resolved birth data plus any options like house system or ayanamsa. Resolve the location once (see the location lookup) and store the resolved coordinates so the same city does not re-geocode on every request.

import { createHash } from "node:crypto";

function chartKey(input: Record<string, unknown>) {
  const json = JSON.stringify(input, Object.keys(input).sort());
  return "chart:" + createHash("sha256").update(json).digest("hex");
}

async function getChart(input: ChartInput) {
  const key = chartKey(input);
  const hit = await redis.get(key);
  if (hit) return JSON.parse(hit); // no billable call

  const res = await roxy.astrology.natalChart(input);
  await redis.set(key, JSON.stringify(res)); // immutable, no expiry
  return res;
}

import hashlib, json

def chart_key(payload: dict) -> str:
    blob = json.dumps(payload, sort_keys=True)
    return "chart:" + hashlib.sha256(blob.encode()).hexdigest()

def get_chart(payload: dict):
    key = chart_key(payload)
    hit = r.get(key)
    if hit:
        return json.loads(hit)  # no billable call
    res = roxy.astrology.natal_chart(**payload)
    r.set(key, json.dumps(res))  # immutable, no expiry
    return res

How much does this save?

For a horoscope feature, the savings are dramatic because reads cluster. Twelve signs times one daily compute is twelve calls per day, no matter whether ten users or ten thousand read them.

FAQ

Does RoxyAPI cache responses for me?

Data API responses are sent as private and no-store, so a CDN will not cache them transparently. Run your own application cache keyed by the request inputs to avoid repeat billable calls.

Do cached calls still count toward my quota?

Only calls that actually reach the API count, and only successful 2xx responses are billed. A hit in your own cache makes no request, so it costs nothing against your quota.

Which RoxyAPI results are safe to cache forever?

Anything computed from immutable inputs: natal charts, numerology from a name and birth date, kundli and dasha, and panchang for a fixed date. Their output never changes, so an unbounded cache is correctness-neutral.

How should I cache a daily horoscope?

Cache it with the date and sign in the key and expire it at the end of the day. That computes each sign once per day and serves every reader from cache.

Next steps

Pair caching with the right plan for your volume on the pricing page, and see structured outputs for how owning your interpretation layer reduces calls further.