Vastu API: Entrance Padas and Ayadi With Verse Citations
Vastu API returning the 32 entrance padas with their verse effects, a typed citation on every verdict, an Ayadi calculator and griha pravesh dates.
TL;DR
- The classical answer to "which way should the front door face" is not a direction. It is one of 32 perimeter padas, and only 7 of the 32 are auspicious.
- Every verdict the Vastu API returns carries a typed
sourceobject naming the text, chapter, verse, translator and edition year, or the literal valueconventionwith the practice it rests on. - Ayadi is text sensitive and unit sensitive. The same 12 by 9 building returns a different yoni under each of three text families, and a different one again when the dimensions arrive in feet.
- Ship a Vastu entrance calculator, an Ayadi calculator or a griha pravesh date finder on the Vastu API, on the same key as feng shui.
Every Vastu tool on the web answers the entrance question with a compass direction. North good, south bad, east auspicious. That is not what the classical chapter says, and any developer who has tried to build a directional checker has run into the gap: the tradition divides the perimeter of a plot into 32 named positions, gives each one a separate stated effect, and never reduces those effects to four cardinal verdicts. A door on the wrong pada of a good side is worse than a door on the right pada of a bad one. RoxyAPI shipped Vastu Shastra today as a full domain, 10+ endpoints computed from typed geometry, and the point of it is not the verdict. It is the citation the verdict carries.
Why the entrance answer is a pada and not a direction
The perimeter of a plot divides into 32 padas, eight to a side, and each pada carries its own effect from its own verse. POST /vastu/entrance takes the plot and where the door sits, then returns the pada, the devata holding that square, the stated effect and the auspiciousness band. Send a rectangle and a fraction along the facing side, or send door coordinates. Here is the East side of a 30 by 40 plot, captured live, every row from verse 53.72 of the same chapter.
| Pada | Devata | Effect | auspiciousness |
|---|---|---|---|
| 1 | Agni | Fire damage. | inauspicious |
| 2 | Parjanya | Daughters rather than sons. | mixed |
| 3 | Jayanta | Great wealth. | auspicious |
| 4 | Indra | Favour with the ruler. | auspicious |
| 5 | Sūrya | A quick temper in the household. | inauspicious |
| 6 | Satyā | Dishonesty. | inauspicious |
| 7 | Bhṛśa | Cruelty. | inauspicious |
| 8 | Antarikṣa | Theft. | inauspicious |
Only two of the eight positions on the side popular Vastu writing recommends most come back auspicious. That is the information a direction only checker throws away.
Ready to build this? The Vastu API gives you all 32 padas, their effects and their citations from one call, on the same key as every other domain. See pricing.
How many of the 32 entrance padas are actually auspicious
Seven. Swept live across all four sides of one plot, the 32 padas come back as 7 auspicious, 3 mixed and 22 inauspicious, and the South side carries no auspicious pada at all, which is why its recommendedPadas array comes back empty rather than suggesting a compromise. The four sides are read from four consecutive verses, so a report can print the verse beside the verdict.
Auspicious entrance padas, measured live across all four sides of one plot on POST /vastu/entrance. 22 are inauspicious and 3 are mixed.
| Side | Padas | Auspicious padas | Verse |
|---|---|---|---|
| North | 25 to 32 | 27, 28, 29 | 53.75 |
| East | 1 to 8 | 3, 4 | 53.72 |
| South | 9 to 16 | none | 53.73 |
| West | 17 to 24 | 20, 21 | 53.74 |
recommendedPadas only ever names positions on the SAME side, so a suggestion asks someone to move a door, never to move a wall. On a south facing plot the honest answer is an empty array and the effect text for the pada the door already sits on, which is a better product than a fabricated compromise.
What the typed source object puts on every verdict
Every verdict in this domain ships with a source object, and text is the discriminator. A cited rule carries the text, chapter, verse, translator and edition year plus a publicDomain flag. A rule that rests on later practice carries the literal string convention and a basis sentence instead, so a printed client report can show which half of the page is classical. Here is the full response for a door 30 percent along the east side, trimmed to the fields a renderer reads.
{
"pada": 3,
"side": "East",
"startCorner": "Northeast",
"ordinalOnSide": 3,
"square": 3,
"devata": { "id": "jayanta", "name": "Jayanta", "padaCount": 2 },
"effect": "Great wealth.",
"auspiciousness": "auspicious",
"reading": "The main entrance falls on pada 3 of the East side, counted from the Northeast corner. That pada is the square of Jayanta. The effect the verse gives for this pada: Great wealth.",
"recommendedPadas": [3, 4],
"source": {
"text": "Brihat Samhita",
"chapter": 53,
"verse": "72",
"translation": "N. Chidambaram Iyer",
"year": 1884,
"publicDomain": true
},
"conventions": { "grid": "81-pada" }
}
publicDomain is doing real work. It is true on the entrance verses, quoted from an 1884 edition, so the citation is safe to print. It comes back false on the citations behind Ayadi, where the edition is still in copyright and only the arithmetic crosses, never a sentence of that English.
Why an Ayadi calculator has to name its text and its cubit
Ayadi shadvarga is six proportional formulas applied to the dimensions of a building, each multiplying a measure and taking the remainder of a division. POST /vastu/ayadi returns the operand, multiplier, divisor, product, remainder and group size for all six, so the arithmetic can be checked by hand rather than trusted. It also takes ayadiText as an input, because the text families read different measures and land on different answers for the same building. A 12 by 9 hasta building, run three ways:
ayadiText | Yoni operand | Product | Remainder | Yoni | yoniAuspicious |
|---|---|---|---|---|---|
manasara | breadth, 9 | 27 | 3 | Simha | true |
perimeter-texts | perimeter, 42 | 126 | 6 | Khara | false |
utpala | area, 108 | 108 | 4 | Kukkura | false |
The unit is not a formatting detail. Send the same 12 by 9 as feet instead of hasta and it converts to 8 by 6 cubits, the yoni remainder moves from 3 to 2, and Simha the lion becomes Dhuma the smoke, auspicious to not. That is why unit and hastaInches are request fields with published defaults rather than hidden constants, and why every response echoes the conventions it was computed under.
How griha pravesh dates are composed over a verified panchang
POST /vastu/timing/griha-pravesh scans a window of up to 93 days and returns the days that clear the day level rules, each carrying the limbs that admitted it. It reads the nakshatra, tithi, weekday and solar position at local sunrise from the same panchang the Vedic endpoints serve, so the dates are composed rather than looked up in a table. Those limbs rest on positions checked against NASA JPL Horizons, published on the methodology page and reproducible from the open MIT benchmark. muhurtaText is a typed switch across two Muhurta texts, and the switch changes the answer.
muhurtaText | Days returned | Shared with the other text | Unique to it |
|---|---|---|---|
muhurta-chintamani | 7 | 5 | 2 |
kalaprakasika | 10 | 5 | 5 |
Sixty one days in Bengaluru, one plot, two independent witnesses, twelve candidate dates between them and only five in both. The response also publishes rejectionsByRule, which counts what knocked out how many days, and leftToTheAstrologer, which names the lagna rules, the eighth from the owner birth moon sign and the combustion checks that a day level search cannot settle. Publishing them beats dropping them silently.
How to call the Vastu API in five minutes
The geometry routes need no place at all, so an entrance checker is a single POST. The date search is the one route that needs coordinates, so resolve the city first and feed the result straight in. GET /location/search returns the latitude, longitude and IANA timezone together, which is what stops a stored reading from drifting by an hour.
curl "https://roxyapi.com/api/v2/location/search?q=Bangalore&limit=1" \
-H "X-API-Key: $ROXY_API_KEY"
# => { "city": "Bengaluru", "latitude": 12.9719, "longitude": 77.5937,
# "timezone": "Asia/Kolkata", "utcOffset": 5.5 }
curl -X POST https://roxyapi.com/api/v2/vastu/timing/griha-pravesh \
-H "X-API-Key: $ROXY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"startDate": "2026-04-01",
"endDate": "2026-05-31",
"latitude": 12.9719,
"longitude": 77.5937,
"timezone": "Asia/Kolkata"
}'
# => total 7, days[0] { date: "2026-04-03", nakshatra: { id: "chitra" },
# tithi: { name: "Pratipada", paksha: "Krishna" }, vara: { name: "Friday" },
# quality: "preferred", admittedBy: [ "nakshatra-admissible", "tithi-window", ... ] }
import { createRoxy } from '@roxyapi/sdk';
const roxy = createRoxy(process.env.ROXY_API_KEY!);
const { data } = await roxy.vastu.findGrihaPraveshDates({
body: {
startDate: '2026-04-01',
endDate: '2026-05-31',
latitude: 12.9719,
longitude: 77.5937,
timezone: 'Asia/Kolkata',
},
});
console.log(data.total); // 7
console.log(data.days[0].date); // "2026-04-03"
console.log(data.days[0].admittedBy); // the limbs that qualified the day
import os
from roxy_sdk import create_roxy
roxy = create_roxy(os.environ['ROXY_API_KEY'])
dates = roxy.vastu.find_griha_pravesh_dates(
start_date='2026-04-01', end_date='2026-05-31',
latitude=12.9719, longitude=77.5937, timezone='Asia/Kolkata',
)
print(dates['total'], dates['days'][0]['date'], dates['days'][0]['quality'])
claude mcp add-json --scope user roxy-vastu \
'{"type":"http","url":"https://roxyapi.com/mcp/vastu","headers":{"X-API-Key":"YOUR_KEY"}}'
10+ tools, Streamable HTTP, no local install and no wrapper process. A deployed agent can then answer "my plot is 30 by 40 facing east and the door is a third along the front" by calling the entrance tool and reading the pada, the effect and the padas it recommends instead. Client setup for Cursor, Claude Desktop and the rest is in the MCP guide.
Every route also takes ?lang=, so the same call in Hindi returns effect as अपार धन। with auspiciousness still the canonical auspicious. Branch on the identifier, render the prose. Vastu sits beside feng shui in the catalog and shares its eight direction identifiers, so one compass input drives both systems with no lookup table in between.
FAQ
Which direction should the main entrance face in Vastu?
The classical answer is a pada rather than a direction. The perimeter divides into 32 positions, eight to a side, each with its own stated effect, so a north facing door on a poor pada is worse than a south facing one on a good pada. Only 7 of the 32 are auspicious. RoxyAPI returns the pada, the devata of that square, the effect and the favourable padas on the same side from one call.
Is there a Vastu API for developers?
Yes. RoxyAPI ships Vastu Shastra as a full domain of 10+ endpoints covering entrance padas, the Vastu Purusha Mandala over a real plot, plot analysis, room compliance, Ayadi shadvarga and griha pravesh dates. It is one of 18+ insight domains on a single key alongside Western astrology, Vedic astrology, feng shui and the rest, with Remote MCP and typed SDKs included at no extra cost.
What is Ayadi shadvarga and how is it calculated?
Six proportional formulas applied to the dimensions of a building, each multiplying a measure and taking the remainder of a division. The RoxyAPI Ayadi calculator returns the operand, multiplier, divisor, product, remainder and group size for every one of the six, plus the member each remainder names where a source names one, so the whole calculation can be checked by hand. Where no public domain source prints the member names, it returns the remainder and the group size and invents nothing.
Do I need a birth chart for Vastu calculations?
No. Every route takes geometry, a facing and, for the date search only, a place and a window. RoxyAPI ships no owner chart route and no numerological facing route, because no primary text ties a birth nakshatra or a radical number to a house facing. The date search applies the owner independent rules and publishes the owner dependent ones it cannot settle in leftToTheAstrologer.
Does a Vastu API work for plots outside India?
Yes. The mandala is geometry aligned to the compass, so it projects over a plot in Lisbon exactly as it does over one in Chennai, and RoxyAPI uses the same eight direction identifiers the feng shui endpoints use. The griha pravesh search takes any latitude, longitude and offset, reads every limb at local sunrise, and falls back to local midnight rather than refusing inside a polar night.
How do I find a griha pravesh date programmatically?
Send a start date, an end date of at most 93 days later, and the coordinates and timezone of the site. RoxyAPI returns every qualifying day with the nakshatra, tithi, weekday and the named rules that admitted it, plus a count of which rule rejected how many days. Pass muhurtaText to choose which of the two Muhurta texts supplies the admissible nakshatras, since the two disagree by design.
Conclusion
Vastu is a citation problem before it is a calculation problem, and a report that cannot say which half of itself is classical is a report nobody can defend. The Vastu API returns the verse on every verdict, the arithmetic on every Ayadi remainder and the rules it deliberately leaves to a human, on the same flat subscription as every other domain. See pricing.