RoxyAPI UI

Yes. RoxyAPI UI is the official MIT licensed component library for insight and prediction apps. It ships drop-in web components for every RoxyAPI domain: natal charts and synastry wheels, Vedic kundli, panchang tables and dasha timelines, transit forecast timelines, Human Design bodygraphs, BaZi charts and luck pillars, flying star charts and kua cards, Mayan day signs, Vastu mandalas, numerology cards, gematria, tarot daily cards and spreads, biorhythm, dosha constitutions, I Ching hexagrams, crystal and dream cards, and angel numbers.

Two lines and no build: load widgets.js from jsDelivr and drop a <div data-roxy-widget="natal-chart"> with your publishable key. The widget draws the birth-data form and the chart in the browser. To keep every key on your server instead, fetch with @roxyapi/sdk and assign the response to the data property of a <roxy-natal-chart>, or inline it as a JSON island for a server-rendered page. Works in plain HTML, Squarespace, Wix, Shopify themes that allow custom code, and any modern browser. On WordPress the official plugin at wordpress.org/plugins/roxyapi renders the same components server-side, and the gallery at roxyapi.com/widgets fills a snippet for every widget with your key.

Yes. <roxy-vedic-kundli> draws the North or South Indian chart, <roxy-panchang-table> the five limbs of the day, <roxy-dasha-timeline> the Vimshottari periods, and the Vedic set continues through divisional charts, ashtakavarga, shadbala, gochara, KP tables and Guna Milan matchmaking. Each one takes the matching API response as data, or fetches for itself on a publishable key inside the one-tag widget. Readings arrive translated, Hindi included, through the lang attribute.

Yes, every domain in the RoxyAPI catalog has components, and a new domain joins the demo with its release. Human Design has the bodygraph, type card, connection and penta charts; Chinese astrology the BaZi chart, luck pillars, zodiac card and almanac day; feng shui the flying star chart and kua card; Mesoamerican astrology the Mayan day sign; Vastu the mandala; Kabbalah gematria; Ayurveda the dosha constitution. Filter the live demo above by domain to see each one on sample data.

Yes. The @roxyapi/ui-react package ships typed React components for every entry in the catalog. Vue, Svelte, Angular, Solid, Astro, and Qwik consume the same Lit web components natively, no extra install required.

Yes. Every component is published to a shadcn-compatible registry. Install with npx shadcn@latest add https://cdn.jsdelivr.net/gh/RoxyAPI/ui@latest/registry/natal-chart.json. The source lands in your repo for full ownership and Tailwind-friendly theming. Map a namespace in your components.json to skip the URL on every install:

{
  "registries": {
    "@roxyapi": "https://cdn.jsdelivr.net/gh/RoxyAPI/ui@latest/registry/{name}.json"
  }
}

Then npx shadcn@latest add @roxyapi/natal-chart. Pairs cleanly with the button, card, and dialog primitives shadcn ships, in the same app.

Yes. RoxyAPI ships a Remote MCP server per domain (Streamable HTTP, no local setup). The same JSON shape your agent receives over MCP feeds straight into the matching component data prop. See roxyapi.com/docs/mcp for the full setup.

Yes, and it is what the tool-result helper exists for. Your model calls a Remote MCP tool at roxyapi.com/mcp/{domain} and hands back a tool name and a JSON string. componentForTool(name) turns that name into the component that draws it, so the reply carries a real natal chart, kundli or tarot spread instead of a wall of fields. It works in any chat UI that renders your own markup for a tool result.

The helper ships inside @roxyapi/ui, @roxyapi/ui-react and @roxyapi/ui-vue, so whichever package you already installed has it. Full recipe: roxyapi.com/docs/tutorials/ai-chat-widgets.

A language model should never draw a chart. It should call a tool and hand the result to something that already knows how to draw it. That is generative UI: the model picks the tool, your interface picks the component. Every component here is a stateless data consumer and a tool result is the same JSON the SDK returns, so the one piece your app supplies is the map from the tool name to the component. Worked example: render astrology charts from LLM tool calls.

Any chat UI that lets you return your own markup for a tool result, because the render slot is ordinary JSX and the component is an ordinary element. That covers the Vercel AI SDK, assistant-ui, CopilotKit, AI Elements, and a hand-rolled React, Vue, Svelte, Angular or Solid interface. Plain HTML works with no build step: load the script tag, create the element the binding names, set data.

Vendor hosted connectors from Anthropic, OpenAI and Google change only where you read the tool name and the result text from, never the lines that follow. Each one is written out in the chat widget tutorial.

No, leave it on. Every component decodes the compact shape on the way in, so you keep the lower token cost per turn and still pass the tool result straight through with no preprocessing of your own. If your own code wants the plain object, expandCompact is exported from all three packages.

One call. componentForTool('post_astrology_natal_chart') returns tag, pascal, operationId and attrs. tag is the custom element for plain DOM, pascal is the export name in the React and Vue packages, and attrs is present when one component covers several tools and needs an attribute to tell them apart.

A name a host prefixed with its server, such as roxy_tarot:post_tarot_daily, resolves the same as a bare one. A tool nothing draws returns undefined, so a bot that calls a reference lookup keeps answering in prose instead of breaking.

Readings come back from the API in the language you pass as lang: English, Turkish, German, Spanish, Hindi, Portuguese, French, Russian, and Simplified and Traditional Chinese. The labels the components draw themselves, headings, buttons and form fields, ship as one small file per language for German, Spanish, French, Hindi, Portuguese, Russian and Turkish, loaded with a single script line; English needs none. A one-tag widget on a page that declares its own lang follows it with no configuration.

As accurate as the API, because a component computes nothing of its own. Every position, house, dasha and score is calculated by RoxyAPI on Roxy Ephemeris, verified against NASA JPL Horizons, and the components draw exactly the response they receive, so what your visitor sees is the API result, not a re-computation. The verification method and the published test corpus are at roxyapi.com/methodology.

Every component and widget renders under your brand alone, with your colours through the theme tokens. The one piece of RoxyAPI branding, a small credit line linking back to roxyapi.com under a reading, is a switch you control on every path: the attribution attribute on a component tag, data-attribution on the one-tag widget, and attribution=on on a hosted embed URL from roxyapi.com/widgets. Turn it on where you want to name your source, off where you do not.

The components are MIT licensed and free to use, modify, and redistribute. Rendering live data requires a RoxyAPI key: every plan covers every domain and every component under one key on a flat price. Try the calls in the API reference first, then pick a plan at roxyapi.com/pricing.

Override CSS custom properties on the root or per element. One set of design tokens covers color, typography, spacing, radius, shadow, and motion. Your own declaration always wins, including from inside a Tailwind or shadcn layer, so no extra selector weight and no !important. The Customize Colors panel above generates the override CSS for you.