::: note
**TL;DR**
- Seven endpoints carry the advanced natal layer past the ten planets: fixed stars, asteroids, Arabic lots, aspect patterns, secondary progressions, solar arc directions, and annual profections.
- Positions are precessed per chart, not read from a frozen table. Regulus sits at 29.7008 Leo for a 1990 birth and 0.2021 Virgo for a 2026 one, a 0.5013 degree shift the API computes from the chart date.
- The layer is internally consistent. Part of Fortune plus Part of Spirit equals twice the Ascendant, and the solar arc equals the progressed Sun minus the natal Sun, both reproducible with two calls.
- Every endpoint ships in the same flat subscription as the natal chart: one call each, one key, no per-endpoint fee.
:::

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](/products/astrology-api "Western Astrology API including fixed stars, asteroids, Arabic lots, and directions"): 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.

| Endpoint | Method | Returns |
|---|---|---|
| [`/astrology/fixed-stars`](/api-reference#tag/western-astrology/POST/astrology/fixed-stars "fixed star positions, magnitudes, and natal conjunctions") | POST | 43 named stars, precessed, with conjunctions to natal points |
| [`/astrology/asteroids`](/api-reference#tag/western-astrology/POST/astrology/asteroids "Ceres, Pallas, Juno, and Vesta natal positions") | POST | Ceres, Pallas, Juno, Vesta by sign, house, and speed |
| [`/astrology/arabic-lots`](/api-reference#tag/western-astrology/POST/astrology/arabic-lots "seven Hermetic lots with day and night sect formulas") | POST | Seven lots with the formula actually applied |
| [`/astrology/aspect-patterns`](/api-reference#tag/western-astrology/POST/astrology/aspect-patterns "Grand Trine, T-Square, Yod, Stellium detection with tunable orbs") | POST | Grand Trine, Kite, T-Square, Grand Cross, Yod, Mystic Rectangle, Stellium |
| [`/astrology/progressions`](/api-reference#tag/western-astrology/POST/astrology/progressions "secondary progressed chart, day for a year") | POST | Progressed chart, 14 bodies plus progressed angles |
| [`/astrology/solar-arc`](/api-reference#tag/western-astrology/POST/astrology/solar-arc "solar arc directed chart at about one degree per year") | POST | 16 directed points including Ascendant and Midheaven |
| [`/astrology/profections`](/api-reference#tag/western-astrology/POST/astrology/profections "annual profection, profected house and lord of the year") | POST | Profected house, sign, and lord of the year |

Ready to build this? The [Astrology API](/products/astrology-api "production-ready Western Astrology API with the full advanced natal layer") gives you all seven under the same key as the natal chart, with no per-endpoint fee. [See pricing](/pricing "RoxyAPI pricing tiers").

## 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:

| Chart date | Longitude | Sign | Degree |
|---|---:|---|---:|
| 1990-07-15 | 149.7008 | Leo | 29.7008 |
| 2026-07-11 | 150.2021 | Virgo | 0.2021 |

::: stat 0.5013 degrees
**Regulus precession across 36 years**, enough to carry it over the Leo to Virgo boundary. Reproduce it with two calls to [`POST /astrology/fixed-stars`](/api-reference#tag/western-astrology/POST/astrology/fixed-stars "fixed star endpoint with per-chart precession").
:::

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:

```json
{
  "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:

| Birth time | `sect` | Part of Fortune formula | Result |
|---|---|---|---|
| 14:30:00 | `day` | `Ascendant + Moon - Sun` | Leo 11.0061 |
| 02:30:00 | `night` | `Ascendant + Sun - Moon` | Virgo 10.5823 |

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.

::: warning
If your provider does not tell you which sect it detected, you cannot audit the Part of Fortune it returned. The lots endpoint returns `sect` and `formula` on every response for exactly this reason.
:::

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:

```json
{
  "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:

| Query | Patterns found |
|---|---:|
| (default) | 3 |
| `?strictOrbs=true` | 0 |
| `?include=chiron,northNode` | 7 |

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](/blogs/planetary-aspect-calculation-orbs-edge-cases "how orbs and edge cases break planetary aspect calculation") 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:

| Endpoint | Key field | Captured value |
|---|---|---|
| `/astrology/progressions` | `progressedDate` | `1990-08-20` (birth plus 36 days) |
| `/astrology/progressions` | progressed Sun | Leo 27.4723 |
| `/astrology/solar-arc` | `solarArc` | 34.46220133441818 |
| `/astrology/profections` | `profectedHouse` / `lordOfYear` | 12 in Libra, Venus |

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.

::: tabs
### curl
```bash
# 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"
  }'
```

### TypeScript
```typescript
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
```

### Python
```python
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](/docs/sdk "typed SDKs for TypeScript, Python, PHP, C#, and Go") and the same [Remote MCP servers](/docs/mcp "Remote MCP servers so agents can call RoxyAPI with no local setup") 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](https://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](/methodology "RoxyAPI accuracy and verification 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](/products/astrology-api "production-ready Western Astrology API with fixed stars, asteroids, Arabic lots, and directions") product page, or read the [natal chart guide](/blogs/natal-chart-api-complete-guide-astrology-app-developers "complete natal chart API guide for astrology app developers") for the base layer these endpoints extend. Every plan on [pricing](/pricing "RoxyAPI pricing tiers") includes all of it.