# Ayurveda API > Ayurveda API for dosha profiles, the dinacharya daily routine and the ritucharya seasonal regimen, with a verse cited on every value. Read the vata, pitta and kapha constitution from a verified sidereal birth chart, compute brahma muhurta and the six dosha periods from the real sunrise at any location, resolve the Ayurvedic season from actual solar ingress instants under two published conventions, and serve the catalogue of three doshas, fifteen sub-doshas, six tastes and twenty qualities straight from the primary texts. Deterministic, cacheable and localized. One key covers every RoxyAPI domain, with Remote MCP and typed SDKs. Ship a cited Ayurveda feature, not another dosha quiz. - Product page: https://roxyapi.com/products/ayurveda-api - OpenAPI spec: https://roxyapi.com/api/v2/ayurveda/openapi.json - Remote MCP server: https://roxyapi.com/mcp/ayurveda - Authentication: `X-API-Key` header on every request - Pricing: https://roxyapi.com/pricing (all domains included in every plan) ## Stats - uptime: 99.95%+ - endpoints: 8 ## Features - Constitution read from a verified sidereal birth chart rather than from a quiz, scoring the three factors that carry a classical rule: the rising sign, the sign the Moon occupies, and the strongest graha by shadbala, each returned with the chapter and verse behind it - Brahma muhurta and the six dosha periods computed from the real sunrise at the place the caller sends, which a fixed clock grid gets wrong everywhere except an equinox near the equator - Two dosha-period conventions returned side by side: the sunrise-anchored thirds the frame chapter states, and the modern clock grid labelled as modern, so a product can show one and reconcile against the other - Ayurvedic season resolved from actual solar ingress instants, in either the tropical reckoning published almanacs use or the sidereal one that runs about 24 days later, with the choice echoed in every response - Two classical sign tables offered as a typed convention, because they agree exactly on only three signs of twelve and share no humour at all on two of them - The catalogue from the primary texts: three doshas, fifteen sub-doshas with seat and function, six tastes with the complete eighteen-cell dosha matrix, and twenty qualities as ten opposed pairs each with its action word - Every recorded disagreement between the source texts is stated in the response rather than resolved silently, including the one that decides which dosha a quality pair joins to - Framed throughout for general wellness and cultural interest, with the scope stated in every response in the language it was requested in ## Includes The Ayurveda API bundles these sub-APIs under one key: - Dosha API - Ayurvedic Constitution API - Dinacharya API - Brahma Muhurta API - Ritucharya API ## Use Cases - Wellness and meditation apps: a dosha profile card built from a birth chart, a morning routine anchored to the users own sunrise, and a seasonal guide that changes on the real ingress instant - Multi-domain AI companions: the Ayurvedic constitution beside the Vedic chart the app already fetched, read through the classical rules with a verse on each factor - Yoga and Ayurveda studios in the German, French and Russian markets, where the Sanskrit vocabulary is already the working vocabulary and a localized gloss is what is missing - Habit and routine products: the brahma muhurta window and the six dosha periods as real timestamps for a users own place, which is the part a printed timetable cannot supply - Editorial and newsletter platforms: a seasonal column that turns over on the ingress rather than on the first of the month, in every language the API ships - AI agents over Remote MCP: what is my dosha, when is brahma muhurta today, what season am I in, each answered with its citation and its scope in the payload ## FAQ ### What is an Ayurveda API? It turns birth data, a date and a location into the Ayurvedic values an app needs: the vata, pitta and kapha constitution, the brahma muhurta window, the six dosha periods of the day and night, and the season with the regimen the primary text gives for it. Every value carries the work, chapter and verse it comes from, and every response states that it is for general wellness and cultural interest rather than medical advice. One key also unlocks every other RoxyAPI domain and a Remote MCP server. ### Can a birth chart show a dosha? The classical Jyotish texts do assign a humour to each graha and to each rising sign, and one of them states that the strongest planet imparts its humour to the native. This API scores exactly the three factors that carry such a rule and returns the verse behind each. What no primary text states is how to weigh those factors against each other, so the blend that produces the percentage split is labelled as a RoxyAPI convention, versioned, and published with its own weights inside the response. ### 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 and the API returns both instants along with sunrise, sunset and the six dosha periods. The window is a fixed offset rather than a share of the night, which is the reading the classical commentary settles on outright, and calculators that scale it to the night length are following the reading it rejects. ### What Ayurvedic season am I in? Send a date and the API resolves the ritu from the real solar ingress instants and returns the season with its exact opening and closing times, the half of the year the sun is in, where each dosha stands in its yearly cycle, and the behaviour items the chapter gives. Boundaries are measured in the tropical zodiac by default, which is what published almanacs use for seasons; the sidereal reading is available as a convention and runs about 24 days later. ### Is any of this medical advice? No. Every response from this API carries a scope statement in the requested language: it is for general wellness and cultural interest only, it is not medical advice, and it is unrelated to the diagnosis, mitigation, prevention or treatment of any condition. No route accepts a health complaint, no field names a substance, and no endpoint returns a recommendation of one. Anyone with a health question should speak to a qualified professional. ### Which texts is the Ayurveda API built from? The Charaka Samhita and the Ashtanga Hridaya for the doshas, the tastes, the qualities, the daily routine and the seasonal regimen, and the Brihat Jataka for the graha and sign rules the constitution reads. Every value ships with the work, chapter and verse it comes from, and with whether the cited translation may be quoted or only referenced. Where two texts disagree, both readings are returned rather than one being chosen quietly. ## Endpoints - `POST /api/v2/ayurveda/constitution` Ayurvedic constitution from a birth chart - Dosha profile API - `POST /api/v2/ayurveda/dinacharya` Dinacharya daily routine - Brahma muhurta and dosha clock API - `POST /api/v2/ayurveda/ritucharya` Ayurveda seasonal regimen - Ritucharya and ritu resolution API - `GET /api/v2/ayurveda/daily` Daily Ayurveda reading - Dosha clock and brahma muhurta by location API - `GET /api/v2/ayurveda/doshas` List the three doshas - Dosha catalogue API - `GET /api/v2/ayurveda/doshas/{id}` Get one dosha - Vata pitta kapha profile API - `GET /api/v2/ayurveda/tastes` List the six tastes - Ayurveda rasa and dosha matrix API - `GET /api/v2/ayurveda/qualities` List the twenty qualities - Ayurveda guna pairs API ### Ayurveda (`/ayurveda/`) Birth data, a date and a place in; a cited reading out. Nothing here asks a user about their own body: there is no questionnaire, no balancing route, no field naming a substance and no input for a health complaint. Every value carries a `source` object naming the `text`, `chapter` and `verse` behind it, with `translation`, `year` and a `publicDomain` flag, and every response carries `meta.disclaimer`, a scope sentence in the requested language that says the reading is for general wellness and cultural interest rather than medical advice. Render it. Five school splits are typed request fields with named defaults, echoed back under `conventions`: `signDoshaScheme` on the constitution, `doshaClock` on the dinacharya, and `ritucharyaScheme`, `rituZodiac` and `hemisphere` on the ritucharya. Sanskrit identifiers (`vata`, `vasanta`, `madhura`, `guru`) never translate; the gloss beside them does. - `POST /ayurveda/constitution`: The vata, pitta and kapha shares from a birth chart. `factors` is exactly three, the rising sign, the sign the Moon occupies and the strongest graha by shadbala, each with its own `doshas`, `weight` and `source`. `composite` carries `dominant`, `secondary`, `type` and `convention: "roxyapi/v1"` with its `weighting` published inside the response, because the texts give the factors and never the weighting. `strengthRanking` and the seven row `planetDoshas` table come back beside it. Takes `date`, `time`, `latitude`, `longitude`, optional `timezone`, `ayanamsa` and `signDoshaScheme`. - `POST /ayurveda/dinacharya`: `sunrise`, `sunset`, `nextSunrise`, the `brahmaMuhurta` window with the `muhurtaMinutes` and `muhurtasPerAhoratra` it was built from, the six `doshaPeriods` and the `routine` as ordered items with a `timing` sentence each. Both clocks always come back: `doshaPeriods` is whichever `doshaClock` you sent and `alternatePeriods` is the other, so a product can show one and reconcile against the other. Takes `date`, `latitude`, `longitude`, optional `timezone` and `doshaClock`. - `POST /ayurveda/ritucharya`: The season for a date with its real `start` and `end` ingress instants and the `solarMonths` it spans, plus `ayana`, `phase` with the tastes that grow in it, `strength`, `tasteIncreasing`, the nine slot `doshaCycle` and the `regimen` items. Takes `date` only, plus optional `ritucharyaScheme`, `rituZodiac` and `hemisphere`. - `GET /ayurveda/daily`: The day composed for one place under the defaults, a lighter shape than the two POSTs combined: `brahmaMuhurta`, `doshaPeriods`, the `ritu` flattened to its ids, and a one line `summary`. Optional `date`, `latitude`, `longitude` and `timezone`, cached to the UTC rollover. - `GET /ayurveda/doshas`: The three, each with `sanskritName`, `devanagari`, `alsoCalled`, the single `element` the verses give beside the `modernElementPair` in circulation, `qualities`, `qualityGunas` joining across to the guna table, `seats` with a `specialSeat` and a `seatsVariant` recording where a second text differs, `functions`, `states` and the five `subDoshas`. - `GET /ayurveda/doshas/{id}`: One of `vata`, `pitta` or `kapha`. Any other id returns 400 naming the three. - `GET /ayurveda/tastes`: The six rasas in the order the verse names them, which is also `strengthOrder` and is not the order most modern lists print. Each carries `elements`, `decreases` and `increases`, and `matrix` is the same eighteen cells inverted, keyed by dosha with `decreasedBy` and `increasedBy`. - `GET /ayurveda/qualities`: The twenty gunas as ten opposed `pairs`, each member with its `english`, its `action` and `actionSanskrit`, and the `doshas` it belongs to. `rule` is the like-increases-like sentence the whole domain runs on. Two response conventions worth knowing before you parse. Pagination is nominal on the three catalogue routes, since the collections are three, six and ten rows, so `limit` is capped at the collection size and `offset` is there for shape rather than for paging. And a recorded disagreement between two texts is always served rather than resolved, as a `note` inside a `source` or as a named field like `seatsVariant`, so a UI can show both readings instead of picking one silently. ## Example Response ``` POST /api/v2/ayurveda/constitution ``` ```json { "frame": { "ayanamsa": "lahiri", "ayanamsaDegrees": 23.72820922463809 }, "lagnaSign": "leo", "moonSign": "scorpio", "factors": [ { "id": "lagna-sign", "input": "leo", "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, "note": "Chapter 18, not 19: the running head on the printed pages reads CH. 19 while the chapter opening precedes the list and chapter 19 begins after the Pisces entry, in two independent scans and in the Rao translation. It is an appended authority the translator credits to Satyacharya, never a verse of Varahamihira. All twelve rows agree across both translations; the two translations order the pair of humour words differently in seven rows, which carries no weight because the sets are identical." } }, { "id": "moon-sign", "input": "scorpio", "doshas": [ "pitta" ], "weight": 1, "source": { "text": "Brihat Jataka", "chapter": "18", "verse": "20", "translation": "N. Chidambaram Iyer", "year": 1885, "publicDomain": true, "note": "The verse expressly equates the effects of a sign occupied by the Moon with the effects of the same sign rising, which is what licenses reading the rising-sign table across to the Moon. The humours themselves come from whichever sign table the signDoshaScheme convention names, so this citation covers the read-across and not the table. Hora Sara chapter 29 states a bodily temperament from the Moon sign directly and is cited by reference only, because no public-domain English of it exists." } }, { "id": "strongest-planet", "input": "Mars Sun Moon", "doshas": [ "vata", "pitta", "kapha" ], "weight": 2, "source": { "text": "Saravali", "chapter": "38", "verse": "5", "translation": "R. Santhanam", "year": 1983, "publicDomain": false, "note": "Referenced, never quoted: no public-domain English exists. Three limits ride with it. The verse names only the five non-luminaries while shadbala ranks seven grahas; it says strengths rather than shadbala, so the choice of metric is ours; and its own frame is the five mahabhutas, with the humours named after them. The blend it licenses is what the composite share split rests on." } } ], "composite": { "vata": 7, "pitta": 87, "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": "Mars", "totalVirupas": 525.53, "rank": 1, "strong": true }, { "graha": "Sun", "totalVirupas": 521.16, "rank": 2, "strong": true }, { "graha": "Moon", "totalVirupas": 511.89, "rank": 3, "strong": true } ], "planetDoshas": [ { "graha": "Sun", "sanskritName": "sūrya", "doshas": [ "pitta" ], "dhatu": "bone", "dhatuSanskrit": "asthi", "doshaSource": { "text": "Brihat Jataka", "chapter": "2", "verse": "8 to 11", "translation": "N. Chidambaram Iyer", "year": 1885, "publicDomain": true, "note": "Confirmed row for row against the independent B. Suryanarain Rao translation. The Moon and Venus rows read vata before kapha in BOTH translations, which is the reading widely circulated material diverges from. The verses cover the seven grahas only, so Rahu and Ketu carry no humour here and none is supplied." }, "dhatuSource": { "text": "Brihat Jataka", "chapter": "2", "verse": "11", "translation": "N. Chidambaram Iyer", "year": 1885, "publicDomain": true, "note": "The two translations disagree on two of the seven rows. Saturn is snayu, which is attested as sinew, tendon, muscle and nerve alike, so the Sanskrit ships and no English is chosen; Iyer reads muscles and Rao reads nerves. These seven are not the sapta-dhatu set and must not be joined to one." } }, { "graha": "Moon", "sanskritName": "candra", "doshas": [ "vata", "kapha" ], "dhatu": "blood", "dhatuSanskrit": "rakta", "doshaSource": { "text": "Brihat Jataka", "chapter": "2", "verse": "8 to 11", "translation": "N. Chidambaram Iyer", "year": 1885, "publicDomain": true, "note": "Confirmed row for row against the independent B. Suryanarain Rao translation. The Moon and Venus rows read vata before kapha in BOTH translations, which is the reading widely circulated material diverges from. The verses cover the seven grahas only, so Rahu and Ketu carry no humour here and none is supplied." }, "dhatuSource": { "text": "Brihat Jataka", "chapter": "2", "verse": "11", "translation": "N. Chidambaram Iyer", "year": 1885, "publicDomain": true, "note": "The two translations disagree on two of the seven rows. Saturn is snayu, which is attested as sinew, tendon, muscle and nerve alike, so the Sanskrit ships and no English is chosen; Iyer reads muscles and Rao reads nerves. These seven are not the sapta-dhatu set and must not be joined to one." } } ], "summary": "The chart reads pitta, and pitta carries the largest share of it at 87 percent. Several grahas share the strength in this chart, so the reading is a blend rather than one humour, which is what the classical rule on several strong planets allows. The reading is built from three cited factors: the rising sign, the sign the Moon occupies, and the strongest graha by shadbala. The weights across those factors are a RoxyAPI convention and are published in this response, because the primary texts give the factors and never the weighting.", "conventions": { "signDoshaScheme": "satyacharya", "ayanamsa": "lahiri" }, "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." } } ``` ## SDK Quick Start ```typescript // npm install @roxyapi/sdk import { createRoxy } from '@roxyapi/sdk'; const roxy = createRoxy(process.env.ROXY_API_KEY!); const { data, error } = await roxy.ayurveda.calculateAyurvedicConstitution({ body: { date: '1990-07-04', time: '10:12:00', latitude: 28.6139, longitude: 77.209, timezone: 'Asia/Kolkata' } }); ``` ```python # pip install roxy-sdk import os from roxy_sdk import create_roxy roxy = create_roxy(api_key=os.environ["ROXY_API_KEY"]) result = roxy.ayurveda.calculate_ayurvedic_constitution(date="1990-07-04", time="10:12:00", latitude=28.6139, longitude=77.209, timezone="Asia/Kolkata") ``` ```php // composer require roxyapi/sdk (PHP 8.2+, built on Saloon) use function RoxyAPI\Sdk\createRoxy; $roxy = createRoxy(getenv('ROXY_API_KEY')); $result = $roxy->ayurveda->calculateAyurvedicConstitution(date: '1990-07-04', time: '10:12:00', latitude: 28.6139, longitude: 77.209, timezone: 'Asia/Kolkata'); ``` ```csharp // dotnet add package RoxyApi.Sdk (.NET 8 and netstandard2.0) using RoxyApi; using Microsoft.Kiota.Abstractions; var roxy = new RoxyClient(Environment.GetEnvironmentVariable("ROXY_API_KEY")!); var data = await roxy.Ayurveda.Constitution.PostAsync(new() { Date = new Date(1990, 7, 4), Time = new Time(10, 12, 0), Latitude = 28.6139, Longitude = 77.209, Timezone = new() { String = "Asia/Kolkata" } }); ``` TS, Python, and PHP method names come from OpenAPI `operationId` (camelCase in TS and PHP, snake_case in Python). TS returns `{ data, error, response }` — check `error` first. Python raises `RoxyAPIError`; PHP throws `RoxyApiException` (catch and switch on `$e->errorCode`). The C# (.NET) client is path-fluent — `roxy.Domain.Resource.GetAsync()` or `.PostAsync(new() { ... })`, PascalCase mirroring the URL — and throws `RoxyError` (switch on `e.Code`). ## MCP Tool Naming Each REST endpoint has a matching MCP tool on `https://roxyapi.com/mcp/ayurveda`. Tool name convention is `{http_method_lowercase}_{path_with_slashes_as_underscores_kebab_replaced_with_underscores_braces_stripped}`: ``` POST /ayurveda/constitution -> post_ayurveda_constitution POST /ayurveda/dinacharya -> post_ayurveda_dinacharya POST /ayurveda/ritucharya -> post_ayurveda_ritucharya ``` `tools/list` is free and public (no auth). `tools/call` requires `X-API-Key` (same billing as REST — 1 request per call). ## Multi-language Support Append `?lang=` to translated endpoints. Supported on this domain: `en, de, es, fr, hi, pt, ru, tr`. English is the default. The `lang` param is ignored on endpoints that have no translatable text. ## Error Contract Success returns clean JSON, no wrapper. Errors return `{ "error": string, "code": string }`. Switch on `code` (stable): - `validation_error` (400, returns `issues[]` with all field errors at once) - `api_key_required` (401), `invalid_api_key` (401) - `subscription_inactive` (403), `subscription_not_found` (404) - `not_found` (404; PATH-routing 404s carry a fuzzy `suggestion` field) - `rate_limit_exceeded` (429) - `internal_error` (500) Do not retry on 4xx. Do retry on 429 and 5xx with exponential backoff. ## Related Surfaces - **Guide:** [Ayurveda integration guide](https://roxyapi.com/docs/guides/ayurveda.md) - [Ayurvedic Constitution From a Birth Chart: Dosha API](https://roxyapi.com/blogs/ayurveda-api-dosha-constitution-from-birth-chart.md) ## Full Reference For complete request and response schemas, fetch the OpenAPI spec at https://roxyapi.com/api/v2/ayurveda/openapi.json. Master agent manifest at https://roxyapi.com/llms.txt. Execution playbook at https://roxyapi.com/AGENTS.md.