Bbizbasics/ developers

Onboarding — from submission to live

The end-to-end path to get a product onto the platform. Some steps are yours (the developer); some are the platform team's. You never need the platform's secrets — only your own scoped credentials.

The sequence

  1. Submit your app (you) — sign in to app.bizbasics.ai → Developer, create a submission (name, slug, description, your frontend_url and api_url — placeholders are fine), then Submit for review. Lifecycle: draft → submitted → in_review → approved.
  2. Review & approve (platform team) — moves the submission submitted → in_review → approved with your product_slug, which registers it in the catalog (lifecycle: sandbox, not customer-visible).
  3. Provision infra (platform team — a separate step from approval) — one call creates your namespace, Postgres (CNPG), MinIO bucket + service account, Redpanda topics, Deployment, Ingress, NetworkPolicies, HPA, PDB, and a <slug>-secrets secret pre-filled with the env below.
  4. Issue your credentials (you) — once approved, from Settings → SSO credentials generate a bbas_…, and from Settings → API keys a bbk_… bound to your product (read + write). Each is shown once — copy it.
  5. Build (you) — start from the scaffold; implement the SSO contract (verify bb_at via JWKS) and follow the Runtime contract (ports, health, image names, sessions — the things that bite people).
  6. Deploy (you) — push your image; the platform Deployment pulls it on the next rollout. (The image push path is confirmed with the platform team during onboarding.)
  7. Go live (platform team) — advance lifecycle sandbox → internal → beta → ga and flip visibility when you're ready for customers.

Your credentials

CredentialUsed forWhere
bbas_…Platform internal endpoints (verify-app-token, silent-sso, quota, webhooks) — sent as X-Internal-Key. Scoped to your product.Settings → SSO credentials
bbk_…The data API (workspace records, quota status) — sent as Authorization: Bearer.Settings → API keys
APP_SESSION_SECRETSign your own product session cookie. ≥32 random bytes.You generate it

Environment the platform injects into <slug>-secrets

DATABASE_URL, REDIS_URL, MINIO_ACCESS_KEY, MINIO_SECRET_KEY, MINIO_BUCKET   # per-product, scoped
BIZBASICS_API_URL    = https://api.bizbasics.ai
BIZBASICS_AUTH_URL   = https://auth.bizbasics.ai
BIZBASICS_JWKS_URL   = https://auth.bizbasics.ai/.well-known/jwks.json
BIZBASICS_PRODUCT_ID = <slug>
APP_URL              = https://<slug>.bizbasics.ai   # your public base URL — use it for
BIZBASICS_APP_URL    = https://<slug>.bizbasics.ai   # redirects (post-SSO landing) + links; never hardcode localhost

You add your bbas_, bbk_ and APP_SESSION_SECRET. Your service runs at https://<slug>.bizbasics.ai with the API at /api, on cookie domain bizbasics.ai — so it receives the bb_at cookie directly.

You are never issued the platform's JWT signing secret or a shared internal key. Identity is verified locally via JWKS; API calls use your scoped bbas_/bbk_. There is nothing to ask the platform team for beyond the steps above.
© bizbasics — developer platform All systems operational