Changelog

2026-09-05

New: /v1/firdaria and /v1/zodiacal-releasing complete the time lords

• /v1/firdaria walks the Persian 75-year sequence of nine major periods in the order set by sect (Sun first by day, Moon first by night), each planetary major split into seven equal sub-periods in the Chaldean order from the major lord, the node majors undivided; the cycle repeats after 75 years. day_chart overrides the sect, night_order=nodes_after_mars selects the medieval placement of the nodes, year_days the year. 1 credit.
• /v1/zodiacal-releasing walks the signs from a lot's sign (Spirit by default, from for Fortune or another point), each lasting its planetary years of 360 days, at up to four levels (max_level), each level restarting from its parent's sign with the loosing of the bond at unit 211; every record carries its sign, lord, angle_from_fortune (1, 4, 7, or 10, the peak) and loosing_of_bond. Range caps shrink with depth: 120 years at levels 1–2, 10 years at 3, one year at 4. 2 credits.
• Both take at or start/end like /v1/profections and emit the same flat, level-tagged records, so one renderer draws all three tracks. See Time Lords and the guide.
• Test depth. Every firdaria record over eighty years, by day and by night and in both node orders, is regenerated from the table and the birth instant and checked both ways: each response record is an expected one, and each expected one appears exactly once; the sect is held to /v1/lots; the tropical and sidereal responses are shown identical. Every releasing record at every level is regenerated from the two lot signs taken from /v1/lots by the walk, the twelvefold nesting, and the loosing rule, and checked both ways; angularity is recomputed from Fortune's sign; a chart without a Lot of Fortune yields no angular period and a warning saying why.
• MCP: calculate_firdaria and calculate_zodiacal_releasing (@morphemeris/mcp 0.15.0).

2026-09-05

New: /v1/profections, the first time-lord endpoint

• /v1/profections computes annual and monthly profections of a natal chart: at age n the profected sign is n signs past the Ascendant's, whole-sign whatever the natal house system, that count is the house, and the sign's domicile ruler is the lord of the year; months step one sign further each. Ask for one instant (at) to get the year and month in force with their lords, or a range (start/end, up to 120 years) for every period overlapping it as flat records ordered by start then level, with clamped_start/clamped_end marking records the range cut. from starts the count from the Midheaven, a body, or a Hermetic lot; months and year_days shape the default mean-year boundaries; solar=true anchors each year to the real solar return and each month to the Sun's 30° ingress, searched in the chart's own zodiac, so a sidereal chart's year turns at the sidereal return. 1 credit, 2 with solar=true; batchable. Powered by astrologica v0.13.0's timelords module (astrologica#88); firdaria and zodiacal releasing share its record vocabulary and follow. See Time Lords and the guide.
• Test depth. Every record at three starting points (Ascendant, Moon, Lot of Fortune), tropical and sidereal, is recomputed from the API's own houses, positions, and lots by the whole-sign count with the classical domicile rulers. Mean boundaries are held to the arithmetic to 1e-6 day. Solar-anchored years are held to /v1/returns to 1e-4 day, and each month's start is taken back to /v1/positions to check the Sun sits exactly 30° further on, in both zodiacs. The two boundary rules are shown to agree on every house and lord within four days of each other.
• MCP: calculate_profections (@morphemeris/mcp 0.14.0).

2026-09-04

Engine: swephrs v0.20.0 and astrologica v0.12.0

• Transit scans cover a year. /v1/transits accepts ranges up to 366 days (183 with moon=include), up from 62 (14). The engine now samples each moving body once and reuses it across targets and aspects (astrologica#77), so a default year takes a few seconds on the Worker. The engine also keeps only the conjunction of the lunar-return pair under moon=returns_only (astrologica#78); the API's own filter for that is gone.
• The seven Hermetic lots. /v1/lots, and lots=default on /v1/midpoints and the chart endpoints, now compute the lots of Paulus Alexandrinus: Fortune, Spirit, Eros, Necessity, Courage, Victory, Nemesis (astrologica#80). The five ASC + planet − Sun lots (Love, Commerce, Passion, Increase, Fate) are gone, so the default lot names in every response change. A lot's formula may name a lot operand (part_of_spirit), and a filtered request brings the lot a selected lot is built on along. Breaking for anyone reading lot names.
• All 47 ayanamshas compute. The twelve star-anchored systems (true_citra, true_pushya, the galactic-centre family, ...) were refused with 400; swephrs v0.20.0 implements them and the C-parity suite holds every one to the Swiss Ephemeris's own value. Six systems were catalogued under misattributed names and are renamed: galcent_mss → galcent_0sag, galcent_ryan_cottrel → galcent_gil_brand, skydram_mathers → skydram_mardyks, true_shell_ayanamsha → true_sheoran, gal_cent_cochrane → galcent_cochrane, veda_web_mueller → valens_moon. The old spellings still parse and answer with the new name in system; display names change for those six. See Ayanamshas.
• BCE dates work. Every BCE year not itself a multiple of 600 failed with a computation error because the engine picked the wrong data file (swephrs#109); fixed. The supported range is now stated from the data files' own headers rather than their names: 3 May 12999 BCE (-012999-05-03T00:00:00Z) to 23 December 16799 CE, and a date outside it returns 400 invalid_datetime with that range.
• Osculating apogee in sidereal mode. Its sidereal longitude carried a nutation term no other body did (swephrs#111); fixed, up to 17 arcseconds. Its speed, and the true node's, also move by up to 4.6e-4°/day under equatorial=true (rotated velocities, as the C library). The aspects test suite no longer excludes it.
• Draconic charts carry their patterns and derived points from the engine's own rotation (astrologica#79); the response is unchanged.
• Fixed stars are Swiss Ephemeris values throughout. Through swephrs v0.19.0 the star pipeline built the Earth from a Moshier series whatever the ephemeris, so /v1/stars returned the C library's SEFLG_MOSEPH star positions. It now uses the Swiss Ephemeris Earth like every other body and matches C's SEFLG_SWIEPH output to 1e-12°; the two differ by up to 8e-6° in longitude and 8e-9 in relative distance (the barycentric Earth in the annual aberration and observer position). The C-parity fixture is regenerated from the Swiss-context run, the star-based ayanamshas included (swephrs#136).

2026-09-03

New: essential dignities on the chart endpoints

• dignities=true on /v1/natal-chart, /v1/synastry (both charts), /v1/davison, /v1/progressed, and /v1/returns (every return chart) attaches a dignities array — one dignity record per body — at no extra credit cost, like patterns and derived_points. rulership chooses the scheme. The sect is read from the chart itself: the Sun on or above the horizon is a day chart, so the triplicity ruler is always assessed, which /v1/dignities (no location) can only do when told day_chart; day_chart still overrides. /v1/draconic refuses the flag: dignities belong to the signs, and draconic longitudes are rotated out of them. The spec had promised dignities in the chart since the start (#140).

Fixed: essential dignities use traditional rulership by default

• /v1/dignities documented rulership as defaulting to traditional and defaulted to modern, so by default Mars in Scorpio was peregrine, Saturn in Aquarius in detriment, and dispositor chains ran through Pluto, Uranus, and Neptune. The default is now traditional, as the spec and the technique require; pass rulership=modern for the outer-planet rulers. traditional and classical are both accepted.

Test depth: rule-based invariants

• The classical tables are now held to their sources. Every dignity record at sixteen instants across a century, by day and by night, under both rulerships and in the sidereal zodiac, is recomputed from Ptolemy's rulers and exaltations with Lilly's degrees, Lilly's triplicity rulers, the Egyptian terms as Ptolemy gives them, the Chaldean faces, and Lilly's scores; dispositor chains, mutual receptions, and final dispositors are recomputed from the rulers. Every lot is recomputed from the Ascendant and the positions with the sect taken from the Sun's altitude, its house from the cusps, and the sidereal lot from the tropical one. Aspects are recomputed from positions with the documented default orbs, and under a flat orb every pair within it is shown to be reported exactly once for all fifteen types; parallels and contraparallels likewise from declinations. Midpoint trees are recomputed from the response's own midpoints on the 360°, 90°, and 45° dials. Patterns at eight instants are recomputed from the response's own aspect list by the documented definitions, with focal body, member aspects, and tightness, in all three stellium scopes. Astrocartography angle lines are checked point by point — the local sidereal time equals the body's right ascension on MC and IC lines, its altitude is zero on Ascendant and Descendant lines, and horizon lines end as circumpolar exactly where the body stops rising — and cusp lines, zodiacal and mundane, are checked at sampled points against /v1/houses and the chart's own mundane house position.
• Known engine issue found by these tests: the sidereal longitude of the osculating apogee (osc_apogee) is not the tropical longitude minus the ayanamsha but differs from it by a few arcseconds that vary with the date, so an aspect between it and another body changes by up to 0.004° between zodiacs. Every other body is exact. Tracked as swephrs#111.

Docs: what the API returns, as it returns it

• The seven lots /v1/lots computes were called "the 7 Hermetic lots". Fortune and Spirit are; the other five (Love, Commerce, Passion, Increase, Fate) pair a planet against the Sun and are not the Hermetic lots of Paulus Alexandrinus, which take Fortune or Spirit as a term. The docs now say what they are; the Hermetic set is an upstream request (astrologica#80). The name field is the full name (Part of Fortune), not the keyword.
• The dignities reference described a response with dignity/debility strings and a single final_dispositor; it now shows the actual record (a ruler and an in_… flag for each of the five dignities, peregrine, score) and the actual dispositor chains, and names the tables the API uses.
• applying and parallels were documented as opt-in with default false on the aspects, natal-chart, and synastry references; they have always defaulted to true, as the OpenAPI document and llms-full.txt said. The references now agree.

Fixed: draconic charts carry their aspects and parallels

• /v1/draconic returned aspects: [] and parallels: [] in every response while the docs said the rotation preserves them. It does — a uniform rotation preserves every separation, and declination is not rotated at all — so the response now carries the natal chart's aspects, recomputed from the rotated longitudes, and its parallels. patterns=true on a draconic chart, which had no aspects to work from, now finds the natal patterns.
• chart_type on /v1/davison and /v1/progressed responses said natal; it now says davison and progressed, as metadata.source already did.

Test depth: derived-chart invariants

• Each derived chart is now held to its definition against the API's own natal charts, positions, and houses. Every draconic longitude, cusp, and angle is the natal one turned by the node (tropical and sidereal, mean and true node) with houses, aspects, and parallels unchanged. Every composite midpoint lies on the shorter arc, equidistant from its two natal sources, cusps included, whichever birth is _a and whatever the tie-break. The Davison chart is exactly the chart cast at the mean of the two instants and the great-circle midpoint of the two places (across the date line too), and it is the composite's instant. The progressed chart is exactly the chart cast at birth plus one day per 365.25 days, so a year of life is one day and the birth instant returns the natal chart; a target before birth is refused. Synastry's two charts are the natal charts; every inter-aspect's angle, orb, and applying flag follow from the two longitudes and daily motions; under a flat orb every pair within it is reported exactly once; parallels and contraparallels follow from the declinations; and swapping the births mirrors everything.

Docs: the chart response as it is

• The natal chart reference described a response the API has never sent — bodies[].name, houses.mc, a dignities[] array, rulership and day_chart parameters — and the derived-chart references inherited it. They now show the actual shape: positions[].body, a 13-slot houses.cusps, chart_type, and a typed metadata.source. Essential dignities are /v1/dignities. The composite reference now documents its own shape (midpoint_longitude with both sources, no place, no motion).

Fixed: ayanamsha values are signed

• /v1/ayanamsha and the ayanamsha field of sidereal position and chart responses reported an offset wrapped into 0–360°, so the J2000 ayanamsha in 1900 came back as 358.6° and every precession-based ayanamsha before its zero year (around 285 CE for Lahiri) as 359.x°. Values are now signed, on (−180°, 180°]: −1.39° and −0.5°. The C Swiss Ephemeris wraps too, except where its nutation term takes a near-zero value just below zero, so neither convention was one a consumer could rely on; the API now has one. Sidereal longitudes are unaffected. A sidereal request whose ayanamsha the engine cannot compute is now an error rather than a tropical chart under a sidereal label.

Test depth: C-library parity for the scalar endpoints

• House cusps and angles for 22 systems (every one the C fixtures cover) at five latitudes and five epochs, fixed-star positions for twelve stars at five epochs, the whole ayanamsha catalogue at three epochs, Greenwich sidereal time, and ΔT from 3000 BCE to 3000 CE are now held to the values of the C Swiss Ephemeris 2.10.03, carried as fixtures from the engine's own parity data. Agreement is 1e-8° or better except Sunshine cusps (milliarcseconds, from the Sun's declination) and stars in 1500 (four milliarcseconds).

Fixed: the semi-sextile and quincunx are computed by default, as documented

• Every aspect-using endpoint (/v1/aspects, the chart endpoints, /v1/void-of-course, patterns) documents a default set of seven aspects. The orb table the API built carried default orbs for the five Ptolemaic aspects only, and an aspect with no orb is skipped, so the semi-sextile and the quincunx never appeared by default, and aspects=semi_sextile without orb= returned nothing. Every aspect type now has its default orb (the values in the aspects reference, which also gains the correct orbs for the quintile pair and drops two aspects the API never had). Default aspect lists, yods, and void-of-course verdicts can change accordingly.
• last_aspect on /v1/void-of-course was documented as the most recent aspect the Moon completed; it is the last aspect the Moon will perfect before leaving its sign. The docs now say so.

Test depth: event-time oracles

• Eclipse maxima are checked to be a new or full Moon on the ecliptic; contacts and phases are checked for order and, for the global search, symmetry about the maximum; local solar eclipses must have the Sun up, local lunar ones the Moon up at some phase. Heliacal altitudes are recomputed at the reported instant. Sunrise and sunset in planetary hours are checked to be the Sun's upper limb on the horizon. Void-of-course verdicts are checked against a scan of the Moon's actual aspects up to its sign ingress. Solar-proximity separations and statuses are recomputed from positions. All of this runs through one batch call per scenario.

New: /v1/transits, a transit scan

• /v1/transits scans a date range for aspect windows: every period in which a moving body is within orb of an aspect to a natal chart's points (bodies plus Ascendant and Midheaven), or, with targets=mutual, to the other moving bodies. Each event carries the instant the pair came within orb, every exact contact inside the window (a retrograde loop that perfects three times is one event with three exacts), and the instant it left, with clamped_start/clamped_end marking windows cut by the range. 5 credits, up to 62 days per request, flat 1° orb by default. Every exact instant is verified in the test suite against an independent position lookup to better than 1e-6°.
• The Moon aspects every point monthly, so by default a scan longer than 14 days keeps only its return to natal moon and says so in warnings; moon=include (ranges up to 14 days) scans it fully, moon=exclude drops it.
• The endpoint takes no calculation flags: an aspect is a difference between two longitudes, and a zodiac rotation cancels out of it.
• Available in /v1/batch and as the MCP tool find_transits.

Engine update: swephrs 0.18.0 and astrologica 0.11.0

The calculation engine went through a four-day audit against the C Swiss Ephemeris, with parity fixtures for every family of functions. Most of what it found is invisible from the API — the numbers were already right — but four things were not, and this release carries their fixes.

• Planet ingresses are geocentric (fix #112). /v1/ingresses searched Mercury through Pluto on their heliocentric longitude, so Venus and Mars ingresses came back days to weeks from the moment any ephemeris table lists. Sun and Moon were unaffected. Ingress times for the planets computed before this date should be recomputed.

• Sidereal charts have sidereal house cusps (fix #113). With sidereal=…, every chart endpoint and /v1/houses returned sidereal planets against tropical cusps, placing roughly every body one house early. Cusps now shift by exactly the ayanamsha, the ARMC does not, and a body's house is the same in either zodiac.

• Return charts were about 69 seconds late. /v1/returns fed a UT1 instant to a search that works in Terrestrial Time and read the answer back as UT1, so every return was off by ΔT — a third of an arcminute of Moon. The return body now sits on its natal longitude to better than 0.0001°.

• Timestamps are real UTC. Every datetime in a response is now rendered from UT1 through the leap-second table (and parsed the same way), so the instant you send comes back to the millisecond and the 60th second of a leap day is representable. Previously the UT1 clock was labelled UTC, up to 0.9 s off. Sub-second precision is now shown everywhere (…T12:00:00.000Z).

• Dates. ISO 8601 expanded years (-000500-03-21T00:00:00Z, sign mandatory, astronomical numbering) are accepted. A date outside the ephemeris tables — before 1 January 13200 BCE or after 31 December 16799 CE — returns 400 invalid_datetime instead of a server error. Most BCE dates currently fail with a computation error because the engine picks the wrong data file for them (tracked upstream as swephrs#109); they returned a silent zero longitude before.

• /v1/houses accepts no_nutation, computing the cusps on the mean frame (mean sidereal time for the ARMC, mean obliquity) so they pair with no_nutation=true positions.

• Local lunar eclipses honor the observer. /v1/eclipses/lunar with lat/lon used to ignore the location entirely — visible was hard-coded and phases below the horizon were reported. The search now skips eclipses with no phase above the local horizon, returns null for phases that occur below it, and shifts the reported maximum to moonrise or moonset when the geocentric maximum is not visible, exactly as the C library does. Solar eclipse visibility at a location is corrected too, and hybrid (annular-total) searches, which converged on the same 2013 eclipse regardless of start date, now work.

• Refusals instead of wrong answers. The engine now reports every state it cannot honor as an error rather than a zeroed value, and the API maps them to 4xx: a star-based ayanamsha (true_citra, true_revati, the galactic-centre variants — twelve systems that used to return tropical positions silently) returns 400 invalid_parameter; acronychal_rising and acronychal_setting heliacal events, which the engine does not yet implement and used to answer from the wrong search, return 400 invalid_heliacal_event and are no longer listed; an eclipse observer altitude outside −500…25000 m returns 400; /v1/planetary-hours at a latitude where the Sun does not rise returns 400 invalid_parameter instead of 500.

• Values that move. Heliacal event times shift (a corrected Δt term at ancient epochs and the sunrise semidiameter correction at all epochs; the aerosol coefficient in the visibility model is corrected), Placidus cusps move by up to 18° in the last degree of latitude before the polar circle and fall back to Porphyrius (with a warning) exactly where the C library refuses, house angles at the Asc1/Asc2 seams (ARMC on a multiple of 90°, latitude equal to the obliquity or its complement) snap as C's do, sidereal longitude speeds subtract the ayanamsha rate, sidereal + no_nutation or j2000 longitudes move by about 0.005° (the ayanamsha now follows the frame), the four epoch-anchored ayanamshas (j2000, j1900, b1950, skydram_mardyks) are projections onto their epoch's ecliptic rather than subtractions (latitudes change too), and astrocartography's cusp lines inside the polar circles come from Porphyrius, as the API's charts there already did.

• Chart responses carry a warnings array (omitted when empty) alongside the top-level warnings; both list the same conditions, the chart's in typed form (kind plus details), the top level as prose. Top-level warning strings are now sentences (high latitude (80°): Placidus not supported, fell back to Porphyrius) rather than debug output.

Catalogue honesty

• The ayanamsha catalogue is generated from the parser's own table. The three published lists (OpenAPI, llms-full.txt, these docs) and the MCP server disagreed with each other and with the API from number 17 onward, and all four advertised the twelve star-anchored systems the engine refuses. The catalogue now lists the 35 systems a request can use, by the name the API accepts, and GET /v1/ayanamsha?system=all returns exactly that set; a test holds the OpenAPI enum to it.
• /v1/ayanamsha responses name the system by the name a request accepts. system is now lahiri rather than the display name Lahiri, which moves to a new name field, so a value you read can be sent straight back. data is always an array, as it always was; the docs and OpenAPI example said otherwise for a single system.
• house_system reports the system that produced the cusps. Inside the polar circle Placidus and Koch have no solution and the engine computes the whole chart with Porphyrius. /v1/houses system and every chart's metadata.house_system now say Porphyrius there, with the high_latitude warning still explaining why; they used to echo the request.
• MCP 0.12.0 ships the corrected ayanamsha catalogue in list_available_values.

Breaking: a calculation flag an endpoint does not implement is now rejected

• Passing sidereal, equatorial, speed, no_nutation, j2000, topocentric, or heliocentric to an endpoint that does not implement it returns 400 invalid_parameter naming the flag, instead of being accepted and discarded. A dropped flag answers in a different frame than you asked for and nothing in the response says so, which is how two frame bugs shipped unnoticed. See Calculation flags for which endpoints take which.
• /v1/positions and /v1/chart accept all seven. The chart endpoints accept all but speed — they always compute daily motion, because retrograde markers and applying aspects depend on it. /v1/houses accepts only sidereal. Every other endpoint accepts none. Batch sub-requests follow the same rule.
• MCP 0.11.0 drops equatorial from get_fixed_stars: /v1/stars never implemented it, so the tool was advertising a coordinate system it could not return.

2026-08-24

New endpoints: Aspect Patterns, Midpoints & Derived Points, Astrocartography

• /v1/astrocartography — Where on Earth each body is on the MC, IC, Ascendant, or Descendant, and — the generalization — on any house-cusp value in any house system, as line geometry with a termination reason per segment (5 credits). Zodiacal or mundane mode. New concept page: Astrocartography.

• /v1/midpoints — Midpoints of every body pair, antiscia and contra-antiscia, optional Arabic lots, and optional Cosmobiology midpoint trees on a 360°/90°/45° dial (1 credit). derived_points=true on the six chart endpoints populates the chart's derived_points array at no extra cost.

• /v1/patterns — Detect T-squares, grand trines, grand crosses, yods, kites, mystic rectangles, and stellia for a set of bodies at a moment, together with the aspect list they were assembled from (1 credit). Patterns use only the aspect types the request detected, and the response warns when a requested pattern cannot form from the aspect set.

• patterns=true on /v1/natal-chart, /v1/synastry, /v1/davison, /v1/progressed, /v1/draconic, and /v1/returns populates the chart's patterns array at no extra cost. pattern_types, stellium_min, and stellium_scope tune it.

• New concept page: Aspect Patterns.

• MCP: new calculate_patterns, calculate_midpoints, and calculate_astrocartography tools; the six chart tools accept patterns and derived_points.

Fix: composite resolution parameter

• /v1/composite's resolution was documented as nearest/far, but composite midpoints are always the shortest-arc midpoint — a "far" mode never existed, and resolution=far silently behaved like the default. The parameter is now documented and validated as what it always was: lower (default) or higher, the tie-break for bodies exactly 180° apart, identical to /v1/midpoints. Unknown values now return invalid_parameter instead of being ignored.

New: mundane house positions (house_position_mode)

• house_position_mode=mundane on /v1/natal-chart, /v1/chart, /v1/synastry, /v1/davison, /v1/progressed, and /v1/returns places each body on the house system's actual cusp surfaces using its ecliptic latitude (the Swiss Ephemeris swe_house_pos algorithm), adds a fractional house_position in [1, 13) to every body, and re-derives house as its floor. No extra credit cost. See Zodiacal vs. mundane house positions.
• Mundane placement requires geocentric tropical ecliptic coordinates; /v1/draconic rejects the mode (its longitudes are rotated — draconic house placements equal the natal chart's).
• Engine: astrologica 0.6.0. The upgrade also lifts the last astrocartography restriction — sripati and equal_mc house-cusp lines now work.
• MCP 0.10.0: the chart tools accept house_position_mode.

Engine update: swephrs 0.5.1 and astrologica 0.5.0

• Corrected house systems. pullen_sd and pullen_sr had been returning the wrong systems (Savard-A and Pullen sinusoidal delta respectively) because of a mislabel in the underlying library. They now return what their names say, and Savard-A is available on its own as savard_a (code J). Cusps computed with either Pullen system before this date should be recomputed. See House Systems.
• House-system codes now match the Swiss Ephemeris exactly. pullen_sr is Q (the previously accepted N is no longer valid) and sripati is S. meridian is accepted as an alias of axial_rotation. The documented list is reconciled with what the API actually accepts: 23 systems.
• max_orb on aspect and parallel records. Every aspect and parallel record now carries the orb limit that admitted it (after per-body overrides), so orb / max_orb gives tightness on a 0–1 scale without a second copy of the orb table. Affects /v1/aspects, /v1/natal-chart, /v1/synastry, /v1/composite, /v1/davison, /v1/progressed, /v1/draconic, and /v1/returns.
• Reserved chart fields. Chart responses carry patterns and derived_points, both currently empty arrays. Aspect-pattern detection (T-squares, grand trines, yods, …) and derived points (midpoints, antiscia, lots) are planned features and will populate them.
• Fixed-star speeds refined. ra_speed and dec_speed on /v1/stars now include the precession-drift and nutation-rate terms; values move by a few 10⁻⁵ °/day. The new values are validated against the C library's own position derivatives.
• Polar-latitude fallback threshold. For Placidus, Koch, and the other quadrant systems that are undefined inside the polar circles, the latitude at which the API falls back to Porphyrius (and reports a warning) now follows the C library's |φ| ≥ 90° − ε boundary (≈66.56°) rather than a fixed 66.0°.

2026-04-01

New endpoints: Eclipses, Heliacal Events, Sign Ingresses

• /v1/eclipses/solar — Solar eclipse search, global or at a specific location, with magnitude, obscuration, and contact times (3 credits)
• /v1/eclipses/lunar — Lunar eclipse search with penumbral, partial, and total phase timing (2 credits)
• /v1/heliacal — Heliacal rising and setting of planets using the Schaefer sky brightness model, with configurable atmospheric and observer parameters (3 credits)
• /v1/ingresses — Find when a planet crosses a zodiac sign boundary or any ecliptic longitude, with multi-result and backward search (2 credits)

All new endpoints support count (1–10) for multiple results and backward for reverse-time search.

New documentation: Credits & Pricing concept page, concept pages for Eclipses, Heliacal Events, and Ingresses, plus practical guides for finding eclipses, heliacal events, and tracking ingresses.

2026-03-15

Initial release

• 7 endpoints: positions, houses, chart, stars, ayanamsha, delta-t, sidereal-time
• Support for all planets (Sun–Pluto), lunar nodes, and 6 asteroids
• 22 house systems
• 47 ayanamsha systems
• Fixed star catalog from Swiss Ephemeris
• Extended date range: 13,000 BCE to 16,800 CE
• Free tier: 500 requests/month
• Paid credits: $0.01/request
• Sub-arcsecond accuracy via Swiss Ephemeris data files
• Global edge deployment on Cloudflare Workers