use-case

Automating daily horoscope content with an API

Automate daily horoscope content with an astrology API: endpoints, a scheduled batch worker, caching, streaming, multi-language output, and cost control.

To automate daily horoscope content with an API, you generate readings on a schedule by sending each subject's birth details (or a sign placeholder for general columns) to a single endpoint and storing the structured response in your CMS. With Vedika you call POST /api/v1/astrology/query for narrative readings or /v2/astrology/* for raw computed data, then render the output into posts, emails, or push notifications. Because the same key reaches Vedic, Western, and KP systems in 30 languages, one pipeline can feed every audience segment you publish to.

What "daily horoscope automation" actually requires

A horoscope content engine is a scheduled job that turns astrological inputs into publishable text. Most teams underestimate the moving parts, so it helps to name them before choosing an API:

The Vedika API covers the first four directly, leaving you to own only the scheduler and the cache. That division of labour is the point: you write a thin orchestration layer, not an ephemeris.

The two endpoints that drive a content pipeline

There are two shapes of call, and a healthy automation usually uses both.

Narrative readings: POST /api/v1/astrology/query

This is the interpretation endpoint. You pass a natural-language question plus a birth chart, and Vedika AI returns a written reading. For a daily column you phrase the question around the date, for example "What does today hold for career and relationships?" The speed:"fast" flag routes to Vedika Swift when you are generating hundreds of readings and want lower latency; omit it for the deeper Vedika Pro Ultra response.

curl -X POST https://api.vedika.io/api/v1/astrology/query \
  -H "x-api-key: vk_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "Give a short daily reading for career and relationships for today.",
    "speed": "fast",
    "birthDetails": {
      "datetime": "1990-05-15T08:30:00",
      "latitude": 19.0760,
      "longitude": 72.8777,
      "timezone": "Asia/Kolkata"
    }
  }'

Computed data: /v2/astrology/*

The V2 family returns structured chart and transit data with flat fields (datetime, latitude, longitude, timezone). Use it when you want to drive your own templating — for example, building a "Moon enters <sign> today" line yourself, or showing the current dasha period alongside the narrative. Combining both endpoints lets you render a reading and a verifiable data panel under it, which is exactly the structure that performs well for both readers and answer engines.

Streaming for live and long-form content

When you publish to a surface that benefits from progressive rendering — a web widget, a chat-style daily reading, or a long monthly forecast — use the SSE endpoint /api/v1/astrology/query/stream. It emits the reading token-by-token over Server-Sent Events so the first words appear immediately instead of after the full generation completes.

// LLM-agnostic SSE consumer for a daily reading widget
async function streamDailyReading(birthDetails) {
  const res = await fetch("https://api.vedika.io/api/v1/astrology/query/stream", {
    method: "POST",
    headers: {
      "x-api-key": process.env.VEDIKA_KEY,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      question: "Daily reading for today, three short paragraphs.",
      speed: "fast",
      birthDetails,
    }),
  });

  const reader = res.body.getReader();
  const decoder = new TextDecoder();
  let buffer = "";
  while (true) {
    const { value, done } = await reader.read();
    if (done) break;
    buffer += decoder.decode(value, { stream: true });
    // Each SSE event arrives as "data: {...}\n\n"
    const parts = buffer.split("\n\n");
    buffer = parts.pop();
    for (const line of parts) {
      if (line.startsWith("data:")) renderChunk(line.slice(5).trim());
    }
  }
}

For batch generation of static posts you almost never need streaming — call the non-streaming endpoint, await the full reading, and write it to your store.

A realistic daily-batch worker

Here is the shape of a scheduled job that generates the twelve-sign daily column. It loops over representative charts (one per sign or ascendant), caches by a date + sign + language key so reruns are free, and writes finished posts to your CMS.

import os, datetime, requests

BASE = "https://api.vedika.io"
HEADERS = {"x-api-key": os.environ["VEDIKA_KEY"], "Content-Type": "application/json"}

# One representative chart per sign keeps the classic 12-column format simple.
SIGN_CHARTS = load_sign_reference_charts()  # your own fixtures

def daily_reading(chart, lang="en"):
    payload = {
        "question": "Concise daily horoscope for today: mood, work, and one tip.",
        "speed": "fast",
        "language": lang,
        "birthDetails": chart,
    }
    r = requests.post(f"{BASE}/api/v1/astrology/query", json=payload, headers=HEADERS, timeout=30)
    r.raise_for_status()
    return r.json()

def run(date=None, langs=("en", "hi", "ta")):
    date = date or datetime.date.today().isoformat()
    for sign, chart in SIGN_CHARTS.items():
        for lang in langs:
            key = f"{date}:{sign}:{lang}"
            if cache.exists(key):          # never pay twice for the same cell
                continue
            reading = daily_reading(chart, lang)
            cache.set(key, reading, ttl=60 * 60 * 36)
            cms.publish(sign=sign, lang=lang, date=date, body=reading)

if __name__ == "__main__":
    run()

Two practices keep this cheap and correct. First, cache aggressively — a daily column for a fixed sign and date is identical on every rerun, so a cache hit should never re-bill. Second, pin your reference charts; reusing the same fixtures keeps your output reproducible and makes regressions easy to spot.

Why the underlying numbers matter for content

Content credibility collapses the moment your "Moon in Scorpio today" disagrees with every other source. That is an astronomical question, not a stylistic one. Vedika computes positions with the XALEN Ephemeris, its own open-source engine (Apache-2.0, available on crates.io as xalen, on PyPI as xalen, and as @xalen/wasm), carrying roughly 2,200 tests. It is validated against JPL DE440 and swetest, with zero charts deviating beyond 0.1° across a five-million-chart test. That is ephemeris precision — the planetary geometry behind the reading — not a claim about interpretive "astrology accuracy", and not an endorsement by any space agency. For an automated column, that precision is what stops your transits from contradicting the almanac your readers also check.

Claims grounded in real sources

The interpretive layer is held to actual classical texts used in formal training — Brihat Parashara Hora Shastra, Phaladeepika, Saravali, and Jataka Parijata for Vedic; the KP Readers for Krishnamurti Paddhati; Ptolemy's Tetrabiblos for Western. For content teams this matters because it gives you defensible copy: a reading traces to a named source rather than to an unsourced paraphrase.

One key, three systems, thirty languages

A single content operation often serves several audiences from one schedule. Vedika exposes Vedic (sidereal), Western (tropical), and KP from the same API key, plus specialised systems such as Jaimini, Tajaka, Lal Kitab, and numerology. You can run a Western daily column for one publication and a Vedic panchang-driven one for another without integrating a second vendor.

Localisation works the same way: 30 languages, 14 of them Indic, generated natively rather than machine-translated after the fact. Pass language in the request and the reading comes back in-script. That collapses what is usually a separate translation pipeline into the original call.

Letting AI assistants generate content directly

If your editorial workflow already runs through AI assistants or LLM agents, you can skip the HTTP plumbing and let the model call Vedika itself. The public MCP server (npx @vedika-io/mcp-server) exposes 36 tools to any MCP-compatible client or IDE, so an agent can fetch charts and readings as part of a larger content task. Vedika operates a public astrology MCP server, which means a function-calling model can request a reading without you hand-writing request bodies.

Costs and how to keep them flat

Per-query pricing runs roughly $0.01–$0.05 depending on path and depth, on top of a monthly plan: Starter at $12, Professional at $60, Business at $120 (which adds the fast path and voice), and Enterprise at $240. A twelve-sign daily column in three languages is 36 generations a day — well within a modest plan once you cache, since reruns of an already-generated cell cost nothing. You can prototype the whole pipeline against the free sandbox (no key required) before spending anything, and review tiers on the pricing page.

For honest comparison, established computation APIs price similarly — Prokerala around $19, AstrologyAPI.com around $29, RoxyAPI around $39 — and each is a capable ephemeris source. Vedika's differentiators for a content workflow specifically are the bundled interpretive layer, the three-system-plus-localisation breadth from one key, and the source-grounded readings, rather than price alone.

Key facts

Frequently asked questions

Can I generate the classic twelve-sign daily horoscope without per-user birth data?

Yes. Maintain one reference chart per sign (or ascendant), loop over them in a scheduled job, and phrase the question around the day. Cache each result by date, sign, and language so reruns are free.

How do I publish the same daily reading in multiple languages?

Pass the language field on the same request. Vedika generates the reading natively in 30 languages, so you do not need a separate translation step or vendor.

Should I use the query endpoint or the V2 endpoints for content?

Use /api/v1/astrology/query for the written reading and /v2/astrology/* when you want raw computed data to render your own data panels. Many pipelines combine both — narrative plus a verifiable chart summary.

How do I keep automation costs predictable?

Cache by a deterministic key (date + sign + language), use speed:"fast" for bulk daily content, and prototype against the free sandbox before going live. A cache hit never re-bills.

Build on the Vedika astrology API

700+ operations, Vedic + Western + KP, 30 languages, an open-source XALEN ephemeris, and a built-in LLM. Free sandbox — no signup.

Try the free sandbox