Skip to main content
SIS uses a federated identity model: every Sumvin user has a portable identity (carried on the wire as their Sumvin Resource Identifier, or SRI) regardless of which embedded wallet provider issued their wallet. Configuring your auth provider tells SIS how to validate the JWTs your users carry.

​
The Validation Flow

When your app resolves a user’s identity on their behalf: 
1. User signs in to your app via Dynamic or Privy
2. Provider issues a JWT to the user's browser
3. Your app calls the Platform API, passing the JWT in the `x-juno-jwt` header
4. The Platform API validates the JWT against your configured provider credentials for that environment
5. It resolves the user's Sumvin Resource Identifier (SRI) and returns identity data
The x-juno-jwt header carries the provider JWT to the Platform API (api.sumvin.com). Direct calls to the SIS API authenticate with your API key via the Authorization: Bearer header instead. Each step depends on your environment’s auth configuration being set up correctly. If the credentials don’t match the provider that issued the JWT, validation fails.

​
Why Credentials Are Per-Environment

SIS needs to know which provider public key to validate JWTs against. Separating credentials per environment:
  • Prevents cross-environment leakage — a development JWT can’t authenticate against your production environment
  • Lets you test provider credential rotations in staging before production
  • Gives you an audit trail per environment

​
Supported Providers

ProviderAuth Method
DynamicEnvironment ID + Public Key (JWK)
PrivyApp ID + Verification Key
Only one provider can be active per environment at a time. See Auth Provider Setup for the full configuration steps.

​
What SIS Returns

After successful JWT validation, SIS resolves and returns:
  • The user’s SRI (Sumvin Resource Identifier) — their stable identity across all providers
  • Identity data associated with the SRI: KYC status, wallet addresses, and verification claims
See the SIS API Reference for the full response schema.

​
Verification Tiers

Third-party integrators operate at one of two verification tiers depending on the scopes they access. Standard integrations receive a JWT with identity attestation. Enhanced integrations (those processing spend authorisation) additionally receive the cryptographic (a PINT signature, user- or agent-signed) for independent verification. See the Verification Tiers guide for the complete reference on integration requirements per tier.