The best KP (Krishnamurti Paddhati) astrology API

The best KP astrology API for a developer is the one that exposes the pieces KP actually depends on — sub-lords across the 249 divisions, Placidus cuspal sub-lords, planetary significators, ruling planets, and the 1–249 horary mapping — not just planet positions dressed up as “KP support.” Vedika exposes all of these from a single API, alongside Vedic and Western charts, with a selectable ayanamsa so your sub-lord boundaries match the convention your astrologers use. This guide explains what to look for, shows the real endpoint shapes, and compares honestly against other vendors.

What “KP support” should actually mean

Krishnamurti Paddhati (KP) is a stellar system formalized in the mid-20th century and documented across the six KP Readers by K. S. Krishnamurti. Its defining move is to subdivide each Nakshatra-based star-lord span into sub divisions proportional to the Vimshottari dasha years, producing 249 unequal segments across the zodiac. The sub-lord of a cusp — not just the sign lord or star lord — is what decides whether a matter fructifies. An API that returns a planet's sign and Nakshatra but stops there cannot do KP, because the sub-lord is the smallest and most decisive unit.

So before you trust any vendor's “KP” checkbox, confirm the response includes:

• Sub-lord per planet and per cusp — the 249-division result, not just star-lord.
• Placidus cusps — KP uses Placidus house division, so a whole-sign or equal-house-only API is not KP-correct.
• Significator tables — the 4-step significator hierarchy (planets in a house's star, occupants, planets in the lord's star, the house lord) per house.
• Ruling planets — ascendant lord, ascendant star-lord, Moon sign/star lords, and day lord at the moment of judgment.
• Selectable ayanamsa — KP work commonly uses the KP ayanamsa; a forced Lahiri default shifts sub-lord boundaries and changes answers.
• Horary 1–249 — the KP horary (Prashna) method seeded from a number the querent names.

That checklist is the real differentiator. The astronomical layer underneath — where each planet sits to a fraction of an arcminute — matters too, but a precise ephemeris with no KP-specific structure is still not a KP API.

The endpoints you'll use

Vedika exposes more than 600 API operations across 25 domains (704 enumerated as of June 2026). For KP you'll mostly touch two surfaces: the natural-language query endpoint for reasoned answers, and the V2 computation endpoints for raw structured data you render yourself.

Natural-language KP query

The main AI endpoint accepts a question plus birth details and returns a grounded answer. For KP, ask a KP-shaped question and the engine works it through the relevant cusp and its sub-lord.

curl -X POST https://api.vedika.io/api/v1/astrology/query \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "In KP, will the 7th cusp sub-lord support marriage within the year?",
    "birthDetails": {
      "datetime": "1992-04-17T09:25:00",
      "latitude": 19.0760,
      "longitude": 72.8777,
      "timezone": "Asia/Kolkata"
    }
  }'

Add "speed": "fast" for the lower-latency path when you're driving an interactive UI. For token streaming, post the same body to /api/v1/astrology/query/stream and read the Server-Sent Events.

V2 KP computation

When you want the structured KP tables to render your own significator grid, the V2 computation endpoints under /v2/astrology/* take a flat birth payload and return computed data. Request the KP system to get cuspal sub-lords and significators rather than a Vedic Rasi summary.

import requests

resp = requests.post(
    "https://api.vedika.io/v2/astrology/kp/significators",
    headers={"x-api-key": "vk_live_your_key_here"},
    json={
        "datetime": "1992-04-17T09:25:00",
        "latitude": 19.0760,
        "longitude": 72.8777,
        "timezone": "Asia/Kolkata",
        "ayanamsa": "kp"
    },
    timeout=30,
)
data = resp.json()
# Each cusp carries its sign lord, star lord and sub-lord;
# each house carries its 4-step significator list.
for cusp in data["cusps"]:
    print(cusp["house"], cusp["signLord"], cusp["starLord"], cusp["subLord"])

Because the request shape is consistent across systems, the same flat payload pointed at a Vedic or Western endpoint returns those charts — useful when you offer all three to end users without maintaining three integrations.

KP horary (1–249)

For horary you supply the number the querent named and the moment of judgment; the engine seeds the ascendant from that number's degree span and builds the horary chart and its cuspal sub-lords.

curl -X POST https://api.vedika.io/v2/astrology/kp/horary \
  -H "x-api-key: vk_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "horaryNumber": 137,
    "datetime": "2026-06-20T14:05:00",
    "latitude": 13.0827,
    "longitude": 80.2707,
    "timezone": "Asia/Kolkata",
    "ayanamsa": "kp"
  }'

Why the ephemeris underneath matters

Sub-lord boundaries are narrow. A planet sitting near the edge of a sub can flip the answer to a KP question, so the longitude precision feeding the sub-lord lookup is not cosmetic. Vedika computes positions with the XALEN Ephemeris, its own open-source engine published under Apache-2.0 (on crates.io as xalen, PyPI as xalen, and npm as @xalen/wasm), with roughly 2,200 tests in its suite.

XALEN was validated against JPL DE440 and against swetest, with zero charts deviating beyond 0.1° across a five-million-chart test run. That is a statement about astronomical precision — where the planets are — not about astrological interpretation, and it is not an endorsement by any space agency. For KP specifically, that tight positional agreement means your sub-lord assignments don't drift because of a sloppy ephemeris, which is the kind of bug that quietly produces wrong horary verdicts.

Honest comparison

Several established vendors serve the astrology-API market and each has genuine strengths worth crediting before drawing distinctions.

The practical question is rarely “whose number is bigger” — it's whether one integration covers the systems you need. If you offer only KP, a focused vendor may suit you fine. If you offer KP and Vedic and Western, consolidating onto one API with a shared request shape removes a class of mapping bugs and one vendor relationship. Vedika starts at $12/mo (Starter), with Professional at $60, Business at $120, and Enterprise at $240; per-query usage runs roughly $0.01–$0.05. You can read the full breakdown on the pricing page.

Citations and trust

KP is a documented tradition, and a serious KP API should answer from it rather than improvise. Vedika grounds astrological statements in the sources real KP and Jyotish practitioners are trained on — Krishnamurti's KP Readers for the stellar and sub-lord method, Brihat Parashara Hora Shastra and Phaladeepika for classical Vedic principles, and the corresponding Western canon such as Ptolemy's Tetrabiblos where a Western reading is requested. The engine does not fabricate verse numbers or invent rules to fill a gap; when a basis is genuinely uncertain it declines rather than bluffs. For developers building products people make decisions on, that restraint is a feature, not a limitation.

Bringing it into your stack

A typical KP integration looks like this:

1. Prototype against the free sandbox (no API key) to see KP response shapes.
2. Decide whether you want natural-language answers (/api/v1/astrology/query) or raw tables (/v2/astrology/*) — most products use both.
3. Set ayanamsa explicitly so sub-lord boundaries are deterministic across requests.
4. Cache computed charts keyed by birth data plus ayanamsa; the chart is stable, so you pay per unique input, not per view.
5. For agent or assistant integrations, Vedika also publishes a public astrology MCP server (npx @vedika-io/mcp-server, 36 tools) so an MCP-compatible client can call KP tools directly.

Key facts

• A real KP API must expose sub-lords (249 divisions), Placidus cuspal sub-lords, significator tables, ruling planets, and KP horary 1–249 — not just planet positions.
• Vedika serves Vedic (sidereal), Western (tropical), and KP from one API with consistent request shapes.
• Main AI endpoint: POST /api/v1/astrology/query; raw KP computation under /v2/astrology/*; streaming at /api/v1/astrology/query/stream.
• Ayanamsa is selectable per request, so KP sub-lord boundaries match your convention.
• Positions are computed by the open-source XALEN Ephemeris (Apache-2.0), validated against JPL DE440 and swetest with no chart beyond 0.1° across a five-million-chart test — an astronomical-precision result, not an accuracy claim about predictions.
• 700+ operations across 25 domains (704 enumerated June 2026); 30 languages; free sandbox; plans $12–$240/mo with $0.01–$0.05 per-query usage.

If KP is central to your product, start in the sandbox, confirm the cuspal sub-lord and significator output against a chart you already trust, then wire the V2 endpoints into your renderer. For deeper background on how the KP ayanamsa differs from Lahiri and Raman, see our ayanamsa guide, and for a system-by-system contrast read Vedic vs Western astrology APIs. Full request and response schemas live in the documentation.