Geocoding Birth Places for Astrology API Charts

Every birth chart starts with a place. A natal chart, a kundli, a synastry comparison, all of them need latitude, longitude, and a timezone, and none of them can be calculated from a city name alone. Users know they were born in Springfield or London or Melbourne, not that they were born at 39.8 north and 89.6 west. So the first job of any astrology integration is geocoding: turning a place name into coordinates and the correct timezone. It sounds trivial, and it is where a surprising number of charts go quietly wrong, because one name can point to many places in different timezones and even different hemispheres. This guide shows why place names are ambiguous, how the wrong place changes the chart, and how to geocode a birth place correctly before the chart call.

Why does one birth place name resolve to many places?

City names are not unique, so a single birth place string can match many real places, and picking the wrong one silently changes the chart. A search for Springfield returns 11 places spread across at least three United States timezones, from America/New_York to America/Los_Angeles. If your code takes the first result, you are guessing which Springfield the user meant, and the guess carries a timezone with it. The problem is not limited to one country either, because names like Melbourne, London, and Paris repeat across continents, each carrying its own timezone and latitude. The table below is real output from the location search endpoint.

Ready to build this? The Astrology API pairs with the bundled location search so you geocode and chart under one key. See pricing.

How does the wrong place produce the wrong birth chart?

When two places share a name but sit at different latitudes, the same birth time produces a genuinely different chart, so auto picking the first result can return the wrong ascendant. Latitude drives the rising sign and the house cusps, and a large latitude gap moves them enough to cross a sign boundary. In the live test below, the same birth of 1990-07-15 at 14:30 returns a different ascendant sign depending on which Melbourne the search resolves.

The failure is invisible in testing because the API still returns a valid chart. It is only wrong, and only the user who knows their real rising sign will notice.

Why must you pass the IANA timezone, not a fixed offset?

The correct offset for a place depends on the date, so an astrology API needs the IANA timezone that geocoding returns, never a hardcoded number. Daylight saving means a city runs at different offsets across the year, and a fixed offset ignores that. London is at plus one in July, not zero. In the live test below, the same summer birth charted with the resolved Europe/London zone versus a hardcoded 0 moves the ascendant by 10.5 degrees, enough to cross a sign boundary for many births.

This is why the location search returns a timezone field like America/New_York alongside the coordinates. Pass that IANA name straight into the chart request and let the resolver apply the offset that was in force on the birth date. The same rule covers historical zone changes: many regions redrew their offsets across the twentieth century, and only an IANA zone plus the birth date can recover the offset a place actually used at that moment. For the deeper mechanics, see the timezone handling guide.

How to geocode a birth place before a chart call

Geocode in one step, disambiguate when needed, then chart. Call the location search with the birth place, let the user confirm the match when a name is ambiguous, and pass the returned latitude, longitude, and timezone into the chart request. A multi part query like Melbourne, Australia or London, Ontario, Canada pins the exact place in a single call. Both examples below are verified against the live schema.

# 1. Geocode the birth place. Add a region to disambiguate a shared name.
curl -s "https://roxyapi.com/api/v2/location/search?q=Melbourne,%20Australia" \
  -H "X-API-Key: YOUR_KEY"

# 2. Chart with the returned latitude, longitude, and IANA timezone.
curl -s -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","latitude":-37.814,"longitude":144.963,"timezone":"Australia/Melbourne"}'

const key = process.env.ROXY_API_KEY;

const geo = await fetch(
  "https://roxyapi.com/api/v2/location/search?q=Melbourne, Australia",
  { headers: { "X-API-Key": key } },
).then((r) => r.json());

// geo.cities is the candidate list. Let the user pick when total > 1.
const place = geo.cities[0];

const chart = await fetch(
  "https://roxyapi.com/api/v2/astrology/natal-chart",
  {
    method: "POST",
    headers: { "X-API-Key": key, "Content-Type": "application/json" },
    body: JSON.stringify({
      date: "1990-07-15",
      time: "14:30",
      latitude: place.latitude,
      longitude: place.longitude,
      timezone: place.timezone,
    }),
  },
).then((r) => r.json());

console.log(place.city, place.province, chart.ascendant.sign);

import os, requests

key = os.environ["ROXY_API_KEY"]
h = {"X-API-Key": key}

geo = requests.get(
    "https://roxyapi.com/api/v2/location/search",
    params={"q": "Melbourne, Australia"}, headers=h,
).json()

# geo["cities"] is the candidate list. Let the user pick when total > 1.
place = geo["cities"][0]

chart = requests.post(
    "https://roxyapi.com/api/v2/astrology/natal-chart",
    headers={**h, "Content-Type": "application/json"},
    json={
        "date": "1990-07-15",
        "time": "14:30",
        "latitude": place["latitude"],
        "longitude": place["longitude"],
        "timezone": place["timezone"],
    },
).json()

print(place["city"], place["province"], chart["ascendant"]["sign"])

A safe geocoding flow follows five steps:

1. Send the birth place to the location search, with a region qualifier when you have one.
2. Read the total field, and when it is above one, present the cities candidates instead of assuming.
3. Take latitude, longitude, and timezone from the confirmed city.
4. Pass the IANA timezone string to the chart endpoint, never a hardcoded offset.
5. Store the resolved place next to the chart so a later reader can audit which city was used.

The search response carries total and a cities array, so a total above one is your signal to show the choices rather than assume. Location search is bundled with every plan, part of 160 plus endpoints across 12 insight domains including Western astrology, Vedic astrology, numerology, and tarot, all under one key.

FAQ

How do I convert a birth city into coordinates for an astrology API?

Call the RoxyAPI location search with the city name and read latitude, longitude, and timezone from the first matching city. Pass those three values straight into any chart endpoint. The search covers 23,000 plus cities and returns the IANA timezone alongside the coordinates, so you never ask a user to type latitude and longitude.

Why does my birth chart look wrong even though the birth time is correct?

A correct time with the wrong place produces the wrong chart, because latitude sets the ascendant and house cusps. If your code takes the first geocoder result for an ambiguous name like Melbourne or Springfield, it may resolve a city in the wrong region or hemisphere. Confirm the matched city before charting when the search returns more than one candidate.

Should I send a UTC offset or an IANA timezone to the chart endpoint?

Send the IANA timezone, such as America/New_York, that the location search returns. A hardcoded UTC offset ignores daylight saving, so a summer birth can land an hour off and shift the ascendant by more than ten degrees. RoxyAPI resolves the offset that was in force on the birth date from the IANA zone.

How do I disambiguate two cities with the same name?

Add a region to the query, like Melbourne, Australia or London, Ontario, Canada, and the RoxyAPI location search pins the exact place in one call. When you only have a bare name, read the total field and present the cities candidates so the user selects the correct one.

Can I geocode a birth place without asking the user for coordinates?

Yes, and you should. Ask only for the birth city, send it to the RoxyAPI location search, and use the returned coordinates and timezone. Asking a user to type latitude and longitude is a conversion killer, and most people do not know their birth coordinates to begin with.

Does RoxyAPI return coordinates and timezone in one call?

Yes. A single RoxyAPI location search returns latitude, longitude, timezone, utcOffset, country, and province for each match. You geocode and resolve the timezone in one request, then send the result to any chart endpoint under the same key.

Conclusion

Geocoding is the quiet foundation of every accurate chart. Resolve the birth place to coordinates and an IANA timezone, disambiguate shared names before you chart, and never fold a fixed offset into the request. Get the place right and every downstream calculation, from the ascendant to the house cusps, rests on solid ground. Build it on the Location API and check the pricing to start.