:::note
**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 `source` object naming the text, chapter, verse, translator and edition year, or the literal value `convention` with 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](/products/vastu-api "production-ready Vastu Shastra API with entrance padas, mandala geometry, Ayadi and griha pravesh dates"), 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](/products/vastu-api "Vastu Shastra API with entrance padas, mandala geometry, Ayadi and griha pravesh timing") gives you all 32 padas, their effects and their citations from one call, on the same key as every other domain. [See pricing](/pricing "RoxyAPI pricing tiers and request quotas").

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

:::stat 7 of 32
**Auspicious entrance padas**, measured live across all four sides of one plot on [`POST /vastu/entrance`](/api-reference#tag/vastu/POST/vastu/entrance "Vastu entrance pada endpoint with the classical effect and citation for each of the 32 positions"). 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.

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

:::warning
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](/methodology "how RoxyAPI verifies planetary positions against NASA JPL Horizons") and reproducible from the open [MIT benchmark](https://github.com/RoxyAPI/astrology-api-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.

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

:::tabs
### curl
```bash
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", ... ] }
```

### TypeScript
```typescript
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
```

### Python
```python
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'])
```

### Remote MCP
```bash
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](/docs/mcp "Remote MCP setup for RoxyAPI insight domains").
:::

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](/products/feng-shui-api "Feng Shui API with flying stars, kua numbers and Eight Mansions") 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](/products/vastu-api "Vastu Shastra API with entrance padas, Ayadi, mandala geometry and griha pravesh dates") 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](/pricing "RoxyAPI plans, quotas and flat all inclusive pricing").