internalMode (Bondi-only)internalMode: true in BondiModule.forRoot (or createBondiClient) routes trigger emits to a different endpoint protected by an internal API key instead of the public HMAC endpoint.
This option exists for Bondi's own dogfood usage. External customers should NOT enable it — it requires INTERNAL_API_KEY, which only the Bondi platform itself possesses.
When Bondi's own NestJS API uses the SDK to emit platform events (user.registered, subscription.created, etc.), making round-trip HMAC-signed calls to itself is wasteful:
So Bondi's internal BondiClient posts emits to POST /internal/platform-events with a shared INTERNAL_API_KEY header, skipping HMAC entirely.
BondiModule.forRoot({
integration: { name: "Bondi Platform", slug: "bondi-platform", category: "platform" },
triggers: [...],
internalMode: true,
// No `token` needed — uses INTERNAL_API_KEY
// workspaceId still needed — events go to Bondi's own platform workspace
})
When internalMode: true:
BONDI_INTEGRATION_TOKEN is NOT usedINTERNAL_API_KEY is used instead (read from env)BONDI_API_URL still requiredBONDI_WORKSPACE_ID still required (the platform workspace ID)External customers don't see this at all. They:
user.registered) by creating workflows in their own workspaceThe internal/external distinction is just about how the EMITTER (Bondi itself) authenticates — not about who can receive events.
If you set internalMode: true in a customer integration:
INTERNAL_API_KEY won't be set in your env → dryRun auto-enables → emits silently log instead of firing/internal/platform-events and is rejected with 401In short: don't.