:::note
**TL;DR**
- The Ayurvedic constitution here is read from a verified sidereal birth chart, never inferred from a questionnaire, and every factor comes back with the work, chapter and verse behind it.
- Three factors are scored, because three carry a classical rule: the rising sign, the sign the Moon occupies, and the strongest graha by shadbala.
- Flip one documented convention and the same birth data returns pitta 67 or kapha 67, which is why every response echoes the conventions it was computed under.
- Ship it with the [Ayurveda API](/products/ayurveda-api "production ready Ayurveda API for dosha constitution, dinacharya and ritucharya") in about 30 minutes, on the same key as every other RoxyAPI domain.
:::

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.

:::stat 3
**Three cited factors, not five.** The lagna lord and the Sun carry no classical rule that they indicate the humour of the native, so neither is scored. Verification method: [methodology](/methodology "RoxyAPI accuracy methodology and source verification register").
:::

| Factor `id` | What it reads | `weight` | Source returned in the response |
|---|---|---:|---|
| `lagna-sign` | the rising sign | 2 | Brihat Jataka, chapter 18, note to 20, the Satyacharya extract, N. Chidambaram Iyer 1885, public domain |
| `moon-sign` | the sign the Moon occupies | 1 | Brihat Jataka, chapter 18, verse 20, N. Chidambaram Iyer 1885, public domain |
| `strongest-planet` | the strongest graha by shadbala | 2 | Saravali, chapter 38, verse 5, R. Santhanam 1983, referenced only, not public domain |

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](/products/ayurveda-api "Ayurveda API with dosha constitution, dinacharya and ritucharya endpoints") returns the constitution, the day and the season on one key, with a citation on every value. [See pricing](/pricing "RoxyAPI pricing tiers and request quotas").

## 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.

```bash
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`](/api-reference#tag/ayurveda/POST/ayurveda/constitution "Ayurvedic constitution endpoint request and response schema") (`calculateAyurvedicConstitution`), which requires `date`, `time`, `latitude` and `longitude`, and accepts `timezone`, `ayanamsa` and `signDoshaScheme`.

```bash
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.

```json
{
  "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:

```bash
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.

```bash
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"}'
```

| Value | `signDoshaScheme: satyacharya` (default) | `signDoshaScheme: bphs` |
|---|---|---|
| `factors[0].doshas` (lagna sign) | `["pitta"]` | `["kapha"]` |
| `factors[1].doshas` (moon sign) | `["pitta"]` | `["kapha"]` |
| `factors[2].doshas` (strongest graha) | `["vata","pitta","kapha"]` | `["vata","pitta","kapha"]` |
| `composite.vata` | 27 | 27 |
| `composite.pitta` | **67** | 6 |
| `composite.kapha` | 6 | **67** |
| `composite.type` | `pitta` | `kapha` |

:::warning
A dosha reading that does not say which sign table it used is not reproducible. Every response echoes `conventions.signDoshaScheme` and `conventions.ayanamsa`, so store the whole `conventions` object beside the reading. Two products showing different answers for one birth is a convention difference, not a bug, and only the echo turns that argument into a comparison.
:::

## 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.

```bash
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" }
```

:::stat 69 minutes
**Gap between the two dosha clocks** for Lisbon on the June solstice: the sunrise anchored pitta period of the day opens at 10:09:37Z, the fixed clock grid opens it at 09:00:00Z. Both arrays ship in one response from the [dinacharya endpoint](/api-reference#tag/ayurveda/POST/ayurveda/dinacharya "dinacharya endpoint with brahma muhurta and the six dosha periods").
:::

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.

```bash
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"}'
```

| Value for `2026-03-01` | `rituZodiac: sayana` (default) | `rituZodiac: nirayana` |
|---|---|---|
| `ritu.id` | `vasanta` | `sisira` |
| `ritu.gloss` | spring | the dewy season |
| `ritu.start` | `2026-02-18T15:51:27.000Z` | `2026-01-14T09:37:07.000Z` |
| `ritu.end` | `2026-04-20T01:39:12.000Z` | `2026-03-14T19:32:43.000Z` |
| `strength.level` | `moderate` | `highest` |
| `tasteIncreasing.id` | `kashaya` | `tikta` |

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](/docs/coverage "what RoxyAPI covers and what it deliberately does not").

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:

```json
{
  "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](/products/ayurveda-api "Ayurveda API with dosha constitution, dinacharya, ritucharya and the classical catalogue"), 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.