# Vastu Shastra API > Vastu Shastra API for directional home and plot analysis: entrance padas with the classical effect of each of the 32 perimeter positions, the Vastu Purusha Mandala projected over a real plot on the 81 pada or the 64 pada grid, room placement checks over a closed room enum, Ayadi shadvarga across three text families, plot shape and ground level under two schools that genuinely disagree, and griha pravesh dates composed over a verified panchang. Every verdict carries the chapter and verse it rests on as a typed field, or says plainly that it is convention. Directional design from Indian architecture, sitting beside our feng shui endpoints on one key, with Remote MCP and typed SDKs. Directional design with the verse behind every verdict. - Product page: https://roxyapi.com/products/vastu-api - OpenAPI spec: https://roxyapi.com/api/v2/vastu/openapi.json - Remote MCP server: https://roxyapi.com/mcp/vastu - Authentication: `X-API-Key` header on every request - Pricing: https://roxyapi.com/pricing (all domains included in every plan) ## Stats - uptime: 99.95%+ - endpoints: 10 ## Features - Every verdict 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, so a printed report can show which half of it is classical - The Vastu Purusha Mandala projected over a real plot on either the 81 pada Paramasayika or the 64 pada Manduka grid, with the devata of every square, the brahmasthan as a polygon you can draw, the marma points, the six vamsa diagonals named by their devatas and the nine atimarma crossings - All 32 entrance padas with the classical effect of each, resolved from a door coordinate or a fraction along the facing side, plus the favourable padas on the same side to move a door toward - Ayadi shadvarga across three text families that disagree, with the multiplier, divisor, product and remainder shown for every varga so the arithmetic can be checked by hand rather than trusted - A typed cubit: the unit and the hasta length are inputs rather than hidden constants, because every Ayadi remainder is unit sensitive and a silent default makes a stored reading unreproducible - Ground level read under two schools at once, the classical verses and the widely taught modern rule, which contradict each other on a slightly higher east or north, so a practitioner can reconcile our verdict with their teacher instead of arguing with it - Room placement over a closed enum of twelve room types, with the four the chapter actually places carrying a verse and the other eight labelled convention, and a composite score whose weights are published on the response - Griha pravesh date search composed over our own verified panchang, reading the nakshatra, tithi, weekday and solar position at sunrise, with the rules a date search cannot settle published rather than quietly dropped - Two Muhurta texts as a typed switch, one admitting eight nakshatras and the other twelve, because they are independent witnesses and the difference is worth exposing rather than averaging - Direction identifiers shared with the feng shui and I Ching endpoints, so a Vastu quarter and a flying star palace compare without a lookup table ## Includes The Vastu Shastra API bundles these sub-APIs under one key: - Vastu Shastra API - Vastu Entrance API - Vastu Purusha Mandala API - Ayadi Shadvarga API - Griha Pravesh Muhurta API ## Use Cases - Property and interior design tools: plot verdicts, mandala overlays on a floor plan and room by room compliance - Real estate listing platforms: a directional check on a plot or a plan from typed geometry, with no drawing upload - Practitioner and consultation software: Ayadi proportions, mandala geometry and citations a client report can print - House warming and scheduling features: griha pravesh dates over a season, with the limb that qualified each day - AI assistants and chatbots: directional answers over Remote MCP with the classical effect text behind them - Content and editorial platforms: devata, direction and pada reference lookups for explainer pages and structured libraries ## FAQ ### Which direction should the main entrance face? The classical answer is not a direction but a pada. The perimeter of the plot divides into 32 positions, eight to a side, and each one carries its own stated effect, so a north facing door on a poor pada is worse than a south facing one on a good pada. Send the plot and where the door sits and the entrance endpoint returns the pada, the devata of that square, the effect and the favourable padas on the same side to move toward. ### What is the brahmasthan and why does it matter? The brahmasthan is the central block of the mandala, nine squares of the eighty one or four of the sixty four, held by Brahma. It is the part of a plan kept open, and the chapter is blunt about a gate that faces it. The mandala endpoint returns it as a polygon in your own plot coordinates, so it can be drawn straight onto a plan and checked against what stands there. ### What is Ayadi and what does the calculator return? Ayadi shadvarga is a set of six proportional formulas applied to the dimensions of a building, each multiplying a measure and taking the remainder of a division. The API returns the multiplier, divisor, product and remainder for every one of the six, the member each remainder names where a source names one, and the two verdict rules the texts state. Where the aya and vyaya names are not printed in any public domain source, it returns the remainder and the group size and no invented name. ### Why does the ground level verdict differ from what a consultant told me? Because the classical verses and the modern teaching genuinely disagree, and the API returns both rather than choosing. The verses call a higher north-east a loss and expressly allow a slightly higher east or north where level ground is unavoidable; the widely taught modern rule wants the north-east lowest and permits neither. Send the school you want to lead with and the other reading comes back beside it, each with its verse or with a plain statement that it rests on teaching practice. ### Does any of this need a birth chart? No. Every route takes geometry, a facing and, for the date search, a place and a window. There is 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, and a route that invented one would be the least defensible thing in the domain. The date search does apply owner independent rules and publishes the owner dependent ones it cannot settle. ### Does it work 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 the direction identifiers are the same ones the feng shui endpoints use. The date search takes any latitude, longitude and offset and reads every limb at local sunrise, and it falls back to local midnight rather than refusing inside a polar night. ## Endpoints - `POST /api/v2/vastu/entrance` Calculate entrance pada - Vastu main door direction API - `POST /api/v2/vastu/mandala` Generate Vastu Purusha Mandala - 81 pada and 64 pada grid API - `POST /api/v2/vastu/plot` Analyse a plot - Vastu land and site assessment API - `POST /api/v2/vastu/ayadi` Calculate Ayadi shadvarga - Vastu proportion and yoni calculator API - `POST /api/v2/vastu/rooms` Check room placement - Vastu room direction compliance API - `POST /api/v2/vastu/timing/griha-pravesh` Find griha pravesh dates - Vastu house warming muhurta API - `GET /api/v2/vastu/directions` List the eight directions - Vastu dikpala and direction reference API - `GET /api/v2/vastu/directions/{id}` Look up one direction - Vastu dikpala reference API - `GET /api/v2/vastu/devatas` List the 45 devatas - Vastu Purusha Mandala reference API - `GET /api/v2/vastu/devatas/{id}` Look up one devata - Vastu mandala devata reference API ### Vastu Shastra (`/vastu/`) Geometry in, citation out. Every route takes a plot and a facing and no birth data at all: send `plot.width` plus `plot.depth` for a compass aligned rectangle or `plot.polygon` for anything else, and either `facing` (one of the eight sectors) or `facingDegrees` (a bearing measured looking out), never both. The x axis runs east and the y axis north, and the mandala is aligned to the compass rather than to the building, so `facing` only says which side the front is on. Every verdict carries a `source` object: either a `text`, `chapter`, `verse`, `translation` and `year`, or the literal `text: "convention"` with a `basis` naming the practice, which is the discriminator to branch on. Seven school splits are typed request fields with named defaults, echoed back under `conventions` on every response: `grid`, `ayadiText`, `vyayaFormula`, `slopeSchool`, `unit`, `hastaInches` and `muhurtaText`. - `POST /vastu/entrance`: Which of the 32 perimeter padas a main door falls on, with the `devata`, the classical `effect`, `auspiciousness` and `recommendedPadas`, the favourable padas on the same side. Send `door` coordinates or `doorPosition`, a fraction along the facing side, never both. `doorPosition` needs a cardinal facing and returns 400 on an intercardinal one. - `POST /vastu/rooms`: A verdict per room over a closed enum of twelve types, each with `zone`, `idealDirections`, `avoidDirections`, a `remedy` and its own source. Four types carry a verse and the other eight carry convention. `score` is a RoxyAPI composite and `scoring` publishes the weights it was built from. - `POST /vastu/plot`: `shape`, `ratio`, `slope`, `water`, `extensions`, `cuts` and `road`, each with a verdict and a source. `slopeLowDirection` is where the ground is LOW. `slope.schools` always returns BOTH the classical and the modern reading whichever `slopeSchool` you sent, with `slope.chosen` naming the one you led with. - `POST /vastu/mandala`: The Vastu Purusha Mandala projected over the plot. 81 `cells` each with its devata and a `center` point in your coordinates, `brahmasthan` as squares plus a polygon plus an area, `marma`, the six `vamsa` diagonals and the nine `atimarma` crossings. On `grid: "64-pada"` the chapter gives structure only, so there is no devata, marma, vamsa or atimarma. - `POST /vastu/ayadi`: The six Ayadi formulas with `multiplier`, `divisor`, `product`, `remainder` and `groupSize` shown per varga, plus `vayas` and a `verdict` whose `ayaVyaya` is one of `aya-greater`, `equal`, `aya-lesser` or `zero-remainder`. Every remainder is unit sensitive, so `unit` and `hastaInches` are inputs and never assumed. - `POST /vastu/timing/griha-pravesh`: Every day in a window that clears the day level muhurta rules, with `admittedBy` naming the limbs that qualified it, `rules` carrying each requirement and its source, and `rejectionsByRule` counting what knocked the rest out. The window is capped at 93 days. `leftToTheAstrologer` publishes the lagna, house and owner dependent rules a date search cannot settle. - `GET /vastu/directions`: The eight directions with `dikpala`, `kind`, the mandala `squares` and the devatas on them, and the `water` effect for that quarter. - `GET /vastu/directions/{id}`: One of them in full, adding `element` and `places`. Ids are the sector names with case and punctuation folded, so `northeast`, `north-east` and `Northeast` all resolve. - `GET /vastu/devatas`: The 45 devatas, paginated with `total`, `limit` and `offset`. - `GET /vastu/devatas/{id}`: One devata with `class`, `group`, `side`, `quadrant`, `squares`, `cells`, `padaCount`, `entrancePada`, a composed `role`, the `verses` it rests on and a `note` recording a competing reading where two texts disagree. ## Example Response ``` POST /api/v2/vastu/entrance ``` ```json { "pada": 3, "side": "East", "startCorner": "Northeast", "ordinalOnSide": 3, "square": 3, "cell": { "rowFromNorth": 3, "columnFromWest": 9 }, "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. 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" } } ``` ## 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.vastu.calculateEntrancePada({ body: { plot: { width: 30, depth: 40 }, facing: 'East', doorPosition: 0.3 } }); ``` ```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.vastu.calculate_entrance_pada(plot={"width": 30, "depth": 40}, facing="East", door_position=0.3) ``` ```php // composer require roxyapi/sdk (PHP 8.2+, built on Saloon) use function RoxyAPI\Sdk\createRoxy; $roxy = createRoxy(getenv('ROXY_API_KEY')); $result = $roxy->vastu->calculateEntrancePada(plot: ['width' => 30, 'depth' => 40], facing: 'East', doorPosition: 0.3); ``` ```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.Vastu.Entrance.PostAsync(new() { Plot = new() { Width = 30, Depth = 40 }, Facing = RoxyApi.Vastu.Entrance.EntrancePostRequestBody_facing.East, DoorPosition = 0.3 }); ``` 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/vastu`. Tool name convention is `{http_method_lowercase}_{path_with_slashes_as_underscores_kebab_replaced_with_underscores_braces_stripped}`: ``` POST /vastu/entrance -> post_vastu_entrance POST /vastu/mandala -> post_vastu_mandala POST /vastu/plot -> post_vastu_plot ``` `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: `de, en, 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:** [Vastu integration guide](https://roxyapi.com/docs/guides/vastu.md) - [Vastu API: Entrance Padas and Ayadi With Verse Citations](https://roxyapi.com/blogs/vastu-api-entrance-padas-ayadi-with-verse-citations.md) ## Full Reference For complete request and response schemas, fetch the OpenAPI spec at https://roxyapi.com/api/v2/vastu/openapi.json. Master agent manifest at https://roxyapi.com/llms.txt. Execution playbook at https://roxyapi.com/AGENTS.md.