Before the Hub, database credentials sat in 35+ codebases. There was no central visibility, no least privilege, and a schema change could break an app without anyone hearing about it. Onboarding a new app was a manual, multi-day job.
I had already designed the shared 87-table schema. The Hub is what made it safe to share.
POST /api/gateway with an API key and a payload. Here is what happens to it.
The key is validated and the app's status checked. Apps move from pending to configured to active, and promote themselves on their first successful request.
Rate limits and timeouts first, then permissions at the level of the table and the column. An app can be allowed to read a table and still be blocked from one field in it.
The query runs against Supabase, the request is logged with sensitive values stripped, and raw database errors come back as friendly 400 and 409 messages.
Paste a new app's discovery file. The model recommends permissions, you review them, and the Hub generates a complete integration client in JS, TS or Python, plus a prompt to paste back into the app's builder.
A database health audit across the connected apps. Left: what I found. Right: after the fixes.
~400 CHECK failures from 'prod' vs 'PROD'. Zero rows in every junction table. '[object Object]' saved as a UUID.
Five failure classes, a four-section fix-prompt template, and permission gaps closed in four apps.
Two lessons I carry everywhere: a gateway 200 doesn't mean the data is useful, and regressions happen during redeploys.
Twice, on purpose. Bulk sync writes directly: without upsert, a 150-record sync would take 395+ round trips and hit the rate limit, so it writes straight to the database and still logs to the audit table. Analytics reads go direct with a read-only key, because a dashboard needs joins and window functions the gateway doesn't do.
It hit foreign-key violations, because the generator wasn't passing relationship information into the prompt. I fixed it in the generator, once, and every later integration inherited the fix.
Human-written table and column descriptions feed the code generator. That's the difference between knowing a status column is a varchar and knowing it's a deal pipeline stage.
Generation streams over server-sent events with automatic fallback from Anthropic to OpenAI to xAI if a provider fails or truncates.
Need something like this? I build these end to end, as a full-time engineer, on contract, or with SKAI Group.
Book a 30-min callCredentials in every repo? I can map it, gate it and audit it.