Loading…
developer hub
One platform behind Doka USA related apps, consisting of a shared database, a single sign-in, and access rules enforced in the database itself.
Your apps. Sign in to see the app directory and what you have access to.
One account. Accounts are created by invitation; what each person may see is granted per user, per app.
Platform management. Admins manage users, data and the platform itself from this hub.
Joining the waitlist does not create a usable account. An admin approves you in Clerk (who are you), then separately grants database access (what may you see). This hub itself is admin-only.
Privacy Notice · Terms of Use · Doka USA, Ltd.
developer hub
The audit trail: who changed what, and the old → new values. Writes from the terminal or loaders show as owner/CLI. Currently audited: app_users; new tables opt in per migration.
CRM edits queued by app users (change_requests). Apply the change at the source system, then mark it here.
A generated build prompt for wiring this Clerk instance and the Data API into a new app — paste it into Claude Code or Cursor. It embeds the live table reference, the token discipline, the error taxonomy, and the RLS contract, so a new app starts where this hub finished.
Every request: a fresh Clerk token (they live ~60 s) as Authorization: Bearer, plus Accept-Profile: app on reads / Content-Profile: app on writes. Paths are unprefixed. The database decides every row via RLS — send no client-side scope filters. Full details live in the Prompts tab's starter prompt.
Plain http://localhost cannot sign in to the production instance — the origin is rejected, and even allowlisted, browsers drop the session cookie as cross-site (symptom: email accepted, password accepted, then “you are signed out”). Two working paths:
1 · Default: develop against the DEV environment. The dev Clerk instance has no origin restriction — plain localhost on any port works with zero setup, macOS and Windows alike, against the dev branch’s sample data. Switch this hub to DEV (the topbar chip) and the starter prompt embeds the dev keys; build apps with the environment as one config swap.
2 · Production-shape testing: the shared origin https://dev.digitaldoka.com:8443 is allowlisted (exact port — a different port is a different origin). One-time, per machine:
# 1. Point the subdomain at your machine # macOS / Linux: sudo sh -c 'echo "127.0.0.1 dev.digitaldoka.com" >> /etc/hosts' # Windows — PowerShell AS ADMINISTRATOR: Add-Content -Path $env:SystemRoot\System32\drivers\etc\hosts -Value "127.0.0.1 dev.digitaldoka.com" # 2. Trusted local certificate (mkcert: brew install mkcert / winget install FiloSottile.mkcert) mkcert -install mkcert dev.digitaldoka.com # 3. Serve YOUR app over HTTPS on 8443 — static HTML needs no build step: npx http-server . -S -C dev.digitaldoka.com.pem -K dev.digitaldoka.com-key.pem -p 8443 # (Vite: server.https · Next: --experimental-https · keep certs out of git)
Never edit Clerk’s allowed_origins yourself — the Backend API PATCH replaces the whole list and would remove everyone else’s origins; the platform owner maintains it. And hosted previews on bare *.netlify.app URLs fail on the same cross-site cookies as localhost — production deployments need a real digitaldoka.com subdomain (one CNAME).
The generated starter prompts carry this section with the live dev keys and the failure-symptom table baked in.
One form, two moments. While the app is an idea: generate the build prompt (a tailored scaffold for this Clerk instance + Data API, pasted into Claude Code or Cursor). When the app is live: add it to the directory — that registers the entitlement key, makes it grantable in the Users tab, and shows it on everyone’s launcher. Both use the same fields below.
New tables and policy changes are applied by the platform owner through migrations — this builds the request, it does not execute anything. Fill it in, copy, and email it.
The invitation email comes from Clerk; the rights you pick here ride along with it. When they accept and sign up they appear above, prefilled, one click from access. Password resets stay self-serve (“Forgot password” on the sign-in screen).
Field meanings, enforced by RLS and never by an app: rep sees rows matching their extkey · manager sees their branch (exact string) · admin sees everything · apps is the entitlement list. Verify any grant with Preview access in the directory.
The funnel: invitations that have not been accepted yet, then people who signed up but have no database row. Confirm or adjust their rights and grant with one click — rights sent with a hub invitation arrive prefilled.
Everyone with database access. Rights edits and deactivation go through the Data API and are enforced by RLS; ban and sign-out-everywhere act on the Clerk identity through the admin function. Deactivate darkens every table instantly and is reversible; ban blocks sign-in itself. There is deliberately no delete.
Lives in app.app_catalog (migration 016): readable by every signed-in user — the gate shows it as their launcher — and writable by admins right here, audited like every other change. Keys are the app_users.apps entitlement values. Retiring an app is is_active = false; there is deliberately no delete. New apps are added from the Requests tab.
The September “a tool a day” schedule (app.app_releases, migration 020). Each entry is what signed-in users see on their Home tab: a countdown to the next release, the calendar, and an info panel with your write-up and video. Add tomorrow’s tool the day before; it goes live at its release time automatically. Times are shown in your local zone; releases fire at 8:00 AM Central.
Preview it live on the Home tab — you see exactly what a signed-in user sees.
Decoded client-side; the signature is verified by Neon, not here.
No token acquired yet.
Clerk says who you are; this table says what you may see.
The role Postgres actually ran your query as, and the sub it resolved.
Every table, graded against what your app_users row should produce.
Each probe inserts a throwaway row and deletes it. Expected outcomes are shown per step.
Last 50 requests, newest first.
Empty is the correct state.