Prashna Kundli API: Add Horary Questions to Your App

A user opens your app at 9:40 PM in New York with one worry: will this job offer come through? They don't know their birth time, and they don't want a full chart. Prashna kundli answers this kind of question. Prashna means "question," and the method is also called horary astrology. It is a chart cast for the moment and place a question is asked, then read for one topic. The person's birth date and time are not needed.

Our API has three routes for it. GET /v1/prashna/topics lists the 33 topics a person can pick, and the questions that are never answered. POST /v1/prashna takes a topic and the place, reads the moment, and puts a short answer first. That answer has a label, a headline, up to three reasons, what helps, what to watch, a timing estimate and a note. POST /v1/prashna/kp is the KP method, where the person also picks a number between 1 and 249.

Your app keeps three jobs. It shows a list of topics, never a free-text box. It handles refusals, which come back as a 422 error with the reason. And it keeps the 72-hour rule: one person, one topic, one answered question in 72 hours.

Every example below is a real answer from our docs, read for a fixed moment: Oct 1, 2026, at 12:00 PM in New York.

How to add prashna kundli to your app

Adding prashna kundli to an app takes five steps. Each step uses one route or one field of the API.

The three routes, side by side:

Only successful calls count toward your usage. So a refused question uses no reading credits. If you have not made a first call yet, the quickstart covers keys and headers.

What a prashna kundli reads

Most teams start with the wrong question: "Does the chart say yes or no?" A question chart doesn't answer that way, and every response says so in its not_claimed field. The better question is this: "How do the two planets of this question stand, and are they moving toward each other?"

The chart is cast for the moment of asking. The sign rising in the east at that moment is the lagna, or rising sign. Its ruling planet, the lagnesh, stands for the person asking. Each topic has its own house, or bhava: the 7th for marriage, the 10th for work. The planet that rules that house stands for the matter.

A birth chart reads a whole life, such as when marriage may come. A question chart reads one question at one moment, and it needs no birth time. So it also works for the users in our guide to unknown birth times.

The answer checks four things. First, how each of the two planets stands: its sign, its house, how close it is to the Sun. Second, the link: are the two planets moving toward an exact angle of 0, 60, 90, 120 or 180 degrees, or apart? The API measures this by degree, the Tajika way (PQ-18). Third, the Moon, which is strong when it is growing and outside the 6th, 8th and 12th houses. Fourth, the kind and harsh planets on the key houses.

Then the API picks one of four answers. It checks them in this order and stops at the first match (PQ-07):

Nothing is weighted or scored. Health and court questions are a contest instead. The person's planet is set against the ruler of the 6th house (the illness) or the 7th (the other side). Those answers are favorable, mixed or unfavorable.

Plan your screens for "Possible with effort." Our rulebook describes a test of hundreds of random moments. "Looks good" came up about 1 time in 100, and the astrologer who reviews our rules is checking the rule behind it (PQ-13). So most people will see one of the other three answers. Write those screens with the same care.

Step 1: a list of topics, never a text box

The API never reads a typed sentence. A person picks one of 33 topics. Any extra field, a free-text question included, gets a 422 error. Rule PQ-01 gives the reason. Deciding which house a sentence belongs to is a judgment, and a parser would make it where nobody can see.

The topics call gives the picker everything it needs: an id, a title in the reader's language, a kind and the houses. The first house is the house of the matter. Each topic also lists its karakas, the planets that stand for it by nature. Here is the marriage topic from the real answer, cut to its main fields:

{
  "id": "marriage",
  "kind": "question",
  "houses": [7],
  "karya_bhava": 7,
  "karakas": ["Venus", "Jupiter"],
  "title": "Marriage",
  "note": "Venus is the karaka of a spouse when a man asks and Jupiter when a woman asks. The request carries no sex, so both are judged and listed, and neither enters the verdict.",
  "kp": {
    "offered": true,
    "cusps": [7],
    "yes_houses": [2, 7, 11],
    "no_houses": [1, 6, 10]
  }
}

Some of the 33 topics, with the houses each one is read from:

A job offer and a career question share houses and a rule. Only the words change, so each reading talks about the question asked (PQ-23).

Group the list for people, not for astrologers. Show the title, never house numbers. Put work beside a job offer, and buying beside selling.

Step 2: send the topic, the place and, if needed, the time

A question needs a topic, a place and a moment. The place is latitude, longitude and timezone. This is the body from the docs' first example, a marriage question asked now in New York:

{
  "topic": "marriage",
  "latitude": 40.7128,
  "longitude": -74.006,
  "timezone": "America/New_York"
}

Leave out year, month, day, hour and minute, and the API reads the current moment at that place. If you send one, send at least the year, month, day and hour. The answer names the moment it used in asked_at. The docs' samples use a fixed moment, so they stay the same:

"asked_at": {
  "local": "2026-10-01T12:00:00",
  "utc": "2026-10-01T16:00:00Z",
  "utc_offset_hours": -4,
  "source": "given"
}

Send the place where the person is asking, not their birthplace. With a time zone name such as America/New_York, the API applies daylight saving time for that moment.

Leave the time out for a live question. Send a time only for a question asked earlier, such as one a client put to an astrologer on a call.

Step 3: show the answer first

Every answer opens with an answer block. Show it first and put everything else under details. Here is the docs' sample: the marriage question, Oct 1, 2026, at 12:00 PM in New York, cut to the answer's main parts:

{
  "verdict": "possible_with_effort",
  "label": {
    "id": "prashna:answer:label:possible_with_effort",
    "text": "Possible with effort"
  },
  "headline": {
    "id": "prashna:answer:headline:possible_with_effort",
    "text": "For your question about marriage, it is possible, but it will take effort."
  },
  "why": [
    {
      "text": "Your planet and the planet of the marriage are moving toward each other (Mars and Venus).",
      "reason": "lords_applying",
      "polarity": "helps"
    },
    {
      "text": "Your own planet (Mars) is weak right now: it is in its weakest sign.",
      "reason": "asker_lord_weak",
      "polarity": "strains"
    },
    {
      "text": "A harsh planet (Moon and Sun) gets in the way of the two planets.",
      "reason": "malefic_interference",
      "polarity": "strains"
    }
  ]
}

How the chart got there: Scorpio was rising, so Mars stands for the person. The 7th house was Taurus, so its ruler, Venus, stands for the marriage. Mars sat in Cancer, its weakest sign. Venus, in Libra, was 6.36 degrees from an exact square (90 degrees) with Mars and moving toward it. So the two were linked. The Moon and the Sun got in the way, and the first match in the list was "Possible with effort."

Keep the reasons in the API's order. The reasons that decided the answer come first, and the rest follow a fixed order (PQ-14). Each has a polarity of helps or strains, which suits an icon or a color. The titles object holds the headings in the reader's language, such as "Why: the main reasons" and "What to watch."

Every text has an id. Each block of text carries an id, and the part of the chart it explains carries the same id as its reading_id. So any line on screen can be traced to the chart behind it.

Two lengths, many languages. Add detail=expanded for text about 1.8 times longer. Add lang for another language; GET /v1/meta lists every language the API serves. A passage not yet written in that language comes back in English, marked fell_back_to_en. Our post on an astrology app in Hindi and other languages covers the rest.

Trisphuta is a second check, never the answer. Each question topic, except health and court cases, gets a trisphuta block. It adds the rising degree, the Moon and Gulika, a point read for hidden obstacles (see Gulika and Mandi). The sum leans harder or slower when it falls in a navamsa (a ninth part of a sign) ruled by a harsh planet. In the sample it did, in a navamsa ruled by Saturn, so differs_from_verdict is true. The check never changes the answer. Show it under details: rule PQ-49 says it leans this way in about two moments of three.

Timing: an estimate in days, weeks, months or years

For a question, timing comes from the link between the two planets. The API counts the degrees the faster planet still has to travel to the exact angle. One degree is one unit, and the unit comes from the faster planet's sign (PQ-11):

Your app needs no table of signs: the timing block names the modality and the unit. In the sample, Venus was the faster planet, in Libra, a movable sign, 6.36 degrees from the exact square. That rounds to 6, so the text reads: "It may take about 6 days. This is an estimate from the planets, not a date."

There is no estimate when the answer is "Highly unlikely." The same goes when the two planets are moving apart, have no aspect, or are the same planet. Then no_estimate_reason says which case it was.

Never turn the estimate into a calendar date. The API lists calendar dates under not_computed, so it never gives one. Show its own text, and do not add "by Oct 7." A countdown would turn an estimate into a promise.

Lost items, theft and missing people

Three kinds of question get extra fields, and need extra care on screen.

A lost item (lost-item) gets a lost_item block. It gives a direction and a kind of place, both read from the sign on the 4th house (PQ-30):

The kind of place comes from the type of sign. A movable sign suggests the thing has gone far or is outside. A fixed sign suggests it is inside, right where it fell. A dual sign suggests it is inside but moved a little, near doors, windows or edges. A separate found status, found, not_found or unclear, has its own rule (PQ-31). When it and the main answer disagree, found.differs_from_verdict is true, and you show both.

A theft (theft-recovery) asks one thing only: will I get it back? The reading never says who took it and never accuses anyone (PQ-26).

A missing person has seven topics, from missing-spouse to missing-employee. The question is whether the person comes back. The reading never says whether anyone is alive, and it always says to go to the police (PQ-25).

Keep these screens calm. Put the police line above the answer, not below it. Use no alert sounds and no red banners. A person asking about a missing family member is already under great stress.

Refusals and unfit moments: the 422 answers

Some requests get a 422 error and no reading. Plan for three kinds:

Refused topics. Eight topic ids are refused whatever the chart shows, and no chart is cast (PQ-15). They cover how long someone will live (lifespan), the sex of an unborn child (unborn-child-sex), and lottery, gambling and share-tips. The rest are a medical diagnosis, whether a named person committed a crime, and a question asked only as a test. This is our own policy, agreed with the astrologer who reviews our rules, not a classical rule.

Leave these ids out of your picker. They help on a chat screen: if your app turns a message into a topic, send the refused id. The API answers with the refusal in the user's language.

Unfit moments. A rising degree under 3 degrees into its sign means the matter is not ready to read. Over 27 degrees, it is already settled (PQ-16). A Moon or rising sign at a junction between a water sign and a fire sign is also not read (PQ-17). Then error.reasons lists every cause, and error.measured gives the degrees.

The same moment always gives the same refusal, so a retry button that resends it is useless. Say why in one line, and invite the person to ask again a little later. For retries in general, see our guide to errors and retries.

The 72-hour rule lives in your app

Every answered response carries repeat_rule, plus a text line you can show the user:

"repeat_rule": {
  "hours": 72,
  "applies_to": "same_person_and_topic",
  "starts_from": "last_answered_question",
  "refusals_count": false,
  "enforced_by": "caller"
}

The rule is short. One person asks about one topic once in 72 hours, counted from the last question that got an answer (PQ-50). It is a working rule from the astrologer who reviews our rules, not one from the old books.

The API cannot keep this rule for you. It keeps no record and takes no user id. So your app keeps the clock:

Log each answered question. Keep one row per person and topic, with the time of the last answered question. The answer's asked_at gives that moment.

Check before you call. If the topic got an answer less than 72 hours ago, show when the person can ask again, and skip the call. That also saves the 5 reading credits.

Count both methods as one. A KP answer and a main answer on the same topic count as one question (PQ-51). The astrologer has not ruled on this point yet, so the answer lists it under provisional.

Don't count refusals. A refused question does not start the clock. And the rule is per topic: asking about work today does not block a question about a lost item.

See all three routes in one place. The prashna API reference lists every input and field, with the real answers this post quotes.

KP horary: a number between 1 and 249

KP is short for Krishnamurti Paddhati, a school that reads a chart by very small slices of the sky (see KP astrology). Its horary method asks the person to pick a number up to 249, along with a topic. POST /v1/prashna/kp takes the same body as the main route, plus number.

The number sets the houses. Each number is one of 249 slices of the zodiac, and the first degree of that slice becomes the rising point. The other 11 houses follow from it and the latitude, and the moment only places the planets (PQ-34). The method uses Placidus houses and the KP ayanamsa, explained in our post on Lahiri, KP and Raman ayanamsa.

Two limits shape the KP screen. The route offers 8 topics, among them marriage, career, money and travel; any other gets a 422 with topic_not_offered. And a latitude beyond 66 degrees gets a 422 with placidus_undefined, because these houses do not work there.

The answer comes first again. promise.status is promised, mixed, denied or not_shown. It comes from the sub lord of the topic's house and the houses it links to. For marriage, houses 2, 7 and 11 say yes, and 1, 6 and 10 say no. A "confirmed" reading means the planets of the moment agree, not that the result is certain (PQ-39). Any date is an estimate.

Same moment, two answers. The docs' KP sample is number 123 and a marriage question, at the same moment as the main sample. Number 123 is a slice of Virgo, in the nakshatra (birth star) Chitra, with Jupiter as its sub lord. Here is the KP answer, cut to its main parts:

{
  "status": "denied",
  "label": {
    "id": "prashna:kp:label:denied",
    "text": "The chart does not support it"
  },
  "why": [
    {
      "text": "The sub lord of your seventh house, Jupiter, links through Mercury only to houses that say no: 1 and 10.",
      "reason": "no"
    }
  ],
  "timing": {
    "text": "No date is given, because the chart does not support this.",
    "status": "no_date",
    "no_date_reason": "promise_failed"
  }
}

The main route said "Possible with effort" for the same topic at the same minute. Neither answer is a mistake: the main route casts the chart for the moment, and the KP route lets the number set the houses.

Pick one method per screen. Never show the two verdicts side by side as one answer. If you offer both, name each, such as "Classical reading" and "KP number reading," and count them as one question.

Read the rules behind every answer. All 51 prashna rules are in the question chart section of our rulebook, each in plain words, with the points still waiting for review.

The API side of a prashna kundli feature is small: one call for the topics and one call per question. The real work is in the product. Give people a list, not a box. Show the answer and its reasons first, and the timing as an estimate. Keep the 72-hour clock in your own app, and let every refusal say why. A question chart reads the moment a question is asked. It never promises what comes next, and your screen shouldn't either.