Skip to main content
Runtime identity is not an API-key Developer API surface. The endpoints that start and complete a login are public IdP routes, called by the end user’s browser or app, not by your server with a Swig API key. This page exists to mark that boundary so you do not wire identity into a server-to-server integration where it does not belong.

​
Who owns identity integration

The IDP SDK owns identity integration guidance: OAuth, email OTP, SMS OTP, session handling, and how a completed login becomes a Swig session.
The currently published IDP SDK defaults still target retired /identity/api/* routes and its endpoint model does not fully represent the public OTP and setup contract below. Treat the route table on this page as the current backend contract until the IDP SDK is refreshed.
Once a user has a session, the Developer SDK picks it up:
TypeScript
That handoff is the only place identity and the Developer SDK meet.

​
Public IdP routes

These routes are public. They are listed here as the current backend contract. The JWKS routes are what you use to verify identity tokens server-side.

​
Why this matters

  • Do not send a Swig API key to these routes. They are not API-key guarded, and doing so leaks a server credential into a client-facing call path.
  • Do not model login as a server-to-server call. The user’s client completes the flow; your server verifies the result.
  • Identity client and organization-provider configuration is a developer-portal admin flow, not a runtime endpoint.

​
What is not here

There is no /identity/api/auth/passkey/start route. If you have an integration pointed at that path, it is targeting an endpoint that does not exist in the current backend.

​
Where to go instead

IDP SDK

OAuth and OTP login flows that create Swig sessions

Server Runtime Model

API credentials, prepared transactions, and the application-owned signer boundary