Ayurvedic Constitution From a Birth Chart: Dosha API

Search for a dosha and the web offers a quiz. Twenty questions about frame, appetite and sleep, and a vata, pitta or kapha label at the end. The RoxyAPI Ayurveda API does not serve that. It computes an Ayurvedic constitution from a birth chart instead: the same date, time and place a natal chart already takes, read through the three factors the classical Jyotish texts actually state a rule for, with the work, the chapter and the verse returned beside every one of them. That is a narrower claim than a quiz makes, and a checkable one. It is also reproducible, which a quiz is not. The same birth data returns the same reading in five years. A questionnaire returns a different answer on a different afternoon.

Can a birth chart show a dosha, and which verses say so?

Three classical rules make it possible, and this API scores exactly those three. The Brihat Jataka assigns a humour to each rising sign in an extract credited to Satyacharya, states in verse 20 that a sign occupied by the Moon carries the effects of the same sign rising, and the Saravali states that the strongest planet imparts its own humour to the native. Each factor comes back with its citation attached.

A shorter cited list beats a longer invented one. The percentages that blend the three are the part with no verse behind them, so composite.convention names the blend and composite.weighting publishes the exact numbers it used, inside the same payload.

Ready to build this? The Ayurveda API returns the constitution, the day and the season on one key, with a citation on every value. See pricing.

How to read an Ayurvedic constitution from birth data

Two calls. Resolve the birthplace to coordinates and an IANA timezone first, then post the birth moment. Never make a user type a latitude. GET /location/search returns everything the chart endpoint needs, on the same key.

curl "https://roxyapi.com/api/v2/location/search?q=Lisbon&limit=1" \
  -H "X-API-Key: $ROXY_API_KEY"
# => { "total": 160, "limit": 1, "offset": 0,
#      "cities": [ { "city": "Lisbon", "province": "Lisbon", "country": "Portugal",
#                    "iso2": "PT", "latitude": 38.7251, "longitude": -9.1498,
#                    "timezone": "Europe/Lisbon", "utcOffset": 1, "population": 517802 } ] }

Then POST /ayurveda/constitution (calculateAyurvedicConstitution), which requires date, time, latitude and longitude, and accepts timezone, ayanamsa and signDoshaScheme.

curl -X POST "https://roxyapi.com/api/v2/ayurveda/constitution" \
  -H "X-API-Key: $ROXY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"date":"1988-11-12","time":"07:45:00","latitude":38.7251,"longitude":-9.1498,"timezone":"Europe/Lisbon"}'

The response below is a real capture from that call, trimmed to one factor and the top two of seven strength rows. Nothing in it is edited.

{
  "frame": { "ayanamsa": "lahiri", "ayanamsaDegrees": 23.702712125305183 },
  "lagnaSign": "scorpio",
  "moonSign": "scorpio",
  "factors": [
    { "id": "lagna-sign", "input": "scorpio", "doshas": ["pitta"], "weight": 2,
      "source": { "text": "Brihat Jataka", "chapter": "18",
                  "verse": "note to 20, the Satyacharya extract",
                  "translation": "N. Chidambaram Iyer", "year": 1885, "publicDomain": true } }
  ],
  "composite": { "vata": 27, "pitta": 67, "kapha": 6, "dominant": "pitta",
                 "secondary": "vata", "type": "pitta", "convention": "roxyapi/v1",
                 "weighting": { "lagnaSign": 2, "moonSign": 1, "strongestPlanet": 2,
                                "strongPlanetThreshold": 0.9, "dualTypeMargin": 10 } },
  "strengthRanking": [
    { "graha": "Mercury", "totalVirupas": 527.41, "rank": 1, "strong": true },
    { "graha": "Saturn",  "totalVirupas": 497.84, "rank": 2, "strong": true }
  ],
  "conventions": { "signDoshaScheme": "satyacharya", "ayanamsa": "lahiri" }
}

strengthRanking[].strong marks every graha within strongPlanetThreshold of the leader, which is why factors[2].input came back as Mercury Saturn rather than one name. That is the classical allowance for a blended reading, not a rounding artifact.

timezone takes either an IANA name such as Europe/Lisbon or decimal hours from UTC such as 5.5, and the IANA form is the safer one for a historical birth because it resolves the offset that was actually in force on that date. time is HH:MM:SS, not HH:MM. The rising sign turns roughly every two hours and carries the heaviest weight of the three factors, so the birth time is the input the whole reading is most sensitive to.

For an agent rather than a backend, the same endpoints are Remote MCP tools over Streamable HTTP, with no local setup:

claude mcp add-json --scope user roxy-ayurveda '{"type":"http","url":"https://roxyapi.com/mcp/ayurveda","headers":{"X-API-Key":"YOUR_KEY"}}'

Why the same chart returns pitta under one convention and kapha under another

Because two classical sign tables exist and they do not agree. The Satyacharya extract and the Parasara recension share a humour on only three signs of twelve, and on Scorpio and Sagittarius they share none at all. The chart above has Scorpio rising with the Moon in Scorpio, so it sits on the worst of those disagreements, and a single request field decides the answer.

curl -X POST "https://roxyapi.com/api/v2/ayurveda/constitution" \
  -H "X-API-Key: $ROXY_API_KEY" -H "Content-Type: application/json" \
  -d '{"date":"1988-11-12","time":"07:45:00","latitude":38.7251,"longitude":-9.1498,"timezone":"Europe/Lisbon","signDoshaScheme":"bphs"}'

Why brahma muhurta from a real sunrise beats a fixed timetable

Because a fixed grid of six four-hour blocks is only correct at an equinox near the equator. POST /ayurveda/dinacharya (getDinacharyaSchedule) takes a date, a latitude and a longitude, cuts the actual day and the actual night into thirds, and returns the modern clock grid beside it in alternatePeriods so a product can show one and reconcile against the other without a second call.

curl -X POST "https://roxyapi.com/api/v2/ayurveda/dinacharya" \
  -H "X-API-Key: $ROXY_API_KEY" -H "Content-Type: application/json" \
  -d '{"date":"2026-06-21","latitude":38.7251,"longitude":-9.1498,"timezone":"Europe/Lisbon"}'
# => sunrise "2026-06-21T05:12:02.221Z", sunset "2026-06-21T20:04:48.049Z"
#    brahmaMuhurta { start "2026-06-21T03:36:02.221Z", end "2026-06-21T04:24:02.221Z",
#                    muhurtaMinutes 48, muhurtasPerAhoratra 30 }
#    doshaPeriods[1]     { dosha "pitta", start "2026-06-21T10:09:37.497Z", span "day", third 2 }
#    alternatePeriods[2] { dosha "pitta", start "2026-06-21T09:00:00.000Z", span "day" }

Brahma muhurta is a fixed window, sunrise minus 96 minutes to sunrise minus 48, at every latitude and in every season, and muhurtaMinutes and muhurtasPerAhoratra come back so the arithmetic can be checked in the payload. A reference that scales it to a fifteenth of the night is following a reading the classical commentary rejects outright, and 96 is the definition rather than the hour and a half that circulates as a rounding of it.

Which Ayurvedic season a date falls in, and why two calculators disagree

Almost always because of the zodiac the boundaries were measured in. POST /ayurveda/ritucharya (getRitucharya) takes a date and nothing else, resolves the ritu from real solar ingress instants, and returns the exact opening and closing times. The tropical reading is what published almanacs use for seasons and is the default. The sidereal reading runs later, so near a boundary the two name different seasons for one date.

curl -X POST "https://roxyapi.com/api/v2/ayurveda/ritucharya" \
  -H "X-API-Key: $ROXY_API_KEY" -H "Content-Type: application/json" \
  -d '{"date":"2026-03-01","rituZodiac":"nirayana"}'

The same vasanta boundary sits at 2026-02-18T15:51:27Z tropically and at 2026-03-14T19:32:43Z sidereally, a gap of 24.15 days. That is a convention, not a defect, and conventions.rituZodiac comes back on every response so a UI can show which reading produced the season name.

ritu.start and ritu.end are the real ingress instants rather than the first of a month, so a seasonal feature turns over at the same moment an almanac does. A date is read at midday UTC, so on a day that carries a boundary the half midday falls in is the answer, and sending the neighbouring date shows the other side of it.

What the Ayurveda API deliberately does not do

It asks nothing about a body. There is no questionnaire that infers a constitution from answers, no balancing route, no field that names a substance, and no input anywhere for a complaint. None of that exists in the specification and none of it sits behind a flag. The boundary is published in full on the coverage page.

Every response in this domain also carries meta.disclaimer, in the language the request asked for, because a payload gets stored, cached, passed to a model and rendered where your own copy does not reach:

{
  "meta": {
    "disclaimer": "For general wellness and cultural interest only. This is not medical advice, and it is unrelated to the diagnosis, cure, mitigation, prevention or treatment of any disease or condition. Consult a qualified professional."
  }
}

Add ?lang=pt and the same field comes back as Apenas para bem-estar geral e interesse cultural..., while ritu.id stays vasanta and conventions stays canonical English. This domain answers in English plus seven more languages. Branch on the identifiers, render the prose, and render the disclaimer wherever you render the reading.

FAQ

Can a birth chart show your dosha?

The classical Jyotish texts assign a humour to each graha and to each rising sign, give a rule letting the rising sign table be read across to the sign the Moon occupies, and state that the strongest planet imparts its humour to the native. The RoxyAPI Ayurveda API scores exactly those three factors and returns the chapter and verse behind each one. What no primary text states is how to weigh the three against each other, so the blend that produces the percentage split is labelled a RoxyAPI convention, versioned, and published with its own weights inside every response.

How do I get an Ayurvedic constitution from an API?

Resolve the birthplace with GET /location/search, then post the date, time, latitude and longitude to POST /ayurveda/constitution with an X-API-Key header and Content-Type: application/json. The response returns lagnaSign, moonSign, three cited factors, the composite vata, pitta and kapha shares, the full shadbala strengthRanking, and the conventions the reading was computed under. One RoxyAPI key covers it along with Western astrology, Vedic astrology, forecast, human design and the rest of 18+ insight domains.

Is there a dosha quiz endpoint?

No, and there is not one behind a flag either. The consumer search for a dosha quiz is a questionnaire product, and RoxyAPI deliberately serves the computed half of this domain instead: a constitution from birth data, a day from a real sunrise, a season from a real ingress, and a catalogue with a source on every row. That boundary is what keeps a reading reproducible and keeps the input identical to the birth data an astrology feature already holds.

When is brahma muhurta today?

It opens 96 minutes before sunrise and closes 48 minutes before it, so it moves with the date and the place. Send a date, a latitude and a longitude to POST /ayurveda/dinacharya and RoxyAPI returns both instants along with sunrise, sunset, the six dosha periods and the modern clock grid beside them. The window is a fixed offset rather than a share of the night, which is the reading the classical commentary settles on.

Why do two Ayurvedic season calculators give different answers?

Usually because one measures the boundaries in the tropical zodiac and the other in the sidereal one, and the two readings of a single boundary sit about 24 days apart. RoxyAPI takes that as a typed input, rituZodiac, defaults to the tropical reading published almanacs use, and echoes the choice in conventions on every response. The second candidate is ritucharyaScheme, where the alternate six season division moves five of the six boundaries.

Is the RoxyAPI Ayurveda API medical advice?

No. Every response carries meta.disclaimer in the requested language, stating that it is for general wellness and cultural interest only and is not medical advice. No route accepts a complaint, no field names a substance, and no endpoint returns a recommendation of one. Anyone with a question about their own body should speak to a qualified professional.

Conclusion

An Ayurvedic constitution from a birth chart is a smaller claim than a quiz makes and a far more defensible one, because every factor carries a verse and every convention comes back in the payload. Build it with the Ayurveda API, on the same key, the same typed SDKs for TypeScript, Python, PHP, C# and Go, and the same Remote MCP server your agent connects to over Streamable HTTP with no local setup.