Description
The Borneo toolkit was pointing every API request to a shared demo tenant — https://demo2.app.borneodata.com/api — instead of the connected customer's own Borneo deployment. Borneo is single-tenant per customer, so this made every action effectively non-functional in production.
Evidence the integration was broken in prod:
| Count |
|---|
auth_configs with toolkit_slug = 'borneo' (Apollo prod) | 275 |
connected_accounts on the borneo toolkit | 498 |
BORNEO_* rows in ClickHouse tool_execution_logs (ever) | 0 |
Auth was succeeding (against each customer's own Cognito), but every subsequent data call was hitting demo2.app.borneodata.com and presumably returning 401/404, so users never got past the first call.
What the fix does
apps/borneo/config.ts
- Adds a
hostUrl strict baseUrl field to the API_KEY scheme (it was already present on the OAuth scheme but unused).
- Replaces the hardcoded toolkit
baseUrl and get_current_user_endpoint with arrow functions that read fields.hostUrl:
baseUrl: (fields) => \${fields.hostUrl}/api``get_current_user_endpoint: (fields) => \${fields.hostUrl}/api/oauth2/userInfo``
This matches the pattern used by accelo, frappe, datadog, n8n, _1password, etc.
openapi/integrations/borneo.yaml
- Both schemes'
proxy.base_url switched from https://demo2.app.borneodata.com/api to {{borneo_dashboard_url}}/api.
- OAuth Cognito
authorization_url / token_url switched from the hardcoded demo2-app-borneodata-com.auth.ap-south-1.amazoncognito.com to {{cognito_domain}}.auth.{{region}}.amazoncognito.com.
- Added the matching
expected_from_customer fields (borneo_dashboard_url on both schemes; cognito_domain and region on the OAuth scheme).
Migration impact (existing connections)
The 275 existing API-key auth configs and 498 connected accounts on the borneo toolkit were created without borneo_dashboard_url. After this PR they will fail validation when invoked (the framework treats required: true strict baseUrl fields as a hard requirement) and customers will need to re-authorize, providing their own dashboard URL.
This is intentional and does not regress any working state — those 498 connections have produced 0 successful tool executions in prod ever (ClickHouse evidence above), because the previous hardcoded demo2 URL never matched the customer's actual tenant. They were already non-functional; this PR makes the failure happen at connection-setup time (with a clear "field missing" message) instead of at first-tool-call time (with a 401/404 from the wrong host).
Codex review (iteration 1) suggested adding a fallback to the prior https://demo2.app.borneodata.com/api to "preserve" existing connections; I dismissed it because the fallback IS the bug — see zen-borneo-dynamic-base-url-r7bvxp-review-history.md for the full rationale.
A separate ops/CX action — Apollo-side data migration or customer outreach — should be coordinated with the toolkit owner for the 275 stale auth configs. That work doesn't belong in this Mercury config change.
How did I test this PR
make validate-config file=apps/borneo/config.ts → ✅ type check + JSON validation passbun run prettier --check apps/borneo/config.ts openapi/integrations/borneo.yaml → ✅nox -s fmt_app -- apps/borneo → ✅ all checks passednox -s chk_app -- apps/borneo → ✅ ruff + mypy clean (157 source files)- Repo-wide
make fmt (39,758 files) → ✅
- Repo-wide
make chk (mypy across 1200+ apps) → ✅ ALL CHECKS PASSED
make snt → all sanity checks pass except a pre-existing action_deletion.py failure on the previously-merged typefully change (unrelated).- Codex review (
codex exec review --base master) → 1 P2 finding, dismissed with documented rationale (see review history file in the PR).
End-to-end execution against a real Borneo tenant cannot be validated from the sandbox (no Borneo test account); E2E will need to be run by Cortex or by a customer with a tenant URL.
@zen-agent