Tropical calculation API

Western Astrology API for Developers

Yes—Cosmic Ephemeris supports a documented Western astrology calculation workflow. Bundled JPL DE421 ephemeris data drives deterministic apparent geocentric planetary positions. Tropical zodiac output is the default, with birth charts, equal and whole-sign houses, aspects, synastry, and natal-to-transit comparisons returned as structured JSON.

What the Western astrology API includes

Cosmic Ephemeris calculates apparent geocentric ecliptic longitude for the Sun, Moon, Mercury, Venus, Mars, Jupiter, Saturn, Uranus, Neptune, and Pluto. Each returned body includes its selected-zodiac longitude, sign position, an apparent one-day motion value, and a retrograde flag.

Default zodiac
Tropical
Position frame
Apparent geocentric longitude
Public date window
1900-01-01 through 2050-12-31

What can you build with it?

The endpoints are designed for server-side product backends. A client application can turn the returned data into a chart wheel, accessible table, natal report, synastry comparison, or calendar that evaluates selected transit instants.

  • Natal chart pages and saved chart profiles
  • Custom SVG or Canvas chart renderers
  • Relationship and synastry interfaces based on raw cross-aspects
  • Transit views for dates and times chosen by the caller
  • Bounded calendars of sign ingresses, stations, and exact major aspects
  • Rule-based editorial systems that preserve their own interpretive voice

See the Cosmic Ephemeris use-case guide for architecture and privacy considerations before collecting birth information.

Current calculation boundaries

Cosmic Ephemeris returns calculation data, not predictive certainty or professional advice. Your application owns its interpretations, editorial claims, and treatment of user data.

  • Placidus, Porphyry, Meridian, Campanus, Regiomontanus, Alcabitius, Koch, Morinus, Topocentric, Sripati, Vehlow, Horizon/Azimuth, Krusinski-Pisa-Goelzer, Sunshine, Sunshine alternative, Savard-A, Pullen SD, Pullen SR, Carter Poli-Equatorial, APC, Equal MC, and Natural are opt-in betas with no fallback on the Houses and natal-SVG endpoints
  • Gauquelin is an opt-in Houses-only beta returning 36 clockwise semiarc sectors; it is not a twelve-house natal-SVG system and never falls back
  • Secondary-progressed planets are beta; no progressed angles/houses. The separate Davison beta uses an uncorrected TT/arithmetic physical midpoint; corrected-MC and spherical variants are not offered. Beta composites retain shortest-arc midpoints and synthetic Equal/Whole Sign houses.
  • Return beta supports Sun/Moon only, Equal/Whole Sign houses and fixed search windows; it does not accept arbitrary event-search controls.
  • The separate planetary-events beta searches sign ingresses, tropical stations and five exact major aspects for at most 31 days. House-ingresses searches transit crossings of fixed Equal or Whole Sign reference-chart cusps. The aspect-windows beta adds configurable exact-hit-anchored orb intervals, applying/separating labels, retrograde repeat numbering and optional iCalendar text. None supplies interpretation; planetary-events and aspect-windows do not calculate houses. The Moon-phase beta separately searches four primary lunar phases
  • No applying/separating flags, user-configurable orbs, dignity scoring, or prose interpretations
  • No topocentric planet or point positions, right ascension, declination, altitude/azimuth, or distance
  • The legacy chart field labeled true node remains identical to the mean-node result; the separate lunar-node beta supplies a distinct osculating model.

See beta Western calculations for original light/dark natal wheels, midpoint composites and secondary-progressed planets. The progression convention is one TT day per fixed 365.2421904-day year; natal angles/houses remain separate context. Composite antipodes reject rather than choosing an arbitrary midpoint. Read Calculation methodology and limitations before comparing output with another ephemeris or astrology application.

Start with the documented contract

  1. Collect an explicit date, local time, IANA timezone, latitude, and longitude.
  2. Send the request from your server with an API key in the Authorization header.
  3. Validate the response and render the calculation in your own product interface.