Whole Sign Fallback at Polar Latitudes for Birth Chart APIs

About the author: Torsten Brinkmann is a Western astrologer and developer advocate with 16 years of practice and a Computer Science background. His work focuses on the astronomical mathematics behind natal charts and the developer integration patterns for astrology APIs, with research interests in house system selection at extreme latitudes.

Most birth chart APIs ship with Placidus as the default and never test what happens at 70 degrees north. The math was designed for Renaissance Italy, not Tromso or Anchorage. When a user enters a birth in Murmansk or Longyearbyen, the diurnal arc equation that defines Placidus intermediate cusps has no real solution. A naive implementation returns NaN values. A worse one ships a 500 error to the consuming app. This post walks through what RoxyAPI returns when Placidus or Koch breaks, why the equation degenerates above the Arctic Circle, how the API falls back to keep the chart usable, and which field to send to override the fallback for traditional Whole Sign readings. Worked with one verified birth in Tromso at 69.65 north.

Why Placidus breaks above 66 degrees latitude

Placidus divides each diurnal semi-arc into thirds and locates intermediate cusps where each third intersects the ecliptic. The defining equation requires arccos(-tan(latitude) * tan(declination)) to return a real number. When that product exceeds 1 in absolute value the arccos has no real solution and the cusp is undefined. This happens for any ecliptic point whose declination plus the observer latitude exceeds 90 degrees, which is exactly the geometric condition for circumpolar bodies that never rise or never set. The threshold is the Arctic Circle at 66 degrees 33 minutes north and the Antarctic Circle at 66 degrees 33 minutes south. Koch fails for the same reason, since it computes intermediate cusps from the Midheaven semi-arc, which collapses when the MC degree itself becomes circumpolar. Regiomontanus and Campanus, two other quadrant systems not implemented by RoxyAPI, fail under similar conditions because all four depend on the prime vertical or horizon crossing of points that simply do not cross at extreme latitudes.

Ready to ship a polar-safe chart? Western Astrology API returns 12 valid cusps at any latitude, no exception handling required. See pricing.

What the API returns at the polar cutoff

Send a Tromso birth to the chart endpoint with the default house system and the response still returns 12 cusps with valid sign and degree fields. The numbers do not blow up. Internally, the Placidus solver checks whether the diurnal-arc product is in range. If any of the four intermediate cusps cannot be solved, the handler short-circuits and returns Equal House cusps for the same Ascendant and Midheaven. The response carries the same shape as a successful Placidus chart: houses[] with 12 entries, each entry with number, longitude, sign, degree. The houseSystem field on the response echoes back what the request asked for, so the consuming app sees placidus even when the math fell back to Equal House behind the scenes. Most consumer apps render correctly because the cusps are valid and the chart wheel still draws. The risk is silent semantic drift: a subscriber expecting Placidus quadrant houses gets evenly spaced cusps instead, and the difference shows up in planet-to-house assignments for charts where a planet sits near a cusp.

How Whole Sign fallback preserves chart usability

Whole Sign is the safe default at high latitudes because it does not depend on diurnal arcs at all. Each house spans exactly 30 degrees and starts at the cusp of a zodiac sign. The first house is whatever sign the Ascendant occupies, the second house is the next sign, and so on around the wheel. The math reduces to one Ascendant calculation plus modular arithmetic. The Ascendant remains well-defined up to 89.99 degrees of latitude because it is the intersection of the eastern horizon with the ecliptic, and that intersection only fails at the geographic pole. For births inside an Arctic city, Whole Sign returns sensible cusps that practitioners can interpret using two thousand years of Hellenistic precedent. Equal House, the system the API falls back to internally, is similar in spirit but divides 30-degree segments from the Ascendant rather than from sign cusps. Both sidestep the diurnal-arc singularity. The difference between Equal and Whole Sign at 70 north can reach 29 degrees on the first cusp, large enough to put a planet in a different house.

How to override the fallback explicitly

Pass houseSystem in the request body to the natal chart endpoint and the handler skips the Placidus path entirely. The supported values are placidus, whole-sign, equal, and koch. Default is placidus. The endpoint also accepts houseSystem: "all" on the dedicated houses route to return all four systems side by side for comparison, which is useful when building a UI that lets the end user pick.

The first call always resolves the city to a coordinate via GET /location/search so the latitude, longitude, and timezone match what users typed. Then feed those into the chart endpoint with an explicit houseSystem.

# Step 1: resolve Tromso to coordinates
curl -H "X-API-Key: YOUR_KEY" \
  "https://roxyapi.com/api/v2/location/search?q=Tromso"

# Step 2: natal chart with explicit Whole Sign override
curl -X POST https://roxyapi.com/api/v2/astrology/natal-chart \
  -H "X-API-Key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "date": "1990-07-15",
    "time": "14:30:00",
    "latitude": 69.6492,
    "longitude": 18.9553,
    "timezone": "Europe/Oslo",
    "houseSystem": "whole-sign"
  }'

import { Roxy } from '@roxyapi/sdk';

const roxy = new Roxy({ apiKey: process.env.ROXY_API_KEY });

const place = await roxy.location.search({ q: 'Tromso' });
const { latitude, longitude, timezone } = place[0];

const chart = await roxy.astrology.natalChart({
  date: '1990-07-15',
  time: '14:30:00',
  latitude,
  longitude,
  timezone,
  houseSystem: 'whole-sign',
});

console.log(chart.houseSystem); // "whole-sign"
console.log(chart.houses.length); // 12

from roxy_sdk import Roxy

roxy = Roxy(api_key=os.environ["ROXY_API_KEY"])

place = roxy.location.search(q="Tromso")
loc = place[0]

chart = roxy.astrology.natal_chart(
    date="1990-07-15",
    time="14:30:00",
    latitude=loc.latitude,
    longitude=loc.longitude,
    timezone=loc.timezone,
    house_system="whole-sign",
)

print(chart.house_system)  # whole-sign
print(len(chart.houses))   # 12

The full request and response schema lives at POST /astrology/natal-chart. For the dedicated houses comparator that returns all four systems side by side, see the houses route in the same tag. Verified positions cross-check against NASA JPL Horizons. Methodology is documented at the verification page.

Per-system polar behavior

Supported house systems and their polar behavior

Which user populations actually hit this in production

Polar births are not an academic edge case. Roughly 13 million people live above 60 degrees north across Norway, Sweden, Finland, Iceland, Russia, Canada, Alaska, and Greenland. Cities inside the Arctic Circle proper, where Placidus reliably fails, include Tromso at 69.65 north (around 78,000), Murmansk at 68.97 north (around 270,000), Bodo at 67.28 north (around 53,000), and Longyearbyen at 78.22 north (around 2,400 permanent residents). Reykjavik at 64.13 north sits just south of the cutoff but lies close enough that midwinter charts can still degenerate for specific Sun declinations. Antarctic stations including McMurdo, Amundsen-Scott, Concordia, and Vostok host roughly 4,000 over-winter scientists in any given year, and births registered at those stations need polar-safe house systems too. Astrology apps that geo-index user signups will see polar births as soon as they ship in the Nordics, and the failure mode is silent unless the API explicitly handles it.

FAQ

What is the geographic cutoff where Placidus breaks?

The Arctic Circle and Antarctic Circle, at approximately 66 degrees 33 minutes of latitude. Above that latitude the diurnal-arc equation that defines Placidus intermediate cusps loses a real solution for at least some declinations, which means the cusps cannot be computed by the standard algorithm. The same cutoff applies to Koch, Regiomontanus, and Campanus, which all rely on quadrant divisions of arcs that become circumpolar.

Why does the API fall back to Equal House instead of Whole Sign?

Equal House is the closest mathematically continuous neighbor of Placidus, since both anchor on the exact Ascendant degree. Whole Sign anchors on the sign cusp, which is up to 30 degrees away. Falling back to Equal preserves the Ascendant and the planetary positions relative to it, which is the choice most modern Western practitioners would make under duress. If you prefer Whole Sign for traditional or Hellenistic readings, set houseSystem: "whole-sign" explicitly in the request and bypass the fallback path entirely.

How do I detect that a fallback happened?

The current natal chart response echoes the requested houseSystem field, so the surface contract does not signal a fallback. The reliable detection method is geographic: latitude above 66.55 or below negative 66.55 degrees combined with houseSystem: "placidus" or houseSystem: "koch" in the request means the response cusps are Equal House regardless of what the field says. The cleanest pattern is to detect the geographic risk on your side, force houseSystem: "whole-sign" for those requests, and surface the choice in the user-facing UI.

Can I get all four house systems back in one call to compare?

Yes. The dedicated houses endpoint accepts houseSystem: "all" and returns a comparison field with Placidus, Whole Sign, Equal, and Koch cusps side by side for the same birth data. This is useful for educational tools, side-by-side renders, and any UI that lets the end user pick a system after the chart is computed. The natal chart endpoint itself returns one system per call.

Does this affect Vedic charts too?

Vedic astrology traditionally uses Whole Sign houses (rashi as house) so the polar failure mode does not apply in practice. The Vedic chart endpoint maps planets to signs as houses by construction, which is mathematically equivalent to Whole Sign. If you build a hybrid app that exposes both Western and Vedic houses, force Whole Sign on the Western side for polar births to keep the two readings comparable.

What if the user does not enter a city, only coordinates?

Coordinate-only input still works. The natal chart endpoint takes raw latitude, longitude, and timezone. The polar fallback fires the same way regardless of whether the coordinates came from /location/search or from a manual input. For ICP audiences in the Nordics or polar research, the coordinate path is common because remote-station latitudes are not always in the geocoder.

Conclusion

Polar births break Placidus quietly. Most APIs return NaN cusps or 500 errors at 70 north, surfacing as bug reports from Norwegian and Icelandic users on the day you ship. RoxyAPI falls back to Equal House with a complete 12-cusp response, and gives you a one-field override to Whole Sign for tradition-aligned charts. Build polar-safe charts on the Western Astrology API.