SDK and API coverage
Use this page when you are choosing how to integrate Switera into an application or backend service. The matrix reflects the packages that exist in the current repository and the launch API families exposed by the Switera API.
Integration paths
| Integration need | Recommended path | Notes |
|---|---|---|
| Browser or framework authentication | @switera/auth plus a framework adapter | Best for hosted login, OAuth callback handling, sessions, MFA, SSO, passkeys, OTP, and magic links. |
| Trusted backend automation | Go, Python, PHP, Ruby, or direct REST | Use an app-scoped secret key from your backend only. Do not ship secret keys to browsers or mobile apps. |
| Embedded sign-in UI | @switera/widgets | Use for a small hosted-auth surface inside a builder-owned app. |
| Mobile app authentication | React Native, Flutter, Android, or Swift packages | Mobile packages are launch scaffolds unless noted otherwise below. |
| AI-assisted platform operations | MCP packages | Use only in controlled developer environments with least-privilege tokens. |
| Unsupported language or full route coverage | Direct REST | The generated reference in docs/api-docs tracks the current backend route surface. |
SDK package matrix
| Package | Runtime | Launch status | Covered surface |
|---|---|---|---|
@switera/auth | Browser TypeScript | Ready for Auth launch flows | OAuth2/PKCE, hosted auth redirects, session state, profile, MFA, SSO/LDAP, passkeys, OTP, magic links, invitations, metadata, privileged sessions, browser Search, current-user Feature Flags, and Realtime token helpers. |
@switera/auth-react | React | Ready for Auth launch flows | Provider, hooks, guards, sign-in/sign-up components, user and organization components, current-user Feature Flags. |
@switera/auth-nextjs | Next.js | Ready for Auth launch flows | Server auth helpers, middleware, route protection, shared browser auth client exports. |
@switera/auth-node | Node.js servers | Ready for Auth launch flows | Express, Fastify, Hono, and token introspection helpers. |
@switera/auth-svelte | Svelte | Ready for Auth launch flows | Provider, guards, signed-in/signed-out helpers, user auth state, current-user Feature Flags. |
@switera/auth-vue | Vue | Ready for Auth launch flows | Vue auth adapter around the core browser client. |
@switera/auth-angular | Angular | Ready for Auth launch flows | Angular auth service and route guards. |
@switera/widgets | Browser widgets | Partial launch support | Login, signup, user button, and organization switcher widgets. |
github.com/switera/switera-go | Go backend | Broad launch backend coverage | Users, organizations, auth settings, SSO, FGA, Vault, audit logs, auth hooks, managed Email, customer Webhooks, directory sync, sessions. |
switera | Python backend | Broad launch backend coverage | Users, organizations, auth settings, SSO, FGA, Vault, audit logs, auth hooks, managed Email, customer Webhooks, directory sync, sessions. |
switera/sdk | PHP backend | Broad launch backend coverage | Users, organizations, auth settings, SSO, FGA, Vault, audit logs, auth hooks, managed Email, customer Webhooks, directory sync, sessions. |
switera | Ruby backend | Broad launch backend coverage | Users, organizations, auth settings, SSO, FGA, Vault, audit logs, auth hooks, managed Email, customer Webhooks, directory sync, sessions. |
com.switera:switera-java | Java backend | Scaffold | Package metadata and baseline HTTP dependencies exist; route resources are not launch-complete. |
Switera | .NET backend | Scaffold | Package metadata exists; route resources are not launch-complete. |
@switera/react-native | React Native | Partial launch support | Mobile auth package scaffold with typed entrypoint. |
switera | Flutter/Dart | Scaffold | Package metadata and mobile auth dependencies exist. |
com.switera.sdk | Android/Kotlin | Scaffold | Library package metadata and mobile auth dependencies exist. |
Switera | Swift | Scaffold | Swift package manifest exists. |
@switera/mcp-server | MCP | Partial launch support | Platform administration helper for controlled developer environments. |
@switera/mcp-context | MCP | Partial launch support | End-user context provider for AI assistant integrations. |
Product API coverage
| Product area | REST API | Go | Python | PHP | Ruby | Browser/framework auth SDKs | Notes |
|---|---|---|---|---|---|---|---|
| Auth, sessions, hosted login | Yes | Partial | Partial | Partial | Partial | Yes | Browser/framework SDKs are the main path for end-user auth. Backend SDKs cover admin/user/session surfaces. |
| Users and organizations | Yes | Yes | Yes | Yes | Yes | Limited | Use backend SDKs for admin workflows and tenant management. |
| SSO and directory sync | Yes | Yes | Yes | Yes | Yes | SSO login helpers only | Backend SDKs manage provider configuration; browser SDKs start login flows. |
| MFA, passkeys, OTP, magic links | Yes | Limited | Limited | Limited | Limited | Yes | End-user ceremony helpers live primarily in browser/framework SDKs. |
| FGA | Yes | Yes | Yes | Yes | Yes | No | Backend-only launch surface. |
| Vault | Yes | Yes | Yes | Yes | Yes | No | Backend-only; keep key and payload workflows off browsers. |
| Yes | Yes | Yes | Yes | Yes | No | Managed Email config, route test, workflow test-run, runtime, suppressions, and previews are backend/admin workflows. | |
| Customer Webhooks | Yes | Yes | Yes | Yes | Yes | No | Backend SDKs cover endpoints, event catalog, delivery history, replay, test sends, and emits where implemented. |
| Billing | Yes | Direct REST | Direct REST | Direct REST | Direct REST | No | Public docs cover the launch routes; typed SDK resources are still later work. |
| Storage objects | Yes | Direct REST | Direct REST | Direct REST | Direct REST | No | Use the REST API and examples until typed SDK resources land. |
| Managed Data | Yes | Direct REST | Direct REST | Direct REST | Direct REST | No | Use the REST API and examples until typed SDK resources land. |
| Search | Yes | Yes | Yes | Direct REST | Direct REST | Tenant token/query helpers | Go and Python cover trusted server-side indexes, documents, and queries. Browser auth SDKs cover short-lived tenant token issuance and browser-safe query. |
| Feature Flags | Yes | Yes | Yes | Direct REST | Direct REST | Current-user evaluation | Go and Python cover trusted server-side flag CRUD and evaluation. Browser/framework auth SDKs evaluate flags for the signed-in user without exposing a secret app key. |
| Realtime | Yes | Direct REST | Direct REST | Direct REST | Direct REST | Connection/subscription token helpers | Browser auth SDKs issue signed tokens for the current user. Server-side publish SDK wrappers are still later work. |
| API keys and usage | Yes | Direct REST | Direct REST | Direct REST | Direct REST | No | Trusted backend calls can use REST for key controls and usage rollups. |
Generated API reference
The repository includes a generated Markdown reference under docs/api-docs, refreshed from src/api/docs/swagger.json. It is useful for implementers and SDK work because it tracks the backend route surface directly.
The public docs intentionally keep the machine-generated reference separate from the main navigation until operation IDs, model names, and examples are fully curated for external readers. Use the task pages first, then use the generated reference for exact route names and request/response shapes.
SDK smoke checks
The repository includes a package smoke runner for launch readiness:
scripts/smoke-sdks.sh
The runner installs and builds available JavaScript packages, imports their public entrypoints where safe, runs Go SDK tests, runs Python SDK tests in an isolated virtual environment, and checks other language packages when their toolchains are installed. Jenkins runs the same script with Node, Go, and Python available before image builds.
Refresh command
From the repository root:
scripts/refresh-api-docs.sh
The script regenerates the Swagger source from Go annotations and then rebuilds docs/api-docs from that Swagger file.
Current launch gaps
- Billing, Storage, Managed Data, Realtime publish, and API-key management need first-class typed resources in the backend SDKs. Search, Feature Flags, and Realtime now have first browser-safe helpers, with broader language parity still later work.
- Java, C#, Flutter, Android, Swift, and React Native packages have smoke coverage only when the matching local or CI toolchain is available.
- Generated operation IDs still need curation before the machine-generated API reference should become the main public reference.