BIO.RE Developer Portal

The BIO.RE Developer Portal documents every client-facing endpoint of the BIO.RE creator monetization platform. 19 modules, 175 endpoint pages — every claim cited back to the backend code (path:line), every response shape derived from a real DTO, every error code traced to the exception that throws it.

Use the sidebar to browse, the search bar to find a specific endpoint, or the module cards below to jump straight to a section.

Browse by module

Quick start by use case

How to read an endpoint page

Every endpoint page follows the same shape:

1. Header — method + path + scope badge (🌐 Public / 🔑 Bearer / 👤 Admin) + rate limit.
2. Callouts — non-obvious behavior, gotchas, kill switches, vendor abstraction notes.
3. Request — path / query / body / header tables, with class-validator rules preserved.
4. Response — success envelope + every error code with i18nKey.
5. Side effects — DB writes, queued jobs, audit log entries, kill-switch gates, cache invalidations.
6. Code samples — curl + TypeScript fetch + TanStack Query hook (copy-paste ready).
7. Try it — interactive playground with auto-generated cURL/JS/Go/Python/Java/C# samples.
8. Source — path:line references back to the backend code (5-source verify: controller + DTO + service + Prisma + cache/util).

Conventions across the API

• Response envelope — every successful response is { "success": true, "data": T }. Errors are { "success": false, "error": { code, message, i18nKey?, details?, correlationId } }.
• Refresh tokens — set as httpOnly, secure, SameSite=Strict cookie scoped to .bio.re. Browsers send + receive automatically; mobile clients can pass via body.
• Idempotency — mutating endpoints accept Idempotency-Key header where supported; the side-effects table notes which writes are atomic.
• Locales — 20 active locales, error responses include i18nKey for UI mapping.
• Admin-managed providers — every external integration (email, SMS, push, captcha, KYC, payment, OAuth, storage) is selected by admin at runtime. The portal never names the active vendor (e.g., "SendGrid" / "Twilio"); endpoints reference the abstraction (external.email.active_provider, etc.). Frontend reads the abstract token; the backend resolves to whichever vendor is currently active. Stripe is the lone exception — load-bearing infra, not a swappable vendor.
• Two databases — most endpoints write to the main Postgres (@biore/prisma). Analytics tracking endpoints write to a separate Analytics DB (@biore/prisma-analytics) — joins between the two happen in application code.

Machine-readable surfaces