Astrology on Supabase

Readings from your own Postgres. Two Edge Functions, one cache, no key in the browser.

Supabase backend template for astrology readings. Two Edge Functions call the API from Deno with the typed client and no build step, a shared daily reading is cached in your own Postgres so one upstream call serves every visitor that day, and a saved chart is private to the person who asked for it under row level security. The API key lives in a project secret and is read in exactly one file. Includes the optional foreign data wrapper setup for querying endpoints as SQL tables, and a one file demo page that renders both readings through the published components.

AstrologyBackend

What it ships with

One upstream call per sign per day: the cache is read before the API and written after it

Row level security on both tables, one policy per verb, every saved chart keyed to its owner

The key is a project secret read in one file, never in a table and never in the browser

Birth city resolved to coordinates and an IANA timezone, so a January and a July birth differ

Optional: query any endpoint as a Postgres foreign table and cache it in a materialized view

README

Serve astrology readings from your own Supabase project. Two Edge Functions call RoxyAPI, Postgres caches the shared daily readings and keeps private charts under row level security, and the API key never leaves a project secret. One API key covers 18+ insight domains, every calculation verified against NASA JPL Horizons. MIT, so rebrand it and ship it.

What you get

Piece	What it does
`daily-horoscope`	Reads the cache first. On a miss it calls the API once, stores the row, and every later reader that day is served from your database
`natal-chart`	Resolves a birth city to coordinates and an IANA timezone, casts the chart, and saves it only for a signed-in caller
`daily_reading`	Shared cache, readable by anyone, writable only by the service role
`saved_chart`	Private, one policy per verb, every row keyed to `auth.uid()`
`demo/index.html`	One page, no framework, renders both through the published web components

Quickstart

supabase secrets set ROXY_API_KEY=your_key_here
supabase link --project-ref your-project-ref
supabase db push && supabase functions deploy

Get a key at roxyapi.com/pricing. To run it locally instead, supabase start then supabase functions serve, and open demo/index.html.

Endpoints it calls

Endpoint	Used by
`GET /astrology/horoscope/{sign}/daily`	`daily-horoscope`
`GET /location/search`	`natal-chart`, to resolve the city
`POST /astrology/natal-chart`	`natal-chart`

Every other domain is one more function on the same pattern. The domain guides say which endpoint answers which question.

How it looks

Light	Dark

Stack

Part	Version
Supabase Edge Functions	Deno 2
Typed client	`@roxyapi/sdk` 1.x, imported with an npm specifier, no build step
UI components	`@roxyapi/ui` from the CDN, used in controlled mode so no key reaches the browser
Database	Postgres with row level security on both tables

Where the key lives

In a project secret, read inside a function with Deno.env.get. It is never in a table, never in the demo page, and never in a variable a browser can read. Browser code that has to call the API directly uses a publishable key locked to your origin: see widgets.

Docs

Start with AGENTS.md, which routes to the rest.

Read	For
docs/database.md	the schema, the policies, the cache
docs/functions.md	what each function does
docs/deploy.md	deploying and running it locally
docs/sql.md	querying the API as SQL instead
docs/code.md	architecture, tests, the checks

Built with RoxyAPI

One key, 18+ insight domains, typed SDKs in five languages, Remote MCP for agents, and flat pricing with every domain included. Pricing . Docs . Remote MCP . Methodology . Templates

License

MIT. Clone it, rebrand it, and ship it under your own brand.