Astrology GPT: Give Your AI Chatbot Real Chart Data

To build an astrology GPT that gets charts right, do not let the model work out the chart. Give it an action, a tool it can call, that sends the birth details to a chart API. Then tell it to quote what comes back. You need three parts: a short OpenAPI schema, an API key, and clear instructions.

The schema is a file that tells the model what it can call. Ours comes from the spec this site serves. We cut it from 50 operations down to 3, because a GPT Action limits how long each description can be. When a user asks about John Doe, the tool sends one request to /v1/planets. It gets back Virgo rising, the Moon in Taurus in the 9th house, and the time zone used. The answer is 3,089 characters long. The model then explains those facts in plain words.

This works for an AI kundli bot (a Vedic birth chart bot) on any platform that can call tools. If you want to know why a chatbot needs this at all, read how to build an AI astrologer that gets the chart right. This post is the wiring.

The three parts of an astrology GPT

OpenAI's own guide follows the same order. You paste in the schema, add the authentication, then write instructions that name each action. That is from its getting started page for GPT Actions, read on Oct 13, 2026.

Start from the spec we serve, then cut it down

The site serves the full API description at /astrology/openapi.json. It is OpenAPI 3.1, a common format for describing an API. On Oct 14, 2026, we ran it through an OpenAPI validator. It passed. It has 50 operations, all under /v1/, and each one has an operationId, the name a model uses to pick a call.

So why not paste it all in? OpenAI's production notes list a limit of 300 characters for each endpoint description. Our descriptions are written for people, so they run long. 48 of the 50 operations go over 300 characters. The planets call alone is described in 1,223 characters. The timezone field is 752 characters, over the 700 limit for a field.

There is a second reason to cut. A model picks the right tool more often from a short list. Our AI assistants guide makes the same point. For a chart bot, we kept 3: the chart, the periods and a plain summary.

We renamed each operationId, because planets_v1_planets_post is hard to name in instructions. We also wrote a new description for each call, 120 to 180 characters long. The cut file has 3 operations and the 8 data shapes they use, about 40,000 characters. It passed the same validator, with no field over either limit.

Two edits that stop silent mistakes

Cutting the file is also your chance to tighten it. Two edits matter most.

Make the birth time required. In the full spec, hour and minute are optional and default to 0, which means midnight. A model that skips the time still gets an answer, with no error. We sent John Doe's chart without the time. The API returned 200 OK with Taurus rising instead of Virgo. His Moon moved from the 9th house to the 1st. In the cut file, hour and minute are required, so the model has to ask the user.

Cap the dasha depth. The dasha call can return 1 to 5 levels of periods. Each level makes the answer far longer. OpenAI's notes cap what an action sends and gets back at 100,000 characters each way.

The cut file sets both the top limit and the default to 2. That keeps the answer near 10,000 characters, with main periods and sub-periods.

The request your tool sends

When a user asks for John Doe's chart, the model fills in the body from the schema. The action then sends this request. We ran the same call against our API on Oct 13, 2026.

John Doe, born Aug 15, 1990, 10:30 AM, New York (America/New_York)

POST https://apiforastrology.com/api/astrology/v1/planets
Authorization: Bearer <your API key>
Content-Type: application/json

{"year":1990,"month":8,"day":15,"hour":10,"minute":30,"latitude":40.7128,"longitude":-74.006,"timezone":"America/New_York"}

This is what came back, trimmed to the rising sign, the Moon and the time zone.

John Doe, born Aug 15, 1990, 10:30 AM, New York: the answer, trimmed

{
  "meta": {
    "ayanamsa": "lahiri",
    "ephemeris": "JPL DE440s",
    "timezone": { "zone": "America/New_York", "abbreviation": "EDT", "dst": true, "offset_hours": -4 }
  },
  "ascendant": { "sign": "Virgo", "degree_dms": "19 : 56 : 06", "nakshatra": "Hast", "pada": 3 },
  "positions": [
    { "name": "Moon", "sign": "Taurus", "degree_dms": "24 : 34 : 30", "house": 9, "nakshatra": "Mrigashira", "pada": 1, "dignity": "mulatrikona" }
  ]
}

The lagna (rising sign) is Virgo at 19°56'. The Moon is in Taurus in the 9th house. Its nakshatra (birth star) is Mrigashira. The meta block says New York was on daylight saving time that day, so the API used UTC-4. The full answer lists all 9 planets the same way, with 14 fields each.

The model must turn "New York" into a latitude, a longitude and a time zone name. Ask for the zone name, not a number such as -5. With the name, the API applies the daylight saving rules in force on the birth date.

Write instructions that make the model quote the numbers

The schema tells the model what it can call. The instructions tell it how to behave. OpenAI's guide suggests three parts: context, steps that name each action, and extra notes. Here is a version for a chart bot.

Context: You explain Vedic birth charts. You never work out a chart yourself.

Steps:
1. Ask for the birth date, the exact birth time and the birth place. If the user does not know the time, say the rising sign and houses cannot be known, and do not call a chart action.
2. Turn the place into latitude, longitude and a time zone name such as America/New_York.
3. Call getBirthChart. For periods, call getDashaPeriods. For a plain summary, call getChartSummary.
4. Quote every sign, degree, house, nakshatra and date exactly as the action returns it. Never add a placement the action did not return.
5. Start the answer by repeating the inputs and the UTC offset from meta.timezone.

Notes:
- If an action fails, say so and stop. Never fill the gap with a guess.
- From getChartSummary, quote the text lines and keep their meaning. Mention what each section was read from, given in because.

Step 4 names the fields, so the model knows which words it may not change. Step 5 lets the user catch a wrong place or time zone before reading on. The summary call suits the last note well, because its text uses no astrology terms. On live keys it uses 2 reading credits, while each chart or dasha call uses 1 call.

Check the chart your GPT gives. Our free kundli tool runs on the same chart call. Enter the same birth and compare the rising sign and the Moon.

Set up the action, then test it

The steps below come from OpenAI's GPT Actions docs, read on Oct 13, 2026. On another platform, look for the same three parts.

Add the schema and the key. In the GPT editor, paste the cut schema into a new action. Set authentication to API Key. OpenAI says it stores the key in encrypted form. With an API key, every chat uses your key, so every call counts on your plan. The other choices are None and OAuth, where each user signs in to your service.

Next, test each action. The editor shows a Test button next to each action, with the full input and output. Run getBirthChart for John Doe and check the answer matches the one above. A test key is enough here. Chart calls work on test keys for any birth. Readings, such as the summary, return only for the sample charts, John Doe and Jane Doe.

Then write a short test set. OpenAI suggests 5 to 10 real questions. For a chart bot, add the hard ones. Ask with no birth time. Ask for a summer birth in New York and check that it reports UTC-4. Ask the same question twice and check the planets match.

Plan for errors and limits, too. OpenAI says ChatGPT backs off after several 429 or 500 errors in a short time. A 429 is a "too many requests" answer. Our errors guide lists each code. Calls also time out after 45 seconds.

Tell users about their data. OpenAI notes that a GPT may send parts of the conversation to your action. Our API uses birth details only to work out the answer, and it does not store request bodies. Say both in your privacy notice. Our security page has the details.

If Custom GPTs go away, what carries over

Custom GPTs are due to be retired on Dec 11, 2026. That is the date Virtualization Review gave on Sep 28, 2026, citing OpenAI. The report adds that some accounts and workspaces may see other dates. It also says a Custom Action may need a rebuild, as an app or an MCP server. MCP is a standard way to offer tools to a model. OpenAI's plugin docs describe plugins built on MCP servers and tools.

The work in this post carries over to any of these. Four things stay the same in an action, a plugin or your own chatbot. Keep the list of calls short. Require the birth time. Cap the dasha depth. Tell the model to quote the answer. Only the packaging changes. If you call a model through its API, write each call as a tool in JSON Schema. Our AI assistants guide shows a full tool and the server code that runs it. The AI assistants use case shows which calls suit which questions.

Get the schema you will cut down. The API reference links the OpenAPI document and shows each call with a John Doe example. The dasha API page explains the period timeline the dasha call returns.

The short version

An astrology GPT is only as right as the data it is handed. Take 3 calls from the OpenAPI file, require the birth time, and cap the dasha depth. Then give the model one firm rule: quote the numbers, never make them. The chart then comes from the same calculation every time, and the model's job is to explain it.