Guides

When the birth time is unknown

A large share of users signing up for an astrology product do not know their exact birth time. Ascendant, house cusps, and dasha timing all depend on the birth time.

None of them can be computed reliably without it. This guide covers what actually needs a birth time, and what product to build around users who don't have one.

All three endpoints below use HTTP Basic auth (your user ID as the username, your API key as the password) and share the base URL https://json.astrologyapi.com/v1. The API does not send CORS headers, so browser-direct calls fail. Call it from a server, and never put an API key in client-side code. For a browser-safe call pattern, see the access token usage guide.

What depends on birth time, and what doesn't

Check the required parameters on each endpoint rather than guessing. Some outputs need an exact hour and minute. Others only need a date, or nothing more than a zodiac sign.

Feature	Needs exact time?	Endpoint	Notes
Ascendant, houses, dasha timing	Yes	`birth_details`, `astro_details`	`hour` and `min` are both required fields. The request fails without them.
Moon sign	Yes, in principle	`astro_details`	Less sensitive than the ascendant, but can still flip if the Moon changed sign during the day.
Sun-sign horoscope	No	`sun_sign_prediction/daily/:zodiacName`	Takes only an optional `timezone` parameter. No date of birth, no hour, no place.
Numerology	No	`numero_table`	Requires `day`, `month`, `year`, and `name`. Hour and minute are not part of the request.

The Moon moves through the zodiac much faster than the Sun. It takes the Moon roughly 27 to 28 days to pass through all 12 signs.

On average the Moon sits in a sign for about 2.25 days. A chart built on an assumed birth time can report the wrong moon sign. The error happens when the Moon actually changed sign partway through that calendar day.

Product patterns for missing birth time

Default to noon with a visible disclaimer. Assuming noon when the time is unknown is a common approach, and a reasonable one, provided the output says so.

Show a visible accuracy disclaimer next to any ascendant, house, or moon-sign output computed this way.

The true birth time could sit on the other side of a sign or degree boundary. The output can therefore be wrong, and the user should know that before they read into it.

Moon-sign-first products. Build the primary experience around sun sign and numerology, since neither needs an exact time.

Treat moon-sign and ascendant detail as a secondary layer, clearly labeled as available only once the user supplies their birth time. This keeps the core product accurate for every user, time-known or not.

Sun-sign-only fallback tier. When a user has no birth time and won't provide one, serve the sun-sign-only tier instead of a fabricated full chart.

A correct, narrower answer holds up better than a detailed one built on a guessed input.

Progressive profiling. Let the user start on the sun-sign and numerology tier right away. Don't block signup on birth time.

Ask for the exact time later: a profile-completion prompt, a nudge after a few sessions, or a step added at an upsell. Recompute the full chart once the time arrives.

A tier-selection function

A user can qualify for more than one tier at once. Check each tier independently rather than picking a single one.

Sun sign is always available.
Numerology depends on having a date and a name.
The full chart depends on having an exact hour and minute in addition to the date.

// Vanilla JS, no framework. Runs in Node or the browser.
//
// birthFields is whatever the user has given you so far, e.g.:
//   { day: 10, month: 5, year: 1990, hour: 19, min: 55, name: 'Asha' }
//   { day: 10, month: 5, year: 1990, name: 'Asha' }        // no time
//   {}                                                      // nothing yet
function resolveAvailableTier(birthFields) {
  const hasDate =
    birthFields.day != null &&
    birthFields.month != null &&
    birthFields.year != null
  const hasTime = birthFields.hour != null && birthFields.min != null
  const hasName = typeof birthFields.name === 'string' && birthFields.name.length > 0

  return {
    // sun_sign_prediction only needs a zodiac sign name, which the user can
    // state directly. It never needs a date, time, or place, so this tier
    // is always available.
    sunSign: true,

    // numero_table needs day/month/year plus a name, and nothing else.
    // hour and min are irrelevant to it.
    numerology: hasDate && hasName,

    // birth_details and astro_details require hour and min in addition to
    // the full date and place. Without both, do not call these endpoints.
    fullChart: hasDate && hasTime,
  }
}

// Example: a user has given a date of birth and a name, but not a time.
const tiers = resolveAvailableTier({
  day: 10,
  month: 5,
  year: 1990,
  name: 'Asha',
})
console.log(tiers)
// { sunSign: true, numerology: true, fullChart: false }

What not to do

Never silently default a missing hour and minute to midnight and then present the resulting ascendant, houses, or moon sign as if precisely known. That is different from defaulting to noon with a visible disclaimer. A silent default hides the uncertainty from the user instead of naming it.

This API does not offer birth-time rectification. No endpoint recovers an unknown birth time from other life data. Don't build a flow that implies otherwise, such as a form asking for life events to "calculate" a missing birth time.