Whole Sign Fallback at Polar Latitudes for Birth Chart APIs

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 use different constructions and are not implemented by this endpoint; the Placidus and Koch fallback rule should not be generalized to them.

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

For a Tromso birth with a Placidus or Koch request, the API selects Whole Sign before calculating the cusps because the absolute latitude exceeds 66.55 degrees. The response retains the standard houses[] shape and reports houseSystem: "whole-sign". Compare the response system with the requested system and make the effective choice visible in your chart interface.

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 is another available system. It 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 { createRoxy } from '@roxyapi/sdk';

const roxy = createRoxy(process.env.ROXY_API_KEY!);

const { data: place, error: placeError } = await roxy.location.searchCities({ query: { q: 'Tromso' } });
if (placeError) throw placeError;
const { latitude, longitude, timezone } = place.cities[0];

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

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

import os

from roxy_sdk import create_roxy

roxy = create_roxy(os.environ["ROXY_API_KEY"])

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

chart = roxy.astrology.generate_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["houseSystem"])  # 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. RoxyAPI applies its polar fallback threshold to Placidus and Koch. This endpoint does not calculate Regiomontanus or Campanus.

Which house system does the API use for polar Placidus or Koch requests?

It uses Whole Sign when the absolute latitude is at least 66.55 degrees. The natal chart response reports the effective system, so display that value instead of retaining the request label. An explicit Equal or Whole Sign request keeps the chosen system.

How do I detect that a fallback happened?

Read the returned houseSystem and compare it with the requested value. A Placidus or Koch request at absolute latitude 66.55 degrees or higher returns whole-sign. Show that effective convention beside the chart so readers know which house divisions they are seeing.

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 uses Whole Sign for polar Placidus or Koch requests and reports the effective system with the 12-cusp response. Build polar-safe charts on the Western Astrology API.