Use Roxy as your calculation engine

Treat RoxyAPI as the verified math and breadth layer, and own the interpretation, personalization, and memory yourself. This is the architecture that keeps your product yours and your switching cost low.

The most defensible way to build on any data API is to treat it as infrastructure, not as your product. RoxyAPI is designed for exactly this split: it returns structured primitives, not finished prose, so the calculation and verification are handled for you while the interpretation, voice, and personalization stay on your side. You get the hard part for free and keep the part that actually differentiates your app.

Why structured primitives instead of text

A weak API hands back a paragraph you then have to parse with regex and pray the format never changes. RoxyAPI returns discrete, documented fields you read directly. A daily horoscope, for example, comes back as typed data:

{
  "sign": "Leo",
  "date": "2026-05-22",
  "overview": "The Moon activates your first house of identity and self-expression...",
  "love": "The Moon stirs Leo with deep emotional awareness...",
  "career": "Mars powers up your tenth house of career and ambition...",
  "energyRating": 8,
  "luckyNumber": 41,
  "luckyColor": "Gold",
  "moonPhase": "Waxing Crescent Moon",
  "moonSign": "Leo",
  "compatibleSigns": ["Aries", "Sagittarius", "Gemini"]
}

Your app reads energyRating or compatibleSigns straight off the object. That structure is what lets you build your own experience on top instead of reformatting prose written by someone else.

Own your interpretation layer

The calculations are the same for everyone; the interpretation is your product. Take the structured fields and run them through your own logic: your LLM prompts, your tone, your scoring, your recommendations. This is where retention lives, and it is the one layer no API should own for you.

A typical flow: call the chart or horoscope endpoint, cache the deterministic result (see caching), then synthesize the narrative your users see with your own model and brand voice.

For the visual half of the product, you do not need a frontend specialist who understands natal wheels or kundli layouts. The open-source UI components render charts, kundli, panchang, tarot, numerology, and biorhythm from the API response, so a designer with no insight-domain knowledge is no longer a blocker to shipping.

Normalize into your own schema

The single best defense against lock-in is an adapter. Map the API response into your own internal type the moment it arrives, and let the rest of your app depend on your type, never on the raw response shape.

type Reading = {
  headline: string;
  energy: number;
  themes: { love: string; career: string };
};

function toReading(api: HoroscopeResponse): Reading {
  return {
    headline: api.overview,
    energy: api.energyRating,
    themes: { love: api.love, career: api.career },
  };
}

def to_reading(api: dict) -> dict:
    return {
        "headline": api["overview"],
        "energy": api["energyRating"],
        "themes": {"love": api["love"], "career": api["career"]},
    }

Now your components, prompts, and storage all speak Reading. If you ever change providers or add a second source, you rewrite one adapter, not your whole app.

Keep user data on your side

RoxyAPI stores no end-user data. It computes from the inputs you send and returns a result; there is no profile, no history, no journal kept on our side. That is deliberate, and it works in your favor: your users data and the memory layer that personalizes their experience stay entirely yours, with no third-party processor in the path. To add per-user memory, see build an AI companion with memory.

FAQ

Will I be locked into RoxyAPI?

No more than you choose to be. Because responses are structured, you can normalize them into your own schema with a thin adapter, so your application logic never depends on the raw shape and switching cost stays low.

Should I use the API output directly or wrap it?

Wrap it. Map each response into your own internal type at the boundary so the rest of your app depends on your schema, not the provider format. This is the standard adapter pattern and it pays for itself the first time anything changes.

Where should interpretation logic live?

In your app. Use RoxyAPI for the verified calculations and structured fields, then apply your own prompts, tone, and scoring. The interpretation layer is your differentiation and your retention driver.

Does RoxyAPI keep my users data?

No. The API is stateless and stores no birth data, journals, or profiles. You keep all user state on your side, which keeps you in control of privacy and personalization.

Next steps

Cut repeat calls with caching, add per-user memory in the AI companion tutorial, and browse the full surface in the product catalog.