Note on this piece. We do not publish customer-specific data without explicit permission. This article synthesizes patterns from anonymized usage logs and customer conversations across our 2,800+ active developers. Names, regions, and exact numbers have been generalized; the technical patterns and behaviors are real.
When developers ask us "who's actually using this API in production?" the answer breaks down into three repeating profiles. Each one has a different scaling problem, different endpoint mix, and a different reason they ended up with us instead of building Swiss Ephemeris wrappers in-house. Here's what each looks like from our side of the dashboard.
Profile 1: The Mobile Horoscope App
What they build. A consumer mobile app on iOS and Android, free download with a premium subscription tier. Users sign up with their birth date, time, and place, and get a daily personalized horoscope, transit notifications, and a couple of "premium" reports (year ahead, relationship compatibility, career timing) gated behind the subscription.
Where they sit on the dashboard. 50,000 to 200,000 monthly active users is the typical size for this profile. Daily request volume runs 200,000 to 800,000 calls per day depending on subscription mix and how aggressively the app prompts notifications. Most apps in this profile sit on our Business tier ($99/mo for 220,000 requests), with the heavier ones on Enterprise for the dedicated-server SLA.
Endpoint mix.
/p/natal-apiâ called once per user at sign-up, cached forever on the app side. The chart never changes; there's no reason to re-fetch it./p/personalized-horoscopes-apiâ called daily for each active user via a cron job, results stored in the app's database and sent as a push notification at the user's local morning time./p/transit-apiâ used for the "what's affecting me right now" tab. Cached on-device for 6 hours./p/synastry-apiâ used for compatibility reports, charged as a one-off premium upgrade.
What they tell us matters.
- Latency at sign-up flow. If the natal chart call takes longer than one second, sign-up conversion drops. Apps in this profile consistently report onboarding drop-off correlating with the first slow API call. Our sub-300ms response time is the entire reason they switched away from competitors charging $99/mo for slower endpoints.
- Daily cron reliability. They don't care about peak burst capacity. They care about the cron job firing for every user on time, every day. A 0.1% failure rate at 100k users is 100 users with no morning horoscope, which is 100 churn risks.
- AI interpretation quality in nine languages. Apps in this profile usually launch in English, then expand internationally. The fact that our interpretations are professionally localized (not Google Translate) saves them six months of contractor work per language.
What we tell them. Cache the natal chart aggressively. Run the daily horoscope cron in batches of 100 charts per request using our bulk endpoint. Wire transit notifications to our webhook so you only ping users when something real happens, not every six hours blindly. Use the dedicated
/p/personalized-horoscopes-api for daily content rather than reassembling transit data manually â it's tuned for this exact flow.Profile 2: The Wellness or Dating Platform Integration
What they build. Astrology is not the main product. It's a feature inside a wellness, journaling, dating, or coaching platform. Users browse the core app and occasionally hit an astrology surface â a daily moon-phase journal prompt, a compatibility score on a dating profile, a Mars-energy chart for a fitness program.
Where they sit. Smaller user counts on paper (often 5,000 to 50,000 MAU) but the astrology endpoints get hit on-demand by users curious to explore. Daily request volume is bursty, not steady. Most platforms in this profile use our Professional tier ($37/mo for 55,000 requests).
Endpoint mix.
/p/natal-apiâ called once when the user enters birth data, cached./p/synastry-apiâ compatibility between two users, called on-demand in dating contexts./p/horoscope-apiâ daily sun-sign horoscope for users who don't enter birth time./p/astrology-chat-apiâ used as a "talk to your chart" feature in some wellness platforms.
What they tell us matters.
- Optional birth time. Wellness and dating platforms cannot demand that a user knows their exact birth time. Our endpoints accept "unknown time" inputs and return what's possible without it (sign placements, planetary positions, basic transits). Apps in this profile consistently mention this as the deciding factor when comparing us against APIs that require full birth data.
- One-API-key-for-many-features. They don't want to integrate three separate vendors for natal, synastry, and horoscopes. The breadth of our endpoint catalog under one auth token is the main draw.
- Embed-friendly response shape. They want to pass our JSON straight into their existing UI components, not wrap and transform it. Our flat response shape with explicit field names makes this easier than the deeply nested formats some competitors return.
What we tell them. Use the Professional tier; bursty traffic patterns fit well within 55,000 monthly requests. If you spike past 80% utilization for two consecutive months, the dashboard will prompt a Business upgrade automatically. Cache synastry results between user pairs â they don't change once both charts are stable.
Profile 3: The AI Astrology Chatbot
What they build. A conversational interface â sometimes a standalone "virtual astrologer" app, sometimes a Slack or Discord bot, sometimes an integration with a larger conversational platform. The user talks to an LLM (Claude, GPT, or Gemini), and the LLM calls our API behind the scenes to ground its responses in real astrological data instead of hallucinating.
Where they sit. This profile has the widest spread. Hobbyist chatbots run on the free tier (50 requests/month). Production chatbots backed by a real product run on Professional or Business. Some of the larger ones run on
/p/mcp-astrology (our MCP server) so they can plug directly into Claude Desktop or ChatGPT custom GPTs without writing glue code.Endpoint mix.
/p/natal-apiâ cached forever per user once birth data is collected./p/personalized-horoscopes-apiâ for "what's happening today" style questions./p/tarot-apiâ many chatbots add a tarot draw as a secondary feature; users love it./p/astrology-chat-apiâ for direct chart-grounded conversation; this endpoint is specifically tuned for LLM context windows./p/mcp-astrologyâ for Claude Desktop, MCP-compatible IDE integrations, and ChatGPT custom GPTs.
What they tell us matters.
- Context window discipline. LLM context windows are finite. They cannot dump a 30-page natal chart into Claude every turn. Our
/p/astrology-chat-apiendpoint returns a compact summary already shaped for LLM consumption, which keeps token bills down and answers faster. - Latency budget under one second per turn. Most chatbots have a soft target of one-second turn latency. Our API has to fit inside roughly 300ms of that, leaving the rest for the LLM call. Apps that previously used slower 2-3 second astrology APIs report users abandoning conversations mid-flow.
- Cache the natal chart, refresh transits daily. This is the universal pattern. Natal data doesn't change. Daily transit data changes daily. The combination keeps API spend predictable.
What we tell them. Use
/p/mcp-astrology if your bot is going through Claude Desktop or a custom GPT â the protocol handles tool discovery and you don't write integration code. Use the dedicated chat endpoint over manually composing natal + transit responses; the chat endpoint pre-summarizes for LLM consumption and saves you tokens. Cache aggressively.What the three profiles have in common
Three patterns repeat across every profile we see in production:
- The natal chart is cached forever. Nobody recomputes a birth chart on every request. It is the single highest-leverage optimization we recommend to every new customer.
- Daily transit data is refreshed daily, not on every page load. Apps that ignore this advice and call the transit endpoint on every page view run out of their request budget within the first week.
- Latency under 300ms server-side matters more than peak burst capacity. Mobile apps drop off, chatbots feel sluggish, and wellness apps lose users when the API call feels slow. We tune for p99 latency, not average, because the slow-tail user is the user who churns.
Where to learn more
/p/natal-apiâ birth chart foundation, cached once per user./p/transit-apiâ current planetary movement, refreshed daily./p/personalized-horoscopes-apiâ daily personalized horoscope content for mobile./p/synastry-apiâ relationship compatibility between two charts./p/astrology-chat-apiâ LLM-shaped responses for conversational interfaces./p/mcp-astrologyâ Model Context Protocol server for Claude Desktop and custom GPTs./pricingâ current tier breakdown ($0 / $11 / $37 / $99 / $399+).
If your project fits one of these three profiles and you want to validate the architecture before writing code, the free tier covers 50 requests per month â enough to wire up a working prototype, demo it to stakeholders, and decide whether to upgrade.
