Credential vault

The MSP pastes their own keys. Those keys sit in a per-tenant vault. The ISV never holds them. Before keys persist, they check the box on the MSP Connect Terms. We stamp the time. No box, no keys.

Mechanism

ISVs start with a key that looks like blk_… and header X-API-Key. MSP credentials are entered on Bitlync, not in your frontend.

ISV console login

Human console login is passwordless: magic-link and Sign in with Microsoft (Entra OIDC). Same session cookie either way. Invite-only — Microsoft does not open-signup a new seat; the email must already be seated or invited. Live Entra prove needs deployment env (BITLYNC_ENTRA_*); without it, Sign in with Microsoft is not offered. Magic-link stays as the fallback. Machine API stays X-API-Key and never merges with the human session. No production host invented here. Sandbox unchanged. Badge OFF.

What the caller sees

Your product sends X-API-Key. It does not send the MSP’s PSA or RMM secret.

X-API-Key: blk_…

# MSP keys are not in this header.
# They sit in the per-tenant vault.

The ISV does not paste MSP creds. There is no shared-secret path that puts PSA keys in your app.

A sure match auto-maps. A leftover PSA company with no ISV candidate is an ask: Match, company import from PSA, or Skip. Bulk unmatched import is available with dry_run preview. Ambiguous UNMAPPED is a human match. It is never an auto-create.