:::note
**TL;DR**
- A return chart is cast for one exact instant: the moment a transiting body comes back to the ecliptic longitude it held at birth.
- The same longitude tolerance produces very different timing precision per body: about 1.5 minutes for the Sun, about 43 minutes for Saturn, because precision scales with how fast the body moves.
- Verify a return timestamp by querying JPL Horizons for the apparent longitude of the transiting body at the computed instant and confirming it matches the natal longitude.
- Developer takeaway: call `/location/search` first, then POST to `/astrology/solar-return`, `/astrology/lunar-return`, or `/astrology/planetary-returns`.
:::

A return chart is one of the few astrology techniques where a single number decides everything downstream. The chart, the Ascendant, every house cusp, and every angle all derive from one timestamp: the instant a transiting body reconjuncts its natal ecliptic longitude. Get that instant wrong by a few minutes and the angles drift, sometimes across a sign boundary, and the reading changes. Most return chart implementations report the timestamp to the second and never state how precise it actually is. That precision is not constant. It depends on which body you are tracking, because a fast Moon and a slow Saturn behave very differently under the same root-finding tolerance. This guide breaks down where return chart timing precision comes from and how to verify it against NASA JPL Horizons.

## Why does a return chart depend on one exact instant?

A return chart is cast for the single moment a transiting body returns to the exact ecliptic longitude it held at birth. A solar return marks when the transiting Sun reconjuncts the natal Sun, once per year. A lunar return repeats roughly every 27.3 days, and planetary returns track Mercury, Venus, Mars, Jupiter, and Saturn cycles. Because the whole chart derives from that one timestamp, an error of minutes is not cosmetic.

The Ascendant moves about one degree every four minutes of clock time. A timing error of 15 minutes can shift the return Ascendant by nearly four degrees, sometimes across a sign boundary, which changes the rising sign, the house rulerships, and the placement of every planet into houses. The conjunction instant is therefore the only number that matters at the root of the calculation. Everything else is deterministic once that instant is fixed, so the entire accuracy budget of a return chart lives in how tightly you can pin the conjunction.

Ready to build this? The [Astrology API](/products/astrology-api "production-ready Western astrology API with verified return charts") gives you solar, lunar, and planetary returns behind one key. [See pricing](/pricing "RoxyAPI pricing and plan tiers").

## How does planet velocity set return-timing precision?

Return-timing precision is governed by angular velocity. A root-finder converges when the transiting body sits within a fixed longitude tolerance of the natal longitude, but converting that angular tolerance into a time window depends on how fast the body moves. A fast body crosses the tolerance band quickly, pinning the timestamp tightly. A slow body lingers inside the band, widening the window for the same angular tolerance.

:::stat 28x
The same longitude tolerance of 3.6 arcseconds pins the solar return to about 1.5 minutes but the Saturn return only to about 43 minutes, a 28x spread driven entirely by angular velocity.
:::

| Return body | Mean motion (deg/day) | Longitude tolerance | Timing precision |
|---|---|---|---|
| Moon | 13.18 | 36 arcsec (0.01 deg) | ~1.1 min |
| Sun | 0.99 | 3.6 arcsec (0.001 deg) | ~1.5 min |
| Mars | 0.52 | 3.6 arcsec (0.001 deg) | ~2.7 min |
| Jupiter | 0.083 | 3.6 arcsec (0.001 deg) | ~17 min |
| Saturn | 0.033 | 3.6 arcsec (0.001 deg) | ~43 min |

The Moon uses a looser angular tolerance than the Sun yet still pins the tightest window, because it travels more than 13 degrees per day. Saturn, at one thirtieth of a degree per day, needs a far tighter tolerance to reach the same precision. You can recover precision for a slow body by tightening the tolerance at the cost of more root-finder iterations, but the velocity, not the tolerance, is the constraint you cannot remove.

## How do you verify a return timestamp against JPL Horizons?

Verify the timestamp, not just a planet position, by querying JPL Horizons for the apparent geocentric ecliptic longitude of the transiting body at the computed return instant, then confirming it equals the natal longitude within the body tolerance. A position-only check at a known time misses timing drift entirely. The timestamp is the claim under test, so the residual you measure is the difference between the natal longitude and the body longitude at the returned instant.

The procedure is five steps:

1. Compute the natal longitude of the body from the birth date, time, and timezone.
2. Call the return endpoint and capture the candidate return timestamp.
3. Query JPL Horizons in observer mode, target the body, geocentric center, for apparent ecliptic longitude at that exact timestamp.
4. Subtract: the residual should fall inside the tolerance band for that body.
5. Repeat across many charts and track the maximum residual.

:::warning
Two traps. First, compare apparent longitude to apparent longitude. Mixing geometric and apparent positions injects an aberration and nutation error of up to about 20 arcseconds into the residual. Second, for Mercury and Venus returns near a retrograde station the geocentric speed falls toward zero, so the same tolerance maps to a much wider time window and the search can find more than one crossing inside a single synodic cycle.
:::

This is the same cross-checking discipline behind every accuracy claim on the [methodology](/methodology "RoxyAPI testing and verification methodology") page.

## What sets the floor under return-chart accuracy?

Return-chart accuracy rests on the accuracy of the underlying planet positions. The public benchmark measures that floor: 210 reference positions across 21 charts, all 210 within tolerance against NASA JPL Horizons DE441, with a median deviation of 0.27 arcminutes and a maximum of 0.54 arcminutes. The Moon, the fastest body, lands tightest at 0.05 arcminutes.

Return timing inherits this position accuracy. The same ephemeris computes both the natal longitude and the transiting longitude, so any shared systematic offset largely cancels in the difference that the root-finder drives to zero. What remains is the convergence tolerance from the velocity table above, sitting on an ephemeris floor measured in tens of arcseconds. For the Moon, the 0.05 arcminute position result is far tighter than the lunar return tolerance, so the tolerance window dominates. For slower bodies the two budgets sit closer together, which is another reason to tighten the tolerance when timing a Jupiter or Saturn return. The full suite is reproducible at [github.com/RoxyAPI/astrology-api-benchmark](https://github.com/RoxyAPI/astrology-api-benchmark "open MIT-licensed accuracy benchmark versus JPL Horizons").

## How do you call the solar, lunar, and planetary return endpoints?

Every return endpoint is location-sensitive, so resolve coordinates first with `GET /location/search`, then POST the birth data and the return window to the relevant endpoint. The solar return takes a `returnYear`, the lunar return takes an approximate `returnDate`, and the planetary return takes a `planet` plus an `approximateDate`. The conjunction instant is the same anywhere on Earth, but the latitude and longitude you supply set the Ascendant and house cusps.

```bash
curl "https://roxyapi.com/api/v2/location/search?q=New%20York" \
  -H "X-API-Key: YOUR_KEY"
```

Feed the returned `latitude`, `longitude`, and `timezone` into the solar return call:

::: tabs
### curl
```bash
curl -X POST https://roxyapi.com/api/v2/astrology/solar-return \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "birthDate": "1990-07-15",
    "birthTime": "14:30:00",
    "returnYear": 2026,
    "latitude": 40.7128,
    "longitude": -74.006,
    "timezone": -5
  }'
```

### TypeScript
```ts
const res = await fetch("https://roxyapi.com/api/v2/astrology/solar-return", {
  method: "POST",
  headers: {
    "X-API-Key": "YOUR_KEY",
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    birthDate: "1990-07-15",
    birthTime: "14:30:00",
    returnYear: 2026,
    latitude: 40.7128,
    longitude: -74.006,
    timezone: -5,
  }),
});
const data = await res.json();
console.log(data.solarReturnDate, data.natalSunPosition.sign);
```

### Python
```python
import requests

res = requests.post(
    "https://roxyapi.com/api/v2/astrology/solar-return",
    headers={"X-API-Key": "YOUR_KEY", "Content-Type": "application/json"},
    json={
        "birthDate": "1990-07-15",
        "birthTime": "14:30:00",
        "returnYear": 2026,
        "latitude": 40.7128,
        "longitude": -74.006,
        "timezone": -5,
    },
)
data = res.json()
print(data["solarReturnDate"], data["natalSunPosition"]["sign"])
```
:::

The response carries `solarReturnDate` and `natalSunPosition`. The [`POST /astrology/lunar-return`](/api-reference#tag/western-astrology/POST/astrology/lunar-return "lunar return chart API request and response schema") endpoint swaps `returnYear` for a `returnDate` and returns `lunarReturnDate` with `natalMoonPosition`. The [`POST /astrology/planetary-returns`](/api-reference#tag/western-astrology/POST/astrology/planetary-returns "planetary return chart API request and response schema") endpoint adds a `planet` and an `approximateDate` and returns `returnDate`, `natalPlanetPosition`, and `approximateCycle`. Full request and response schemas live in the [`POST /astrology/solar-return`](/api-reference#tag/western-astrology/POST/astrology/solar-return "solar return chart API request and response schema") reference.

## FAQ

**What is a return chart in astrology?**

A return chart is cast for the exact moment a transiting body comes back to the ecliptic longitude it held at birth. The solar return is the annual birthday chart, the lunar return repeats about every 27.3 days, and planetary returns track the Mercury, Venus, Mars, Jupiter, and Saturn cycles.

**How accurate is the timing of a solar return?**

At the shipped longitude tolerance, the solar return timestamp is pinned to about 1.5 minutes. Because the transiting Sun moves about 0.99 degrees per day, the same angular tolerance always converts to roughly the same time window for the Sun.

**Why is a Saturn return timestamp less precise than a solar return?**

Saturn moves about 0.033 degrees per day, roughly 30 times slower than the Sun. The same longitude tolerance therefore maps to a wider time window, about 43 minutes for Saturn versus about 1.5 minutes for the Sun.

**Does location change a return chart?**

Yes. The conjunction instant is the same everywhere, but the Ascendant, Midheaven, and house cusps depend on the latitude and longitude you supply. Relocating a solar return to another city changes the angles and the house placements while keeping the timestamp identical.

**How do you verify a return timestamp against JPL Horizons?**

Query JPL Horizons for the apparent geocentric ecliptic longitude of the transiting body at the computed return instant, then confirm it matches the natal longitude within the tolerance. Comparing apparent longitude to apparent longitude keeps aberration and nutation out of the residual.

## Conclusion

A return chart is only as trustworthy as the single instant it is cast for, and that instant is only as precise as the angular velocity of the body allows. RoxyAPI computes solar, lunar, and planetary returns with Roxy Ephemeris and verifies the timing against NASA JPL Horizons, so the precision is a known quantity rather than a guess. Explore the [Astrology API](/products/astrology-api "production-ready Western astrology API with solar, lunar, and planetary returns") and [pricing](/pricing "RoxyAPI pricing and plan tiers") to start.