Use cases
What you can build on Lumin
98 use cases across 19 verticals, each grounded in tools that actually exist on the server. Every tool name below is real and links to its reference page. Roughly a third of the surface is not orthodox KP (Parashari, Jaimini, Tajik, KP-extended), and presenting one of those as a KP finding is a methodology error that reads as thoroughness, so each vertical page labels it.
Start here: what you can ask the user for decides what you can build
This is the most useful fact on this page. Tools divide by input class, and the class decides the product shape, the consent burden, and the conversion friction.
| Input class | Tools | What it needs | Consent friction |
|---|---|---|---|
| Natal | 172 | Birth date, time and place | High. Birth data is among the most identifying tuples a product can hold, and a large share of users do not know their birth time. |
| Place and/or date only | 11 | A location and a date. No person at all | None. Cacheable per city per day, embeddable on a public page. |
| Horary | 7 | A number 1 to 249 and the moment of asking | None. Answers real life questions with no birth data. |
| Two-person | 9 | Two charts | High, doubled |
| Mundane | 2 | A country, company or location chart | None, no private individual |
| Reference | 3 | Nothing | None. Free discovery calls |
21 tools need nothing personal at all
These are your no-signup demo, your public widget, and your SEO surface. Cacheable per city per day, embeddable on a page with no form at all.
Two corrections
Both verified against the engine. Assuming either from the family name alone will misroute a product decision.
- The electional family is not place-only. 14 of its 15 tools take the native's birth data, because KP election consults the running dasha lord of that person's chart. Only get_election_catalog is person-free.
- The horary family takes birth-data-shaped field names but no birth.
birth_datetime,latitudeandlongitudecarry the moment and place of judgment, not a birth.
The seven verticals
Every one of the 98 use cases in the catalog appears on exactly one of these pages, mapped from the source catalog's 19 lettered sections.
| Page | Catalog sections | Use cases | Covers |
|---|---|---|---|
| Matrimonial and dating | A | 8 | Match scores, dosha filters, wedding dates both families accept. |
| Commerce and personalization | B, O | 12 | Onboarding profiles, gift finders, send-time optimisation, a personalization API. |
| Wellness and health | C, D | 13 | Prakriti quizzes, constitutional risk profiles, recovery windows, triage. |
| Career and education | E, F | 12 | Vocational fit, promotion prep, exam windows, study-abroad counselling. |
| Scheduling and electional | J, P, Q | 12 | Venue dates, meeting and filing slots, panchang widgets, regional almanacs. |
| Place-based and operations | I, K | 9 | Departure timing, sowing and harvest windows, fleet overlays, zero PII. |
| Research and data | G, H, L, M, N, R, S | 32 | Fintech, real estate, sports, legal, media, research and consumer apps. |
Before you ship any of these
Read responsible use first. It is the compliance page: disclaimer requirements by vertical, the three advisor-only tools that must never reach a consumer, and why birth data is PII.
Read pagination.totalItems and pageNote on paged tools, and increment
page until you have what you need. A page is a unit of thinking, not a
payload optimisation.
Calls are topped up in any amount, starting at 1 USD for 400 calls.
A quick lookup is a handful of calls and a full reading is 25 to 40,
so more calls means more readings and deeper ones. The eight run_*
composites chain several engine calls into one, which covers the same
ground for fewer calls when your UI does not need the intermediate
results.Where to next
- Examples for nine working apps, four of them built against this exact catalog.
- Reading depth and call floors for what a real tool chain costs.
- All tools for the full reference.