Skip to main content

Changelog

Changes to the Asterwise API and MCP server. See versioning for what counts as a breaking versus additive change.

Current API version: 2026-03-01

Entries from June 2026 onward are dated by deployment. Earlier entries are grouped by month, covering the period when the v1 surface was being built.

2026-10-09​

Added

  • Gochar: favorable_reason on each transit says which rule decided is_favorable_from_moon (the house from the Moon, or the bindu count).

Changed

  • Gemstones: secondary is now the first usable second gem (yogakaraka, 9th lord, 5th lord or Atmakaraka, skipping the lagna lord's and any contraindicated one), with its role.

  • Lal Kitab: Rahu in a malefic state in Jupiter's houses or pakka ghar now indicates the debt to father, as the 1952 text says.

  • Daily horoscopes: the closing "what's next" line now names a real upcoming sign change and its date.

  • Varshaphal Harsha Bala text uses correct ordinals ("1st", "3rd").

  • Lo Shu: number_analysis[].plane is marked deprecated; use lo_shu_plane.

  • MCP: the dream symbol category parameter lists the eight accepted values.

  • Lal Kitab chart and remedies: sources and each debt's source now read "Lal Kitab tradition", and remedy items no longer include page. The field stays in the schema, marked deprecated, so existing clients keep parsing.

2026-10-08​

A full review of every engine against Jagannatha Hora, Swiss Ephemeris, Drik Panchang, USNO and the classical texts. Values change where they now follow the source; every change to the response shape is a new field.

Added

  • Western natal and return charts: Lilly's full essential_dignities per planet (triplicity, term, face, peregrine) and the chart sect.
  • New fields: dasha dasha_start_date and balance_years, KP rasi_house and significator strength_order, gochar ashtakavarga_score_reduced, varshaphal vara_lord, ithsala_type and orb_limit, remedies in_dusthana_house and is_combust, gem contraindicated and caution, rudraksha how_to_wear, moon next_phase_at and principal_phase, sade sati segments, biorhythm trend, mobile number country, digits_used and master_number, Lo Shu lo_shu_plane, name correction karmic debt per number, and more (see each endpoint).
  • Optional date/timezone for angel number of the day and tarot card of the day; KP ruling planets take a date, time and timezone and default to the current moment.

Changed

  • Dashas: the first mahadasha's sub-periods now continue the full period that began before birth; Yogini runs three cycles; Ashtottari uses the BPHS nakshatra groups; Char dasha follows K.N. Rao's published method.
  • KP places planets cusp to cusp. D30 and D60 follow BPHS; Shadbala, Vimshopaka and Bhava Bala match B.V. Raman's worked example.
  • Yogas, doshas, gochar, ashtakavarga, varshaphal, sahams and Harsha Bala follow their classical rules; Mangal dosha is cancelled only by a strong Jupiter or Venus.
  • Festivals (Vat Savitri, Vat Purnima, Purnima vrat, Sharad Purnima), exact moon phase dates, Sade Sati with retrograde re-entries and biorhythm direction.
  • Western: hemisphere counts, applying aspects, progressed Ascendant and sign compatibility.
  • Numerology: names are reduced part by part, karmic debt is found anywhere in the reduction, Birth Day keeps 11 and 22, and mobile numbers leave the country code out.
  • Clear errors instead of failures for polar latitudes, impossible dates and inputs with no letters or digits.

2026-10-07​

Changed

  • Lal Kitab always uses the Lahiri ayanamsa, and the ayanamsa field now says so: it is accepted (requests that send it keep working) and ignored.
  • MCP: asterwise_check_mobile_number and asterwise_check_vehicle_number say their name and date inputs are not used (only the digits are analysed). The asterwise_get_varshaphal output description now lists the fields the API returns (election_fallback and moon_election on the year lord, integer age_years, tajika_aspect_houses_matched).
  • The Postman collection is rebuilt from the live OpenAPI spec and its page describes the file as it is: set the api_key collection variable; requests are grouped by API area.

2026-10-06​

Changed

  • The spec now says time is required on the 16 endpoints that need it: KP chart and significators, atmakaraka, char dasha, ishta devta, varshaphal with saham and harsha bala, gochar, dasha transits, remedies, gemstones, nakshatra prediction, pitra dosha, ghat chakra and natal crystal recommendations. They always refused a request without a time; the spec wrongly said it was optional with a sunrise fallback. Requests that worked before work the same. A request without a time still gets validation_error, now with details naming the time field.
  • Pitra dosha, ghat chakra and natal crystals have their own request schemas (PitruDoshaRequest, GhatChakraRequest, NatalCrystalRequest), because the shared ones are also used where no time is needed. The JSON you send is unchanged.
  • Five endpoint descriptions no longer say "Core tier or above" or "Vedic tier or above". No such plans exist: every plan reaches every endpoint.

Added

  • Prashna accepts every ayanamsa: raman and tropical as well as lahiri and kp, like every other chart endpoint.

SDKs and MCP

  • Python SDK 0.8.0 and TypeScript SDK 0.8.0 carry these changes: time is required on the 16 endpoints above, and Prashna takes every ayanamsa. In Python, three methods take their own request models, so the argument name changes: pitra_dosha(pitru_dosha_request=...), ghat_chakra(ghat_chakra_request=...) and crystals_recommend_natal(natal_crystal_request=...).
  • MCP: tools that need the birth time now require it instead of failing at the API. asterwise_get_kp_significators returns only the requested house_number. asterwise_get_business_name_analysis no longer asks for a birth date it never used. asterwise_get_prashna_chart now casts the chart for the date and time you give (it used the current moment), with an optional timezone.

2026-10-05​

Changed

  • Python SDK 0.7.0 needs Python 3.10 or newer (3.9 reached end of life in October 2025) and urllib3 2.8.0 or newer, for its security fixes. On Python 3.9, pip keeps you on 0.6.x, which keeps working.

  • TypeScript SDK 0.6.1 has no runtime dependencies. 0.6.0 listed @hey-api/client-fetch, which it never imported, and that pulled the OpenAPI code generator and a vulnerable js-yaml into apps that installed the SDK. No code changes needed: npm install asterwise@latest.

  • TypeScript SDK 0.7.0: same methods, requests and responses. response on a result is now typed as possibly missing, which it already was after a network failure; strict TypeScript code reads result.response?.status. A success response with a broken body, or an invalid baseUrl, now returns an error result instead of throwing. See the SDK changelog.

  • The TypeScript SDK page imported from asterwise/dist/…, which the package doesn't expose, so its examples failed to run. They now import from asterwise and pass a shared client. The KP Ruling Planets example now sends target_date, target_time and target_timezone (it sent field names the endpoint ignores, so it showed the current moment).

  • Responses over 1 KB are gzip-compressed when your client sends Accept-Encoding: gzip (most HTTP clients do, and decompress for you). A five-level dasha answer goes from about 21 MB to 2.4 MB. Response signatures (X-Asterwise-Signature) still cover the uncompressed JSON. Account, sign-in, key and billing responses are never compressed.

  • A dasha request with levels: 4 counts as 3 requests and levels: 5 as 10 toward the per-IP limit of 60 a minute. Monthly calls, billing and your plan's per-minute limit count each call once. See rate limits.

  • Request bodies must arrive within 30 seconds; slower uploads get invalid_request_body. The 64 KB body limit is now enforced while the body is read, without buffering more than that.

  • Per-IP limits use the visitor address Cloudflare reports for requests that reach us through our Cloudflare edge, so visitors routed through the same edge server never share a limit.

  • Deleting an account now locks it at once (its API keys return api_key_revoked, sessions and AI-app connections end, a paid plan stops renewing) and deletes it 30 days later. Until then the link in the confirmation email, or signing in, restores it with the same keys. Only what tax law requires is kept, for eight financial years: orders, plans and any tax invoices.

  • Data retention: the request log is kept 90 days and usage history 13 months. Password sign-ups that never confirm their email, never pay and make no calls get a reminder and are removed 30 days after sign-up.

  • The account export (GET /v1/account/export, signed-in dashboard only) now includes everything held about the account: profile, all keys, plans, orders, call packs, sessions, AI-app connections, usage per day and the request log. It downloads as a JSON file (the export document itself, not wrapped in success/data), streamed so large accounts work, one export at a time per account.

  • Deleting an account from the dashboard needs a 6-digit code emailed to the account (valid 10 minutes, five tries), so a signed-in browser alone can't delete it.

  • Email confirmation and account restore links open a page on asterwise.com, and only its button acts, so mail scanners that open links can't confirm or restore. The token sits after #, which browsers never send to a server. Links in older emails still work: they open the same pages.

  • New error account_action_limit_exceeded (dashboard only): a deletion code was asked for too often, or an export is already running. retry_after says how long to wait.

  • Cached calculation results are kept per account, so a result is never served to, or detectable by, another account.

Fixed

  • POST /v1/astro/sade-sati is about ten times faster (≈0.1 s instead of ≈1 s), with identical results.

2026-10-04​

Added

  • POST with a JSON body for the five endpoints that took personal data in the URL: /v1/numerology/life-path (date), /v1/numerology/lucky-numbers (name, date, optional count), /v1/numerology/mobile-number and /v1/numerology/vehicle-number (number). /v1/numerology/personal-year already had one; its name is now optional, since the calculation never used it. Each POST gives exactly the same answer as the GET. SDK 0.6.0 adds life_path_post, lucky_numbers_post, mobile_number_post and vehicle_number_post (TypeScript: lifePathPost, luckyNumbersPost, mobileNumberPost, vehicleNumberPost), and the MCP tools now use POST.

Deprecated

  • GET on those five endpoints. Birth dates, names, phone numbers and number plates in a URL end up in proxy, CDN and server logs and in browser history; a JSON body does not. The GET forms keep working unchanged for at least 12 months. Every response from them carries a Deprecation: @1791072000 header (RFC 9745) and a Link to this entry, and they are marked deprecated in the OpenAPI document. The SDKs keep their GET methods and mark them deprecated. No removal date is set yet; it will be announced here and by email first.

Changed

  • API keys no longer manage the account. Everything that changes an account (billing and plans, creating, rotating or revoking keys, AI-app connections and consent, the signing secret, logs, export, deletion) needs a dashboard sign-in. An API key sent to those endpoints gets the new session_required error (403). An API key keeps calling every calculation endpoint and can read its own record (GET /v1/keys/me) and usage (GET /v1/keys/me/usage). A leaked key can still spend calls until it is revoked, but it can no longer change the plan, revoke other keys or delete the account.
  • GET /v1/keys/me/usage reports the account's calls this month, the count the monthly limit is enforced on (shared by every key), instead of the calling key's own count.
  • Email confirmation. Password sign-ups get a confirmation link (valid 24 hours) instead of the welcome email, which follows confirmation. Until the email is confirmed an account can sign in and use its Sandbox calls, but subscribing, upgrading, resuming a plan, updating the card, connecting an AI app and the admin page return the new email_not_verified error (403) and send a fresh link. Opening a password reset link or signing in with Google also confirms the email. If an unconfirmed account's address is then used to sign in with Google, the Google user gets the account and its password, sessions, API keys and AI-app connections are ended.
  • Account responses include email_verified.
  • Password sign-in limits: five wrong passwords for an email, or twenty from one network, within 15 minutes pause password sign-in for that email or network with the new login_attempts_exceeded error (429, Retry-After). Every failed sign-in now returns the same authentication_failed message, whether or not the email has an account.
  • Sign-up refuses disposable email domains with invalid_email.
  • MCP OAuth: refresh tokens are single use. A client retrying within 30 seconds of a refresh gets the same tokens again; a used refresh token presented later revokes that connection, so the app has to connect again. Client registration grants only authorization_code and refresh_token with the asterwise:read scope, whatever else is requested.

Removed

  • GET /v1/keys, DELETE /v1/keys/{key_id}, GET /v1/keys/usage (an alias of /v1/keys/me) and DELETE /v1/keys/me/data. Keys are listed and revoked in the dashboard; account data is deleted with the account.

  • Magic-link sign-in (POST /v1/auth/magic-link, /v1/auth/verify, /v1/auth/exchange), unused since the website moved to password and Google sign-in, and its eight error codes (magic_link_*, exchange_code_*). Their reference pages redirect to the error index.

  • Five error codes the API never returned: date_out_of_supported_range, polar_latitude_unsupported, interpretation_not_found, insufficient_tier and dependency_unavailable. No response changes: dates outside 1800-01-01 to 2099-12-31 still return validation_error. The Python and TypeScript SDKs drop them in 0.4.0.

  • POST /v1/keys, which created a free key for any email without signing in. Keys are created in the dashboard. The two error codes only that route returned, endpoint_restricted and invalid_key_name, are gone too; the SDKs drop them in 0.5.0.

Fixed

  • Each error reference page now says where the error can occur (for example session_not_found: signed-in website sessions only) instead of "Affects all endpoints" on every page, and each endpoint page lists the errors that endpoint can return.
  • Endpoint reference pages show the utc_offset parameter and birth_moment field added on 2026-09-28, with example responses from the current engine.
  • max_keys_exceeded said every account could have 10 active keys; the limit is per plan: 5 on Sandbox, 10 on Builder, 20 on Launch, 40 on Scale.
  • Typos: "the Trikona Trikona lordship" and "lordsing" in the natal crystal recommendation description; "the classical classical" in the asterwise_get_dasha MCP tool description.

2026-09-30​

Changed

  • Cursor completes OAuth sign-in on its first connection to the MCP server. Other clients, and directory scanners, can still read the tool catalogue before signing in.
  • Google sign-in responses include is_new_account.
  • GET /health returns only {"status": ...}. When the database is unreachable it returns 503.
  • MCP: an error from the Asterwise API carries the API request id, so support can trace it.

2026-09-28​

Added

  • POST /v1/astro/panchanga returns the whole panchanga day (sunrise to next sunrise) beside the sunrise limbs: every tithi, nakshatra (with padas), yoga and karana active in it with ISO start and end times and at_sunrise / is_kshaya / is_vriddhi flags; sunrise, sunset, moonrise, moonset; Sun and Moon rashi and Sun nakshatra; masa (amanta and purnimanta, with Adhik months); samvat (Vikram, Shaka, Gujarati, samvatsara); ritu; ayana; and timings (Brahma Muhurta, Abhijit, Vijaya, Godhuli, Sandhyas, Nishita, Pradosh, Rahu Kaal, Gulika, Yamaganda, Durmuhurta, Varjyam, Amrit Kaal, Bhadra with residence, Panchaka, the five parts of the day).
  • The monthly panchanga calendar adds, per day, sunrise, sunset, moonrise, moonset, paksha, masa, Bhadra windows and every limb of the day, so a kshaya tithi now appears on the day it runs.
  • GET /v1/astro/panchanga/festivals: about 50 named festivals (from 20), and with the new categories parameter every Ekadashi, Pradosh, Sankashti Chaturthi, Masik Shivaratri, Purnima and Amavasya (vrat), the 12 sankrantis, eclipses with local visibility and contact times, and periods (Adhik Maas, Chaturmas, Pitru Paksha, both Navratris, Holashtak, Kharmas). Entries add id, category, masa, paksha, tithi with start and end, the rule that fixed the day, observance_window, note, and end_date for periods. The default remains the named festivals.
  • POST /v1/astro/muhurta: six more activities (vehicle_purchase, property_purchase, mundan, annaprashan, upanayana, vidyarambha), ranges up to a year, optional location, participants (Tarabala and Chandrabala), max_windows_per_day and min_duration_minutes. Windows add start_at / end_at (ISO 8601), civil_date, panchanga_day, grade, nakshatra, lagna, masa, reasons and cautions; the response adds criteria and excluded_minutes.
  • Divisional charts: each planet gains dignity, is_vargottama and (with a birth time) its whole-sign house from the varga lagna, and a top-level houses table per chart.
  • Nakshatra prediction: tarabala.cycle, cycle_name, is_moon_in_birth_nakshatra, and transit_nakshatras (every nakshatra of the day with its tara).
  • MCP: asterwise_geocode (104 tools).
  • Every birth-data request accepts an optional utc_offset (±HH:MM or ±HH:MM:SS) that overrides the time zone's offset. See birth time and time zones.
  • POST /v1/astro/natal returns birth_moment: the UTC instant used, the offset applied, where it came from (iana, local_mean_time, explicit_offset) and whether the local time fell in a daylight-saving gap or overlap.
  • GET /v1/astro/ayanamsha adds true_value_decimal (mean ayanamsa plus nutation), the offset subtracted from apparent planetary positions.
  • The natal Avakahada block adds paya_basis.

Changed

  • Muhurta windows are found in continuous time instead of Choghadiya slots, with each activity's nakshatra, tithi and weekday rules, seasonal bans (Chaturmas, Adhik Maas, Pitru Paksha, Kharmas, Holashtak, Guru/Shukra asta, Panchaka) and graded scores. The earlier window fields keep their meaning: date is the panchanga day and start / end are HH:MM on it; use start_at / end_at for the exact instants.
  • Festival dates follow the lunar month and the classical part of the day for each festival, instead of the Sun's sign and the sunrise tithi.
  • The Tara named for counts 10 and 19 is Anujanma and Trijanma (was Janma).
  • Local times are converted with the full IANA time zone database (release 2026d). For dates before a zone adopted a standard time, the birthplace's local mean time (longitude / 15 hours) is used instead of the zone city's.
  • A local time in a daylight-saving gap is read with the offset in force before the change; a time that occurred twice is read as its first occurrence (it was the second).
  • Natal ayanamsa_value reports the true ayanamsa, the value actually used.
  • Arudha padas and the Upapada take the stronger co-lord of Scorpio (Mars or Ketu) and Aquarius (Saturn or Rahu), as Jagannatha Hora does, instead of always Mars and Saturn.
  • Rahu and Ketu graha drishti is the 7th house only; the graded 3rd/4th/5th aspects belong to the seven planets.
  • Avakahada paya is Rashi Paya: the Moon's house from the lagna.
  • Nakshatra names are spelled the same on every endpoint: Dhanishta and Mula (panchanga, muhurta and the Avakahada block said Dhanishtha; dosha details said Moola). The nakshatra details endpoint accepts either.

Fixed

  • Chaitra to Ashadha festivals came out a lunar month late, and Bhai Dooj and Dev Uthani Ekadashi a month late; Dhanteras, Diwali, Dussehra and Ganesh Chaturthi a day late.
  • A tithi that no sunrise touches was missing from the calendar.
  • Muhurta returned marriage windows in Chaturmas and on Pushya, Tuesday or a Krishna Rikta tithi.
  • Sunrise, sunset, Rahu Kaal, Choghadiya and hora times were about a minute early (Julian Days read as Terrestrial Time); times now round to the minute.
  • Yamaganda used the wrong part of the day on Sunday to Thursday; Tamil Emagandam (the same period) now equals Yamagandam.
  • The sunrise chart for an unknown birth time used the previous day's sunrise in time zones west of UTC.
  • MCP: the monthly calendar tool now sends the timezone; the festival and Tamil tools take lat/lon/timezone like the others.
  • Sidereal positions from the natal, divisional, transit and matchmaking endpoints were off by the nutation in longitude (up to 19 arcseconds): the mean ayanamsa was subtracted from apparent positions. Near a sign, nakshatra or pada boundary this changed the result, and those endpoints could disagree with panchanga, muhurta, KP, Sade Sati, Shadbala and Varshaphal, which were already right. Varshaphal solar return times move by a few minutes.
  • Dates from 2038 in time zones with daylight saving had the wrong offset for half the year, and some dates before 1901 had the wrong historical offset (a day for Manila before 1845).
  • The sunrise chart for an unknown birth time was up to a minute before sunrise.
  • Rashi drishti: Capricorn aspected Aquarius but not the reverse; adjacent signs never aspect each other.
  • Nakshatra details for Dhanishta returned empty activities and body_map.

SDKs and MCP

  • Python SDK 0.3.0 / 0.3.1 and TypeScript SDK 0.3.0 / 0.3.1 carry these changes. 0.3.0 gives typed responses to 45 operations that returned untyped data (TypeScript unknown): the horoscope, KP, Lal Kitab, Varshaphal, matchmaking, numerology and Prashna functions among them, with 208 more exported TypeScript types. 0.3.1 adds utc_offset, birth_moment and true_value_decimal. No function was removed.

Website

  • asterwise.com serves a Markdown version of every page to clients whose Accept header prefers text/markdown, for agents. Browsers keep getting HTML.
  • Agent discovery: Content-Signal in robots.txt, an API catalog at /.well-known/api-catalog (RFC 9727) advertised in a Link header on every response, /auth.md on how agents get credentials, and an agent-skills index at /.well-known/agent-skills/index.json.

2026-09-18​

Fixed

  • Thirumana Porutham: the summary reports 12 poruthams (the 10 standard plus Nadi and Varna), matching the detailed results.

2026-09-16​

Added

  • POST /v1/astro/matchmaking lists each partner's Mangal dosha cancellation rules beside the verdict.

Changed

  • Matchmaking uses the same Mangal dosha cancellation rules and severity tiers as the dosha endpoint. Severity is also reported when the dosha is seen from the Moon or Venus.
  • The Mangal dosha description distinguishes three states: Mars outside the dosha houses; in them but cancelled, naming the rule; and present.
  • The asterwise_get_compatibility MCP tool documents the severity tiers and per-partner cancellations.

2026-09-14​

Added

  • POST /v1/astro/yoga: each yoga carries classical_sources, the classical text it is drawn from and, where unambiguous, the section (for example Brihat Parashara Hora Shastra / Chandra yogas). Yogas from general tradition return an empty list. Neecha Bhanga Raja Yoga gains a formation text.
  • The asterwise_get_yogas MCP tool describes classical_sources.

2026-09-08​

Changed

  • Dashboard sign-in sessions are kept in a secure, HTTP-only cookie set by api.asterwise.com. Nothing to do: existing sessions carry on, and API keys and scripts keep using the Authorization header. Signing out clears the cookie.

2026-09-07​

Added

  • MCP: python stdio.py runs the server over stdio with ASTERWISE_API_KEY from the environment, for Claude Desktop local configs and hosted builds.
  • MCP: the tool catalogue is readable without signing in. initialize, ping, tools/list, prompts/list and resources/list work anonymously; tool calls still need OAuth or an API key.

Changed

  • Connected AI apps (MCP OAuth): every authorization is an independent connection with its own API key, so Claude, Cursor, ChatGPT and other apps can be connected side by side and reconnected one at a time. Disconnecting an app from the dashboard, or revoking its token, ends that connection as a whole, and the app asks you to connect again.
  • Connected apps are counted separately from your own API keys, up to 25 per account, and do not count toward your plan's key limit.
  • Apps whose Client ID Metadata Document offers several token-endpoint methods, ChatGPT's among them, can connect as public PKCE clients.
  • MCP tool descriptions match their schemas: asterwise_get_crystal and asterwise_get_dream_symbol describe name as a slug, no required parameter advertises a default, and response_format is optional in every tool.

2026-09-06​

Added

  • MCP OAuth supports Client ID Metadata Documents and public PKCE-only clients. Apps that identify themselves with an HTTPS URL pointing at a metadata document (Claude.ai, Claude Code, VS Code, Smithery) connect without a client secret: the document's redirect URIs are enforced, PKCE S256 is required, and loopback redirect URIs match on any port (RFC 8252). The consent page shows the host that published the document. See MCP setup.
  • A public Postman collection, linked from the docs and the SDK READMEs.

Changed

  • POST /v1/oauth/token and POST /v1/oauth/revoke accept application/x-www-form-urlencoded bodies (RFC 6749) as well as JSON.

2026-09-05​

Added

  • Accuracy: Asterwise tropical longitudes checked against NASA JPL Horizons for 80 positions between 1950 and 2050. Median difference 0.046 arcseconds; 79 of 80 within 0.5 arcseconds. Raw data and a reproduction script are published.

SDKs and MCP

  • Python SDK 0.2.4 and TypeScript SDK 0.2.4: MIT license file included and package metadata updated. No code changes.

2026-09-04​

Added

  • The OpenAPI document types ErrorResponse.error as the ErrorCode enum (all 52 codes), so generated clients know every code. Responses are unchanged.
  • MCP server card at https://mcp.asterwise.com/.well-known/mcp/server-card.json: public tool metadata for directories, built from the same registry as tools/list.
  • MCP: every tool parameter has a description in its input schema.
  • Docs: a reference page for every MCP tool, generated from the server.
  • Proof: sidereal and tropical positions, ascendant, ayanamsa and a panchanga for a reference birth, each beside an independent Swiss Ephemeris calculation, with the script.
  • CORS allows the X-API-Key and X-No-Cache request headers from browsers.
  • The MCP server source is public at github.com/asterwise/asterwise-mcp (MIT).

Changed

  • Daily, weekly, monthly and yearly horoscopes are computed from the sky at local sunrise on the first day of the period (central India).
  • When a new period's horoscope has not been generated yet (just after IST midnight, the 1st, or 1 January), the horoscope endpoints return the previous period's text with its period_key, instead of 404.
  • MCP tool descriptions are shorter: tools/list is 224 KB (was 406 KB), and each description links to the tool's docs page for the full text. Tool names, schemas and required fields are unchanged.
  • MCP tool responses are smaller: a repeated interpretation passage is replaced with a pointer to its first copy, and the dasha tool leaves per-period essays out of the tree (the current period's interpretation stays) and defaults to 2 levels (was 3). A two-level dasha answer goes from about 150 KB to 27 KB of JSON.
  • MCP: Authorization: Bearer <api key> works alongside X-API-Key.

Fixed

  • POST /v1/astro/panchanga without a time reports the vara (weekday) of the requested date.

2026-09-01​

Added

  • Error codes dependency_unavailable (503: a service the calculation needs is unavailable; retry) and solar_day_out_of_range (422: the instant falls outside the solar day at that location, or the day/night span cannot be computed). 52 codes in all; the SDKs carry the same list. dependency_unavailable was retired on 2026-10-04 (see that entry).

Changed

  • Every error's doc_url is the canonical form with a trailing slash. The form without a slash redirects (308).
  • A request body that is not valid UTF-8 JSON returns 400 validation_error with a parse message (was internal_error).
  • Monthly horoscopes are published at the start of the 1st (IST).
  • MCP: every tool has a title and openWorldHint: false, as the OpenAI Apps directory expects.

2026-08-27​

Changed

  • Resetting your password ends every connected AI app's access (MCP OAuth grants). Reconnect the apps to continue.

2026-08-01​

Added

  • Shadbala (POST /v1/astro/strength): Kaala Bala includes Abda Bala (15 virupas) and Masa Bala (30 virupas), per BPHS Ch. 27, in Savana time counted from the Kali Yuga epoch, as Jagannatha Hora does. Kaala Bala rises by 45 virupas per chart, so planet rankings can change.
  • Varshaphal: all five Pancha Vargeeya Bala components are scored (Kshetra, Uchcha, Hadda, Dreshkana, Navamsa) out of 80 virupas, with Tajika Hadda and Dreshkana tables and Tajika Panchadha Maitri.
  • Varshaphal response: election_fallback, moon_election and tajika_aspect_houses_matched name the rule that elected the Varsha Pati. They replace election_used_strongest_without_aspect.
  • GET /v1/astro/panchanga/hora names the hora convention used.

Changed

  • Varsha Pati election follows the classical rule: a whole-sign aspect to the Varsha Lagna qualifies a candidate (no planetary orb), Muntha Pati takes the office when no candidate aspects, and the Moon is excluded except in the two classical cases. The elected planet changes for some charts.
  • Every day-based calculation shares one solar-day model: real sunrise, sunset, apparent noon and midnight at the place. This covers Shadbala's Vara, Hora, Nathonnatha and Tribhaga Bala, Varshaphal day and night and its year lord, the KP ruling planets day lord, and the panchanga vara. Shadbala and Varshaphal results can change for some charts.
  • GET /v1/astro/panchanga/hora uses the unequal seasonal division (12 horas of day, 12 of night), the panchanga-table convention. Shadbala keeps the equal 24 divisions of B.V. Raman.

Fixed

  • Muhurta: night windows after midnight are dated to the following civil day, so their tithi, nakshatra, yoga and vara, and the Sarvartha Siddha and Amrita Siddha Yoga flags, are evaluated at the right instant.
  • Muhurta and Varshaphal at latitudes where the Sun does not rise or set return a 422 error.

2026-07-25​

Added

  • Divisional chart responses include an ascendant object for each varga, alongside planet placements. Omitted when birth time is not supplied.

Changed

  • Vedic birth input accepts requests without a time field. When omitted, a sunrise chart is used and birth_time_provided returns false. Passing "00:00" is treated as a midnight birth, not an unknown time.
  • MCP BirthData.time is optional. Omitting it sends no time key upstream.

Fixed

  • Western natal and return responses set birth_time_provided from whether time was supplied. It previously always returned true.
  • OAuth authorization code exchange no longer fails with Authorization code already used when a client retries the token request. Unknown codes now return the same message as already-used codes.

2026-07-16​

Fixed

  • Payment method update returns a payment link during the grace period.
  • Subscription cancellation returns an error when the processor call fails, instead of reporting success.

2026-07-09​

Changed

  • Paid plan prices and monthly quotas: Builder $10 / 10,000 calls, Launch $30 / 50,000, Scale $100 / 300,000. Sandbox unchanged at 500.
  • Upgrades are prorated. Downgrades are rejected.
  • Subscription payloads on GET /v1/account and GET /v1/billing/dodo/subscription include sku_id, billing_interval and pending_plan_change.

2026-07-02​

Added

  • GET /v1/account/signing-secret and POST /v1/account/signing-secret/rotate for per-account response signing.
  • Email and password registration returns a one-time sandbox api_key and mints a key named Sandbox.
  • Key list and summary responses include key_prefix.
  • Annual billing: Builder $100/yr, Launch $300/yr, Scale $1,000/yr. The monthly quota is unchanged; only the billing interval differs.

Changed

  • Responses are signed with the account signing secret when one exists. Callers verifying against the global signing secret should switch to the per-account secret.
  • Monthly quota counts only calls returning 2xx. Failed calls and over-limit rejections are not counted. Cache hits are counted.
  • GET /v1/account usage counts the UTC calendar month, matching what rate limiting enforces.
  • On a Redis outage, paid tiers continue to serve. Sandbox returns MONTHLY_USAGE_LIMIT_EXCEEDED.
  • Active API key caps are per tier rather than a flat limit.
  • Dodo payment history returns payments across subscriptions, up to 50.
  • Subscribe and upgrade use Dodo checkout sessions.

2026-06-18​

Added

  • PATCH /v1/account updates full_name. GET /v1/account returns it.
  • CORS allows PATCH and PUT for browser clients.

2026-06-04​

Changed

  • Exceeding the per-account API key cap returns MAX_KEYS_EXCEEDED (409). It previously returned a validation error.

2026-05 — May​

The largest expansion of the endpoint surface. Western astrology, tarot, crystals, dreams and angel numbers were added, and the error contract was standardised.

Added

  • Western astrology: moon phase, moon calendar, aspects, daily/weekly/monthly transits, synastry, composite, compatibility, zodiac compatibility, solar, lunar and planetary returns, secondary progressions, solar arc.
  • Western horoscope: GET /v1/western/horoscope/{daily|weekly|monthly|yearly}/{sun_sign}.
  • Numerology: expression, soul-urge, personality, maturity, balance, karmic-lessons, personal-cycles.
  • Tarot: card catalogue, card by id, major arcana, suit, card of the day, draw, three-card, Celtic Cross, yes/no.
  • Crystals: GET /v1/crystals, /crystals/{name}, /crystals/by-planet; POST /v1/crystals/recommend, /crystals/recommend/natal.
  • Angel numbers: GET /v1/numerology/angel, /angel/today, /angel/{number}; POST /v1/numerology/angel/personal.
  • Dreams: GET /v1/dreams/symbols, /dreams/symbol/{name}.
  • Vedic: GET /v1/astro/planet-nature, /puja-suggestions, /rudraksha, /ayanamsha; POST /v1/astro/nakshatra/prediction, /pitra-dosha, /ghat-chakra, /varshaphal/saham, /varshaphal/harsha-bala; GET /v1/astro/panchanga/tamil, /panchanga/festivals.
  • POST /v1/western/biorhythm, moved from /v1/astro/biorhythm.
  • Sade Sati responses include Small Panoti (Dhaiya).
  • Rate-limit responses include the Retry-After header.
  • MCP server reaches 103 tools.
  • Python and TypeScript SDKs 0.2.0 and 0.2.1.

Changed

  • Error responses use the 8-field canonical envelope: success (always false), error, message, details, retry_after, doc_url, request_id, timestamp. Unmatched routes and oversized bodies use it too. (Corrected 2026-10-07: this entry listed status_code instead of success; the envelope has always had success.)
  • birth_time_unknown is replaced by birth_time_provided on natal and related chart responses. The polarity is inverted. Dropped from panchanga.
  • Auth failures distinguish API_KEY_MISSING, API_KEY_INVALID, API_KEY_NOT_FOUND and API_KEY_REVOKED.
  • Pitru dosha bphs_combinations_triggered and bphs_combinations_count are renamed to combinations_triggered and combinations_count.
  • MCP asterwise_get_divisional_chart makes chart_type optional. Omit it for all sixteen vargas.
  • Mangal Dosha detection uses D1 only. The D9 check was removed.
  • Gana Koota Deva plus Manushya scores 6, previously 5.
  • POST /v1/astro/kp/ruling-planets rejects out-of-range lat and lon with a validation error instead of a 500.

Fixed

  • POST /v1/astro/divisional returns only the requested chart when chart_type is set.
  • Western return charts use conjunction separation, not opposition.
  • Panchanga nakshatra and yoga end times no longer double-subtract ayanamsa.
  • Char Dasha start rashi, Savya and Apasavya sets, Aquarius secondary lord and period years return corrected values.
  • KP ruling planets are de-duplicated.
  • Numerology master-number interpretations and personal_year validation accept inputs that previously failed.

2026-04 — April​

OAuth, the MCP server, the SDKs, and a change of payment processor. Several calculation engines were corrected, which changed returned values.

Added

  • OAuth 2.1 on the API: authorize, token, revoke, refresh, POST /v1/oauth/register, GET /v1/oauth/client-info, /connections, DELETE /v1/oauth/connections/{token_id}.
  • MCP server with 52 tools, OAuth 2.1 and streamable HTTP, including discovery metadata and WWW-Authenticate on unauthenticated requests.
  • POST /v1/western/natal.
  • GET /openapi-sdk.json for SDK generation.
  • Python and TypeScript asterwise SDKs on PyPI and npm.
  • Dodo billing under /v1/billing/dodo/: subscribe, webhook, subscription, cancel, and GET /v1/billing/dodo/payments.
  • Strength responses include bhavbala across twelve houses.
  • Varshaphal responses include muntha_lord and Tajika planet-pair aspects.
  • Natal responses include house_system_note and Bhavesh Phala interpretations where applicable.

Changed

  • Birth-data endpoints require BirthInput with date, time, latitude, longitude, timezone and name. date_of_birth and time_of_birth are rejected.
  • Numerology requests use name and date instead of full_name and birth_date.
  • Tier growth is renamed to launch across schemas, SKUs and stored tiers.
  • Sandbox monthly quota is 500, reduced from 2,000.
  • Burst limits: sandbox 10/min, builder 60, launch 200, scale 500.
  • Razorpay billing routes are removed. Dodo is the payment processor.
  • Account billing-details endpoints are removed.
  • Paid plan quotas and prices: Builder 15,000 / $39, Launch 60,000 / $99, Scale 300,000 / $249.
  • MCP report tools are removed: asterwise_generate_kundli_report, asterwise_generate_dasha_report, asterwise_generate_matchmaking_report, asterwise_generate_varshaphal_report.
  • Report endpoints POST /v1/report/kundli, /matchmaking, /dasha, /varshaphal are removed from the public API.
  • API auth accepts X-API-Key in addition to Authorization: Bearer.
  • bhava_madhya, bhava_sandhi and rashi_drishti return labeled objects rather than raw numeric arrays. Ashtakavarga, upapada and varshaphal ascendant fields use labeled or sign-keyed shapes.
  • Natal moon_sign and moon_nakshatra are always populated.
  • OAuth token and revoke accept form-urlencoded and JSON bodies.
  • MCP OAuth redirect URI validation allows the cursor:// scheme.

Fixed

  • Sign-dependent yogas that were silently skipped now appear in responses.
  • Sign-dependent dosha detection, including Mangal Dosha, runs with correct sign indices.
  • Dignity, combustion, Bhava Chalit, Graha Yuddha, Shadbala, yoga, dosha, matchmaking, transit, panchanga, KP, Prashna, Lal Kitab and gemstone outputs change where prior engine bugs applied.
  • Matchmaking field StreeDeerga uses a Latin a. A Cyrillic lookalike character was removed, which changes the JSON key.
  • Matchmaking Rajju group labels and descriptions return corrected values.
  • Yoga and dosha interpretation keys resolve instead of returning placeholders.
  • Unauthenticated callers no longer receive cached authenticated responses.

2026-03 — March​

Initial public release and the first build-out of the endpoint surface.

Added

  • API key management: POST /v1/keys, GET /v1/keys, DELETE /v1/keys/{key_id}, GET /v1/keys/usage, GET /v1/keys/me.
  • Account auth: magic link, register, login, Google, forgot and reset password, logout, session revoke, GET/DELETE /v1/account, POST /v1/account/onboard, GET /v1/account/export, /logs.
  • Account-scoped API key create, list, rotate and delete.
  • Vedic core: POST /v1/astro/natal, /dasha, /dosha, /yoga, /matchmaking, /strength, /transits, /divisional, /ashtakavarga, /yogini, /ashtottari, /sade-sati, /gochar, /chart.
  • Panchanga: POST /v1/astro/panchanga, /panchanga/choghadiya, /hora, /rahu-kaal; GET /v1/astro/panchanga/calendar.
  • Matchmaking variants: /matchmaking/dashakoot, /porutham, /thirumana-porutham, /papasamyam.
  • Timing and analysis: /muhurta, /char-dasha, /varshaphal, /dasha-transits, /atmakaraka, /ishta-devta, /remedies, /gemstones; GET /v1/astro/nakshatra/{name}.
  • KP: /kp/chart, /significators, /ruling-planets. Prashna: /prashna. Lal Kitab: /lal-kitab/chart, /remedies.
  • Numerology: profile, compatibility, life-path, personal-year, lucky-numbers, meaning, name-correction, chaldean, lo-shu, business-name, mobile-number, vehicle-number.
  • Horoscope: GET /v1/horoscope/{daily|weekly|monthly|yearly}/{moon_sign}.
  • Reports: POST /v1/report/kundli, /matchmaking, /dasha, /varshaphal.
  • Utilities: GET /v1/utils/geocode, /timezone.
  • Billing: order, verify, webhook, subscription, cancel, reactivate, add-on purchase, subscription-status polling.
  • ayanamsa=tropical on birth-data endpoints.
  • include_interpretation on POST /v1/astro/natal.
  • Natal responses include Avakahada Chakra fields.
  • Matchmaking responses include Mangal Dosha, classical vetoes, Stree Deergha and narrative fields.
  • Astrology endpoints accept an omitted birth time, using a sunrise chart.

Changed

  • Tier free is removed. Sandbox is the free path.
  • CreateKeyRequest no longer accepts monthly_limit. The limit comes from the tier.
  • POST /v1/billing/upgrade is removed. Upgrade preview fields change and new_billing_date is dropped.
  • DELETE /v1/account requires a body of {"confirm": true}.
  • Billing and keys are account-scoped, with one subscription per account.
  • New API keys use an aw_ prefix.
  • POST /v1/keys returns HTTP 200.
  • Per-IP and per-key burst rate limits apply.
  • Expired subscriptions downgrade to sandbox.
  • Sandbox monthly quota is 2,000 at this point. Reduced to 500 in April.
  • Disposable email addresses are rejected at signup.
  • Responses include the Asterwise-Version header.

Fixed

  • Auth and ownership checks on key endpoints reject cross-account access.
  • Ayanamsa selection is applied on panchanga and divisional routes.

Note on stability​

The v1 surface was built and reshaped between March and May 2026. Endpoint paths, field names, the error envelope, tier names, quotas and the payment processor all changed during that period. The contract reached its current shape on 2026-05-21 with the 8-field error envelope.

Integrations written before June 2026 should be checked against the current reference rather than earlier behaviour.

Reporting issues​

If the API behaves differently from what is documented here, email [email protected] with the X-Request-Id from the affected response.