The checklist at a glance
| # | Check | What a good answer looks like | Simple Numerology API |
|---|---|---|---|
| 1 | Conventions | Y, master numbers, middle names and accents documented | Documented, contested rules settable per request |
| 2 | Stability | Answers never change under a version you pinned | Version in the URL (/v1/), default output frozen |
| 3 | Determinism | Same input, same JSON, every time | No model, no randomness, cache forever |
| 4 | Privacy | Names and birthdates not stored or logged | Never stored, only sent in the request body |
| 5 | Honest types | Fields can hold 11, 22 and 33 | Master numbers kept, ties and arrays where they belong |
| 6 | Errors | A 4xx with a code and the bad parameter | One error shape with code, param and request_id |
| 7 | OpenAPI | A spec you can generate a client from | OpenAPI 3.1 and a Postman collection |
| 8 | Free tier | The real API, without a card | 100 charts a month, every endpoint |
| 9 | Real names | Accents and other scripts counted correctly | Accents folded, Cyrillic valued, computed_name returned |
| 10 | One call | A full profile in one request, plus batch | 47 fields per call, up to 100 charts per batch |
1. Are the conventions documented?
Ask the questions numerology sources disagree on:
- Is Y a vowel, a consonant, or does it depend on context?
- Do master numbers 11, 22 and 33 survive reduction?
- Are names summed whole, or reduced name by name first?
- Do middle names count toward the full-name numbers?
- How are accents handled? Is “María” read as “maria”, or is the í dropped?
If the documentation doesn’t answer these, your users’ complaints will. Here: every default is documented, and the contested ones (the Y rule, the reduction method and transliteration) can be set per request.
2. Will the numbers ever change?
Most apps store charts. If the provider changes a convention, stored charts silently disagree with new ones. Look for an explicit versioning policy and a way to pin a version. Here: the version is in the URL (/v1/), only a new URL can change an answer, and every response echoes the conventions that produced it.
3. Is it deterministic?
The same input should always produce the same output, with no model and no randomness. Only then can you cache a chart forever, which matters for both cost and latency. Test it: send the same request twice and compare the JSON.
4. What happens to the names you send?
Full names and dates of birth are personal data. Check whether the provider stores request bodies, logs them, or puts names in the URL, where they end up in access logs. Here: names and birthdates are never stored or logged, and they travel only in the request body.
5. Are the response types honest?
Ask whether a “number” field can hold 11, 22 or 33, whether hidden passion can be a tie, and whether karmic debts arrive as an array. An API that squeezes everything into one digit is losing information or hiding it. See master numbers and your integer column.
6. How does it fail?
Send an impossible date such as 1990-02-30. A good API returns a 4xx with a machine-readable code and the name of the bad parameter. Then exceed the quota: you want a clear status code and quota headers, not silent truncation or an HTML error page. Here: every error has the same shape (type, code, param, request_id), and running out of quota returns 402 with X-Quota-* headers.
7. Is there an OpenAPI spec?
An OpenAPI document lets you generate a typed client in any language, import the API into Postman, or point an AI coding assistant at it. Here: OpenAPI 3.1, a Postman collection, official SDKs and quickstarts for Python and JavaScript. See generating a client.
8. Can you try it properly for free?
A free tier should cover the real API, not a subset of fields, and shouldn’t need a card. Here: the free plan is 100 charts a month on every endpoint, with no card and no expiry.
9. Does it handle real names?
Your users are not all called John Smith. Send “María García López”, a hyphenated “Jean-Luc” and a name in another script, then look at which letters were counted. An API that silently drops the í, or every letter of a Cyrillic name, returns a confident chart computed from part of the name. Here: accents are folded (María counts as maria), Russian Cyrillic is valued natively, transliteration to Latin is one option away, and every chart returns computed_name, the letters it was computed from.
10. Is it one call or twenty?
Some APIs expose one endpoint per number: life path here, destiny there, soul urge somewhere else. A full profile then costs a dozen requests, a dozen chances to fail halfway and a dozen charges against your quota. Here: one request returns all 47 fields, from life path to planes of expression, and a batch call returns up to 100 charts, charged all or nothing.
A five-minute evaluation script
Run the same checks against every candidate:
# Determinism: two identical requests should produce identical JSON
for i in 1 2; do
curl -s -X POST "$API/v1/charts/pythagorean" -H "X-API-Key: $KEY" \
-H 'content-type: application/json' \
-d '{"first_name":"Lynn","last_name":"Kylie","birthdate":"1980-12-08"}' \
| shasum
done
# Life path for 1980-12-08 should be 2, not 11 (the straight-sum shortcut)
# "Lynn" tests the Y rule; an accented name such as "José" tests folding
Compare the answers with the life path method and the Y rule. A provider that gets 1980-12-08 wrong is using the shortcut, and most of its other numbers are probably built the same way.
Frequently asked questions
What is the best numerology API?
The one whose conventions match what your users expect, and that documents and freezes them. Run each candidate through the checklist above with the same test names and dates. If your audience expects Pythagorean numerology, Simple Numerology API passes all ten checks, and its free plan lets you verify that before you pay.
Why do two numerology APIs give different numbers for the same name?
They follow different conventions: whether Y is a vowel, whether master numbers are kept, whether names are reduced whole or one by one, how accents are read, or a different system altogether, such as Chaldean. Neither answer is necessarily wrong, which is why an API should say which rules it used.
How do I test a numerology API for free?
Sign up for its free tier and send the same few people to every candidate: a name with a Y (Lynn), an accented name (José), and a birthdate whose shortcut and correct life paths differ (1980-12-08). Simple Numerology API’s free plan includes 100 charts a month on every endpoint, with no card.
Does Simple Numerology API support Chaldean numerology?
No. It computes Pythagorean charts only, and every response says so in its system field. If your users expect Chaldean numbers, it is better to know before you integrate.
Start with 100 free charts a month
No card, no trial clock, no expiry date.
Related
A free numerology API
A free numerology API with 100 requests a month, every endpoint and no credit card. Paid plans start at $9 for…
The cheapest numerology API at volume
A low-cost numerology API. 10,000 requests for $9 a month or 500,000 for $49, under $0.10 per 1,000 charts, wi…
The simplest numerology REST JSON API
The simplest numerology REST API. One POST with a name and a birthdate returns a full numerology chart as JSON…
Pythagorean vs Chaldean numerology
Pythagorean vs Chaldean numerology side by side. Both letter charts, a worked name example, what each system c…