Platform API vs SIS
Sumvin exposes two distinct API surfaces. The Platform API is what a consumer app calls on behalf of a user — create a user, run KYC, manage wallets and cards, kick off an IPA. The Sumvin Identity Service (SIS) is what a verifier calls when a user’s credential lands on its doorstep — exchange a signed PINT, fetch JWKS, check revocation, look up user data by SRI. You pick the surface by the job you’re doing, not by the user you’re acting for.What each surface owns
| Surface | Owns | Typical caller |
|---|---|---|
| Platform API | Users, onboarding state, KYC, wallets (EOA + Safe), IPAs, cards, strategies, transactions | Partner backend acting on behalf of an authenticated user |
| SIS | PINT exchange, JWT issuance, JWKS, revocation, SRI-to-user lookup, dashboard auth config | Verifier backend, or any service receiving a PINT JWT |
Where they meet
A user created via the Platform API is identified system-wide by their SRI. Their signed PINTs are exchanged for JWTs at SIS. The JWT’ssub claim is the same SRI the Platform API uses — the two surfaces are joined at the identity layer, not at the transport layer.
Which one am I calling
- Building a consumer app that onboards and authenticates its own users → Platform API.
- Receiving a credential from a user’s browser or agent on inbound requests → SIS (verifier role).
- Federating your own auth provider (Dynamic, Privy, SIWE) into Sumvin’s identity graph → SIS Dashboard.
x-juno-jwt from your auth provider; SIS uses a partner-issued API key. See Auth model for the full matrix.
See also
- Platform map — the visual version of this split
- Sumvin Identity overview — why SIS exists
- Auth model — which credential goes where