Fixed Stars, Asteroids, and Arabic Lots: Advanced Natal API

A natal chart endpoint that returns ten planets, twelve houses, and a flat list of aspects is table stakes. It is also where a lot of integrations run out of road. The moment a serious astrologer opens your app, the questions get harder: is that Sun conjunct Regulus, and precessed to which date? Is this a day chart or a night chart, and did you flip the Part of Fortune formula accordingly? What orb are you using to call that a T-square?

This post walks the advanced natal layer of the RoxyAPI Western astrology API: seven live endpoints, every request shape and response field pulled from the live OpenAPI spec, and every value below captured from a real production response. One birth chart runs through all of them: 15 July 1990, 14:30:00, New York City.

What does the advanced natal layer add beyond the ten planets?

Seven endpoints, each returning a complete result in a single call. The base natal chart already carries fourteen bodies (the ten planets plus North Node, South Node, Chiron, and Black Moon Lilith), twelve houses, aspects, detected patterns, the vertex, and a sect-aware Part of Fortune. The advanced layer is what sits on top of that: catalog stars precessed to the chart date, the four asteroid goddesses, seven Hermetic lots, tunable pattern detection, and three independent timing techniques.

Ready to build this? The Astrology API gives you all seven under the same key as the natal chart, with no per-endpoint fee. See pricing.

How far do fixed stars move between the catalog and the birth date?

Far enough to change the sign. Fixed stars are not fixed in tropical longitude: precession drags them forward at roughly 50 arcseconds a year, about one degree every 72 years. POST /astrology/fixed-stars precesses each catalog star to the chart date rather than serving a frozen table, so the same star lands in a different sign depending on who was born when.

Regulus, run through the endpoint twice with nothing changed but the date:

Each star arrives with magnitude, its traditional nature, and keywords. Algol comes back at Taurus 26.0395, magnitude 2.12, nature "Saturn and Jupiter". Conjunctions to natal points are computed for you and returned tightest first:

{
  "star": "Pollux",
  "point": "Sun",
  "orb": 0.0772,
  "interpretation": "The fixed star Pollux sits within 0.1 degrees of your Sun, a star of Mars nature in classical astrology."
}

The orb query parameter decides how much you see. On the same chart, the default orb=1 returns 3 conjunctions. orb=3 returns 11.

Why does the Part of Fortune formula flip between day and night charts?

Because the lot is defined by sect, and getting sect wrong silently moves the Part of Fortune by an arbitrary amount. POST /astrology/arabic-lots determines whether the Sun is above or below the horizon, reports the result in a sect field, and echoes the exact formula it applied. Two charts on the same day, one born at 14:30 and one at 02:30:

Part of Spirit takes the mirror formula in each case. That is not decoration, it is a checkable invariant: Spirit is Fortune reflected across the Ascendant, so Fortune plus Spirit must equal twice the Ascendant. On the day chart above, /arabic-lots returns Fortune at 131.00608221017433 and Spirit at 302.88811974727196. Their sum is 433.8942019574463. /astrology/natal-chart returns the Ascendant at 216.94710097872317, and twice that is 433.89420195744634. The two agree to floating point noise.

The endpoint returns seven lots in total: Fortune, Spirit, Eros, Necessity, Courage, Victory, and Nemesis.

How do you tune aspect-pattern orbs instead of hardcoding them?

With query parameters, because orb policy is the entire answer to whether a pattern exists. POST /astrology/aspect-patterns detects Grand Trine, Kite, T-Square, Grand Cross, Yod, Mystic Rectangle, and Stellium, and it exposes the two knobs that decide the outcome. On the 1990 chart, the default industry-standard orbs return 3 patterns:

{
  "kind": "T_SQUARE", "name": "T-Square",
  "planets": ["Moon", "Sun", "Saturn"],
  "apex": "Moon", "modality": "cardinal",
  "dissociate": false, "tightness": 61
}

Change nothing but the query string and the same chart tells a different story:

Tighter orbs erase every pattern in this chart. Adding Chiron and the North Node as pattern-eligible bodies more than doubles them. Both numbers are correct, and an app that hardcodes one orb table can never show you the other. The response echoes options so you always know which policy produced the result. The natal chart endpoint returns the default-orb patterns inline, so the dedicated endpoint is what you reach for when you need to change the policy. For the orb math underneath, see the aspect orb edge cases post.

How do progressions, solar arc, and profections time a chart?

Three different keys, three endpoints, all taking a targetDate alongside the birth data. Secondary progressions advance the chart one ephemeris day per year of life. Solar arc pushes every point forward by the arc the Sun itself has travelled. Annual profections walk the Ascendant one whole sign per completed year and hand you a lord of the year.

Run against 2026-07-11 for the same 1990 birth:

The two directed techniques are wired to each other by construction. solar-arc reports the directed Sun at longitude 147.4723243090658, which is exactly the progressed Sun that progressions returns, and the natal Sun sits at 113.01012297464763. The difference, 34.4622013344, is the solarArc value. Note that it is 34.46 degrees over 35.99 years, not 36: solar arc is only about one degree per year, because apparent solar motion is not uniform. An implementation that multiplies age by exactly 1.0 will drift.

How do you call the advanced natal endpoints?

Resolve the birth city first. Every coordinate-dependent endpoint needs latitude, longitude, and timezone, and you should never make a user type them. GET /location/search returns all three, and the IANA timezone string it hands back can be passed straight through, so historical DST is resolved for the birth date instead of the current one.

# 1. Resolve the city
curl -s "https://roxyapi.com/api/v2/location/search?q=New%20York&limit=1" \
  -H "X-API-Key: YOUR_KEY"
# -> { "cities": [ { "latitude": 40.71427, "longitude": -74.00597,
#                    "timezone": "America/New_York", ... } ] }

# 2. Feed it into any advanced endpoint
curl -s -X POST "https://roxyapi.com/api/v2/astrology/fixed-stars?orb=3" \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_KEY" \
  -d '{
    "date": "1990-07-15",
    "time": "14:30:00",
    "latitude": 40.71427,
    "longitude": -74.00597,
    "timezone": "America/New_York"
  }'

const { data: places } = await roxy.location.searchCities({
  query: { q: 'New York', limit: 1 },
});
const city = places.cities[0];

const { data, error } = await roxy.astrology.generateFixedStars({
  query: { orb: 3 },
  body: {
    date: '1990-07-15',
    time: '14:30:00',
    latitude: city.latitude,
    longitude: city.longitude,
    timezone: city.timezone,
  },
});

if (error) throw error;
console.log(data.conjunctions[0].star, data.conjunctions[0].orb);
// Zuben Elgenubi 0.042

places = roxy.location.search_cities(q="New York", limit=1)
city = places["cities"][0]

result = roxy.astrology.generate_fixed_stars(
    date="1990-07-15",
    time="14:30:00",
    latitude=city["latitude"],
    longitude=city["longitude"],
    timezone=city["timezone"],
    orb=3,
)

for c in result["conjunctions"]:
    print(c["star"], c["point"], c["orb"])
# Zuben Elgenubi Pluto 0.042

Every interpretation string in the layer is localized. POST /astrology/asteroids?lang=es returns the Ceres reading as "Tu Ceres en Leo habla de cómo cuidas y eres cuidado, los ciclos de nutrición, pérdida y retorno". An unsupported code is rejected rather than silently ignored: ?lang=xx returns a 400 with code: validation_error.

The map-astrology endpoints (/astrology/astrocartography, /astrology/relocation-chart, /astrology/local-space) sit in the same domain and take the same birth payload. On the Vedic side, POST /vedic-astrology/panchang/hora returns the twelve day horas and twelve night horas as the planetary-hours counterpart. All of them ship in the same subscription, with the same typed SDKs and the same Remote MCP servers an agent can call with no local setup.

FAQ

Is there an API for fixed stars in a natal chart?

Yes. RoxyAPI exposes POST /astrology/fixed-stars, which returns 43 named stars precessed to the chart date, each with tropical longitude, sign, degree, apparent magnitude, traditional planetary nature, keywords, and any conjunctions to natal planets or angles. The conjunction orb is tunable from 0 to 3 degrees via the orb query parameter, and the response sorts contacts tightest first.

How do I get the Part of Fortune from an API?

Call POST /astrology/arabic-lots with the birth date, time, latitude, longitude, and timezone. RoxyAPI detects the chart sect, applies the correct day or night formula, and returns the Part of Fortune alongside six other Hermetic lots. Both the detected sect and the exact formula used are included in the response, so the value can be audited rather than taken on trust. The natal chart endpoint also returns a sect-aware partOfFortune inline.

Which asteroids does the RoxyAPI astrology API support?

The POST /astrology/asteroids endpoint returns the four asteroid goddesses: Ceres, Pallas, Juno, and Vesta. Each comes back with ecliptic longitude and latitude, sign, degree, natal house, daily speed, a retrograde flag, and a written interpretation. The house system is selectable through the optional houseSystem field, which defaults to Placidus.

Can an astrology API detect a T-square or a Grand Trine?

Yes. POST /astrology/aspect-patterns detects Grand Trine, Kite, T-Square, Grand Cross, Yod, Mystic Rectangle, and Stellium, and returns the participating planets, the apex, the modality, a dissociate flag, and a tightness score. Orb policy is a query parameter rather than a hardcoded table, so strictOrbs=true narrows the orbs and include=chiron,northNode widens the eligible bodies.

How accurate are the advanced astrology endpoints?

Every position in the advanced layer comes from Roxy Ephemeris, verified against NASA JPL Horizons. The public MIT-licensed benchmark at github.com/RoxyAPI/astrology-api-benchmark checks 210 reference planet positions across 21 charts against JPL Horizons DE441, with a median deviation of 16 arcseconds. Full test methodology is published at /methodology, and every position-calculating endpoint in this layer carries gold-standard tests of its own.

Do I pay extra for the advanced endpoints?

No. Fixed stars, asteroids, Arabic lots, aspect patterns, progressions, solar arc, and profections are part of the same flat subscription as every other endpoint across all twelve domains. One request equals one quota unit, whether it arrives over REST or Remote MCP. There are no per-domain fees, no credit weighting, and no per-token charges.

Conclusion

The advanced natal layer is not a premium tier or a roadmap item: it is seven live endpoints, each returning a complete result in one call, with the sect, the orb policy, and the precession date all visible in the response so a practitioner can audit them. Start with the Astrology API product page, or read the natal chart guide for the base layer these endpoints extend. Every plan on pricing includes all of it.