Audit an Astrology API: Count What It Actually Ships

Two astrology API providers sit in a browser tab each. One advertises three hundred endpoints. The other advertises ninety. There is no way to tell from those two pages which number describes running software and which describes an ambition, because a number on a pricing page costs nothing to type and nothing to defend.

There is a way to tell, and it takes about ninety seconds. A provider that publishes an OpenAPI specification has published a machine-readable inventory of everything it actually serves. That document can be counted, grouped, and checked for padding by anyone, without an account, without a sales call, and without trusting a word of the copy that sits next to it. This guide is the procedure, the commands, and the failure patterns worth looking for.

Why an endpoint count on a pricing page proves nothing

A marketing endpoint count is unfalsifiable by construction. Nobody outside the company can reproduce it, nobody can see what was counted as one endpoint versus three, and the number carries no penalty for being generous. A provider with a published spec is capped at the truth, because the document lists every route it serves. A provider without one can print any figure at all, and frequently prints several different ones on different pages of the same site.

The same asymmetry shows up in how the two numbers behave over time. A specification is generated from the running service, so it moves when the service moves. A figure typed into a hero section moves when somebody remembers to edit it, which is how one site ends up advertising three different totals at once without anyone noticing.

That gap punishes the honest party unless buyers actually run the check. It is also why the first question to ask a provider is not how many endpoints exist, but where the specification lives.

Ready to build on numbers you verified yourself? The Astrology API ships every domain on one key, and pricing is flat per request with no per-endpoint weighting.

How to count the endpoints in any OpenAPI spec

An OpenAPI document stores routes under a paths object, and every HTTP method under a path is one operation. Counting operations rather than paths is the honest unit, because one path serving both GET and POST is genuinely two things a developer can call. Three commands cover the whole job, and all three run against a public URL with no credentials attached.

1. Find the spec. Try /openapi.json, /swagger.json, and any link on the API reference page. If every candidate returns a 404, stop here: there is no inventory to audit, and every catalog number that provider publishes is unverifiable.
2. Count the operations.

curl -s https://roxyapi.com/api/v2/openapi.json \
  | jq '[.paths[] | keys[]] | length'

3. Group them by domain. Tags carry the domain grouping, so this is the per-domain depth table nobody has to take on faith:

curl -s https://roxyapi.com/api/v2/openapi.json \
  | jq -r '[.paths[][] | .tags[0]] | group_by(.)
    | map({tag: .[0], ops: length}) | sort_by(-.ops)[] | "\(.ops)  \(.tag)"'

Point the same two commands at any provider that publishes a spec. The output is directly comparable in a way that two marketing pages never are.

How to tell a real catalog from a padded one

Counting is only half the audit. A catalog can be inflated without a single false statement, by splitting one capability across several routes so the total climbs while the capability set stays flat. Nothing about that is dishonest on its face, which is why the count alone settles less than it appears to. Four patterns account for most of it, and each has a check that takes one command.

The first check is a one-liner. If the two figures differ, some operations are duplicates:

curl -s https://roxyapi.com/api/v2/openapi.json \
  | jq '[.paths[][].operationId] | {operations: length, unique_ids: (unique | length)}'

Fragmented results matter more than the raw count for anyone paying per request, because a catalog that needs six calls to assemble one birth chart bills six times for what a complete response delivers once. Read one full response early in the evaluation and the padding question usually answers itself.

What the count returns for RoxyAPI, domain by domain

Running the grouping command above against the live spec returns the table below. These are published as floors rather than exact integers on purpose, because a blog post is frozen text and the catalog only grows, so a floor stays true while a precise figure starts rotting the day a route ships. The exact live integer is on the transparency page, and the command in the previous section returns whatever is true today.

The padding check returns an equal operation count and unique operation ID count, which is the machine-readable way of saying that no route in the catalog is a second door onto a room that already exists. Every path carries exactly one operation, so the total is a count of distinct capabilities rather than a count of ways to reach the same handler. That is the property worth comparing across providers, and it is the one a marketing figure can never demonstrate.

How to call an endpoint you just counted

An inventory is worth nothing until one of its rows returns real data, so the last step of the audit is a live call. Every chart endpoint needs coordinates and a timezone, so resolve the birth place first rather than asking a user to type latitude and longitude. The location lookup returns both, and its latitude, longitude, and timezone fields feed straight into the chart request.

curl -s "https://roxyapi.com/api/v2/location/search?q=berlin&limit=1" \
  -H "X-API-Key: YOUR_KEY"

curl -s -X POST https://roxyapi.com/api/v2/astrology/natal-chart \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"date":"1990-07-15","time":"14:30:00","latitude":52.5244,"longitude":13.4105,"timezone":"Europe/Berlin"}'

const headers = { 'X-API-Key': process.env.ROXYAPI_KEY! };

const places = await fetch(
  'https://roxyapi.com/api/v2/location/search?q=berlin&limit=1',
  { headers },
).then((r) => r.json());

const { latitude, longitude, timezone } = places.cities[0];

const chart = await fetch('https://roxyapi.com/api/v2/astrology/natal-chart', {
  method: 'POST',
  headers: { ...headers, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    date: '1990-07-15',
    time: '14:30:00',
    latitude,
    longitude,
    timezone,
  }),
}).then((r) => r.json());

import os, requests

headers = {"X-API-Key": os.environ["ROXYAPI_KEY"]}

places = requests.get(
    "https://roxyapi.com/api/v2/location/search",
    params={"q": "berlin", "limit": 1},
    headers=headers,
).json()

city = places["cities"][0]

chart = requests.post(
    "https://roxyapi.com/api/v2/astrology/natal-chart",
    headers={**headers, "Content-Type": "application/json"},
    json={
        "date": "1990-07-15",
        "time": "14:30:00",
        "latitude": city["latitude"],
        "longitude": city["longitude"],
        "timezone": city["timezone"],
    },
).json()

The chart response opens with the angles, captured live from production:

{
  "ascendant": { "longitude": 210.51743045285548, "sign": "Scorpio", "degree": 0.5174304528554785 },
  "midheaven": { "longitude": 131.55265619093097, "sign": "Leo", "degree": 11.552656190930975 }
}

The full body is about 30 KB and carries planets, houses, aspects, patterns, part of fortune, vertex, and per-placement interpretation text in one call. Run it in the browser from POST /astrology/natal-chart, which returns real production responses with no signup and no key required.

FAQ

How do I check how many endpoints an API really has?

Fetch the OpenAPI spec and count the operations under the paths object rather than trusting the number printed on the pricing page. For RoxyAPI that is curl -s https://roxyapi.com/api/v2/openapi.json | jq '[.paths[] | keys[]] | length', which needs no account and no API key. Point the same command at any provider that publishes a spec.

What does it mean if an astrology API has no OpenAPI spec?

It means the catalog size cannot be independently verified, and neither can the request or response shape of any endpoint before you integrate. It also means no typed SDK can be generated from it, so any client library is hand-written and free to drift from the running service. Treat a missing spec as a missing measurement rather than as a small documentation gap.

Does a bigger endpoint count mean a better astrology API?

Not on its own. A catalog can be inflated by exposing one capability at several paths, by splitting the same result into JSON, PDF, and image routes, or by fragmenting one chart across many separately billed calls. Compare operation counts against unique operation IDs to detect duplicates, and read one complete response to see how much a single call returns.

Can I count RoxyAPI endpoints without an API key?

Yes. The combined specification at /api/v2/openapi.json is public and needs no authentication, and the interactive reference runs real production requests in the browser with no signup. A key is only needed once a call consumes quota from your own subscription.

How many domains does RoxyAPI cover on one API key?

Twelve, spanning 171+ endpoints: Western astrology, Vedic astrology, numerology, tarot, human design, forecast, biorhythm, I-Ching, crystals, dreams, angel numbers, and location. Every domain is included in every plan under one subscription and one key, with flat per-request billing and no per-endpoint weighting.

Conclusion

An astrology API endpoint count is either something you read or something you measured, and the difference decides how much the comparison is worth. Fetching the spec, grouping by domain, and checking for duplicate operation IDs turns a shortlist of marketing pages into a shortlist of measurements in about ninety seconds.

Run the three commands on every provider under consideration, then build on the one whose numbers survived. The Astrology API publishes its full inventory at a public URL for exactly that reason.