@bondi-labs/integration-sdk - v0.0.1
    Preparing search index...

    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:

    • Same data center / VPC, no need for adversarial signature validation
    • Bondi already trusts the caller (it IS the caller)
    • HMAC adds latency for no security benefit when both endpoints are inside Bondi's trust boundary

    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 used
    • INTERNAL_API_KEY is used instead (read from env)
    • BONDI_API_URL still required
    • BONDI_WORKSPACE_ID still required (the platform workspace ID)

    External customers don't see this at all. They:

    • Subscribe to platform events (user.registered) by creating workflows in their own workspace
    • The receiver endpoint matches their workspace and fires their workflows

    The 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
    • If somehow set, the request hits /internal/platform-events and is rejected with 401

    In short: don't.