Feeding astrology data to an LLM: why structured beats prose

A lot of the developers signing up for AstroAsk lately are building the same thing: an LLM-powered astrology experience. A chatbot that reads your chart. An agent that answers "is tomorrow a good day to sign the lease?" A personalized daily reading generated on the fly. The model does the talking; the astrology API supplies the facts.

If that's you, here's the design decision that matters most, and it's about the shape of the API you pick, not the size of its catalog.

Two kinds of astrology API

Most astrology APIs were built for a world where the API's job was to produce the final text a human reads. So they return prose:

{
  "varna": {
    "points_obtained": 1,
    "description": "There shall be a complementing relationship between the couple. Rahul Kumar shall be dedicated towards providing for the family. Simran Kumari will also nurture the family with love and care."
  }
}

That's a real response (names changed by the vendor's own mail-merge). It's fine if you're displaying it verbatim. It's actively unhelpful if you're handing it to a model, for three reasons:

1. The model has to un-write it. To reason about compatibility, the LLM first has to extract "Varna: 1/1, both Kshatriya" back out of a paragraph of narrative. It'll mostly succeed — and occasionally hallucinate a detail the paragraph implied. You're paying tokens to reverse a formatting step.

2. It's the vendor's voice, not yours. "Rahul Kumar shall be dedicated" has a tone, a reading level, a cultural register, and a gender assumption baked in. If your product's voice is different — warmer, more clinical, in Tamil, for a Gen-Z audience — the model now has to fight the source text instead of just using it.

3. It doesn't compose. A good AI reading connects things: this koota is weak, but the Nadi is fine, and Venus is well-placed for both, so on balance… Prose blobs don't connect. Scores and flags do.

What structured data gives the model

Same koota from AstroAsk:

{
  "name": "varna",
  "score": 1,
  "maxScore": 1,
  "p1": "Kshatriya",
  "p2": "Kshatriya",
  "areaOfLife": "Spiritual & Ego"
}

Plus, at the top level, totalScore, rating, doshas[], and isCompatible. Now your system prompt can be:

You are a warm, plain-spoken relationship astrologer. Here is the Ashtakoot matching data as JSON. Explain the result to a first-time reader in three short paragraphs. Lead with the total. Mention any dosha explicitly. Do not invent facts not in the JSON.

The model has clean facts to reason over, your voice to speak in, and a hard boundary ("not in the JSON") that structured data makes enforceable and prose does not.

The pattern generalizes

Everywhere the API returns reasoning instead of a conclusion, the model gets better raw material:

• Manglik: references[] says which reference point triggered — so the model can say "from the Moon, not the ascendant" instead of a bare yes/no. (Why that matters →)
• Yogas: each has conditions[] and a strength grade — the model can rank them and explain the strong ones.
• Dashas: each period has lordStrength with dignity, house, and Shadbala — "your Saturn period starts in August; Saturn is strong in your chart, so expect…" is a sentence the model can actually justify.
• Planets: dignity, avastha, isVargottama, houseClassifications[] — the vocabulary an astrologer would use, as fields.

A practical recipe

1. Call the calculation endpoints you need — usually /v1/planets, /v1/dasha/current, and one or two verdict endpoints. Or bundle them in one POST /v1/batch.
2. Pass the JSON straight into the prompt as context. Don't pre-summarize it in code; let the model read the fields.
3. Constrain the model to the data ("only use facts present in the JSON").
4. Set the voice, language, and length in your prompt — that's your product's job, and the API stays out of the way.

Two things make this cheap: every AstroAsk endpoint costs exactly one request regardless of what it computes, and responses are typed and consistently named, so the same prompt works across endpoints without per-endpoint massaging.

What we deliberately don't do

We don't sell an "AI reading" endpoint. That would put us in the business of choosing your product's voice, and it would let anyone white-label the exact thing that should be your differentiator. We compute; you interpret. If you want to see structured astrology data driving an LLM in production, that's what our own consumer app at astroask.app does — on this same API.

Start with the quickstart, or paste /v1/compatibility/ashtakoot output into your model of choice and see how much less prompt engineering it takes.