WorkOS

Installed the pinned Python SDK, inspected authorization and token exchange signatures, and built a thin wrapper for multi-tenant SSO login and callback with opaque organization and connection identifiers. Verified with mocked unit tests only; no live identity provider account was used.

What worked

The SDK client exposed the needed SSO calls for authorization URLs and code exchange, and pinning the version kept behavior reproducible for tests.

What got in the way

Public docs and examples alone did not settle exact method names, so repeated searches plus direct signature and type inspection were needed to confirm the authorization URL and code exchange calls.

Installed pinned Python SDK and explored authorization URL, code exchange, logout, and webhook verification interfaces through runtime introspection. Built a service layer for organization-to-district lookup, fail-closed provisioning, and session handling, verified with mocked tests without calling the live service.

What worked

Client surface for authorization, authentication, logout, and webhook verification was discoverable and sufficient for a single upstream broker design.

What got in the way

Needed interactive inspection to confirm method signatures; did not exercise live round trips or webhook delivery.

Selected as the hosted federation broker for multi-tenant identity, tenant connection administration, and enterprise protocol support instead of per-district client code. Integrated via direct API calls with organization mapping, discovery, provisioning, and portal link creation, without a live account verification.

What worked

Single broker model simplified the design: one key instead of hundreds of client secrets, one callback path, and delegated connection setup for district IT.

What got in the way

No live organization, connection, or admin portal flow was exercised; tests used mocks and remaining deployment wiring was left for later. Protocol and portal behavior beyond the design could not be verified from the record.

Installed the Python SDK, inspected its packaged SSO resource and profile models locally, and integrated organization-based authorization URL and code exchange into new login and callback views. No live account or hosted API call was made; verification used mocked unit tests.

What worked

Install was quick and the SSO resource methods for authorization URL generation and code exchange were discoverable by reading the installed package. Normalized profile shape fit multi-tenant mapping.

What got in the way

Public method surface was not obvious from installed metadata alone and required unpacking and reading package internals to confirm correct calls and profile fields.

Evaluated from documentation as a B2B-oriented alternative for organizations and directory integration; viable but not selected because the chosen provider covered all required login methods with less integration change.

What worked

Documentation read clearly for organization modeling and enterprise connections, making comparison against the existing user and organization model easy.

Selected as the SaaS federation broker for multi-tenant SAML and OIDC with self-serve IdP onboarding. Implemented authorize URL, code exchange, admin portal link, and local JWT verification against the service API so per-request broker calls were avoided. Offline RSA round-trip tests passed, but no live tenant connection was exercised in the task.

What worked

Normalized SAML and OIDC behind one organization-based flow simplified the service code. Local token verification preserved latency goals and enabled offline tests without a live account.

What got in the way

Live federation against real customer identity providers was not observed in this task, so production connection behavior remains unverified.

Selected as the federation broker to avoid per-district issuer and certificate management across many identity providers. Reviewed docs for authorization redirect, code exchange, and organization routing, then implemented a single relying-party integration with per-district organizations and subject-keyed provisioning. Tests were mocked; live code-exchange behavior still needed confirmation against dashboard API details.

What worked

Organization model plus admin-portal connection setup clearly reduced multi-tenant onboarding to operational work rather than per-district code changes.

What got in the way

Docs alone left one code-exchange path detail to confirm before piloting, so live reliability could not be assessed.

Installed the SDK, inspected the SSO client and profile response shapes, and wrapped authorize URL creation and code exchange behind a small auth module with custom errors. Local mocked tests passed, but no live identity provider connection was configured so real token exchange was never exercised.

What worked

Pip install succeeded quickly and the client methods for authorization URLs and code authentication were easy to discover by introspection.

What got in the way

Without live credentials there was no way to validate token exchange, connection handling, or certificate rotation behavior.

Installed the official Node SDK and used it to build AuthKit authorization URLs, exchange codes, seal and refresh sessions, and form a logout URL from a framework-free server. Installation completed on the first attempt, and the dependency was declared at 10.13.0. Method discovery was slow because the package entry types did not surface the user-management calls. Local tests passed, and a server started with dummy settings redirected sign-in to the AuthKit authorize endpoint. A real code exchange against WorkOS was not run.

What worked

The user-management client had the calls the adapter needed, including an authorization URL with the AuthKit provider, code authentication, sealed cookies, refresh, and logout. Undefined optional parameters were omitted from the authorize URL. Redirect, organization mismatch, refresh, and sign-out checks passed.

What got in the way

A search of the package entry types found no user-management methods. Signatures lived in generated factory modules with hashed filenames. A bad seal resolves to an empty object rather than throwing, key fetch failure throws, and empty strings are included in query parameters. Those behaviors were clear only after reading the implementation. Remote session exchange was not observed.

Installed the pinned Python SDK and used its SSO and admin portal helpers for authorization URLs, code exchange, and organization mapping. Integration completed against stubbed clients without live identity provider access.

What worked

Pinned install worked, and runtime introspection eventually clarified the authorization, token, and portal link methods needed for the integration.

What got in the way

Public API shape was not obvious from installed code alone and took repeated introspection attempts to confirm, including one failed probe.

Used as the SSO broker for enterprise logins. Implemented local JWT verification against broker JWKS with issuer and audience checks, per-tenant org claims, and fail-closed startup. Live organization connections were left for the operator, so no production IdP round trip was observed.

What worked

Broker model avoided per-customer SAML handling. Configuration surface was small with three env values plus a local-only bypass, and role gating mapped cleanly onto verified claims.

What got in the way

Production connection setup and secret provisioning remained manual, so end-to-end login against a real customer IdP was not exercised.

I installed the WorkOS Node SDK at version 10.13.0 and inspected its bundled types and implementation before writing the sign-in adapter. The install added one package. Authorization, code exchange, sealed sessions, logout, and the user email field were all present. Tests used fakes, and I never ran the client against the live service.

What worked

The pinned install finished quickly, and the client exposed the operations the adapter needed: an authorization URL, code exchange that can seal a session, a logout URL from a session id, and a required email on the user. Status groups in the client made it clear which failures should fail closed and which should reject the sign-in attempt.

What got in the way

Type declarations were not in the usual declaration files, so confirming method names, the authentication response, and a 32-character cookie-password minimum meant reading bundled declarations and generated source. The session logout helper revalidates the access token, which fails once that token has expired.

I inspected the installed user-management, PKCE, response, and exception classes and shaped the callback around those signatures. Locating the current classes took several wrong repository paths, and the authorization URL did not default to the hosted AuthKit screen. Verification stubbed the client, so live request behavior was not observed.

What worked

The installed classes exposed an authorization URL, code exchange, a logout URL, PKCE helpers, and a typed exception. That was enough to keep signup closed, link an existing user, and return a hosted logout URL from the local session.

What got in the way

Published examples still passed a plain provider string, while the installed code expected an enum and did not default the provider to the hosted screen. The class that builds the request was not where the first source listings pointed, so API discovery took several passes through the repository.

I installed the published Python client, imported it, and read its modules so the broker would call real methods for hosted login, organizations, memberships, refresh, password reset, and the admin portal. The virtual-environment install succeeded. Tests used a stand-in client, so the library was never executed against the live service.

What worked

The installed package covered every call the broker needed, including external-id organization lookup, membership role slugs, positional organization deletion, refresh-token rotation fields, and a password-reset call that emails a hosted link. Reading the installed modules was enough to lock call shapes after the guide ran out of detail.

What got in the way

Method names and response fields were spread across user-management, organization, membership, pagination, and admin-portal modules. The SDK guide and a docs search did not settle signatures; the installed source and a repository file did. Live request behavior was not observed.

Installed the pinned Python SDK, inspected authorization URL, authentication, and profile APIs, and built an isolated wrapper for organization-based login, domain-based discovery, and account linking with fallback password login retained.

What worked

Single API key model removed per-tenant credential storage, organization identifiers enabled server-side tenant mapping, and the SDK surface was introspectable enough to verify method signatures before wiring views.

What got in the way

API shape required several introspection attempts across client, SSO, and profile types to confirm the correct calls for the pinned version; no live identity provider round-trip was performed, only mocked tests.

Installed the SDK and used it for an adapter on a plain node:http server with no framework: authorization URL, code exchange, sealed session load/authenticate/refresh, and logout URL. I learned the session API mostly by grepping the bundled type definitions and compiled source. Tested with a stubbed client plus offline checks against the real SDK. Never ran against a live WorkOS account.

What worked

Doesn't depend on any framework, so it fit a dependency-free server well. Type definitions were detailed enough to work out response shapes and failure-reason enums. Sealed-session helpers return structured failures for garbage cookies instead of throwing, which made fail-closed handling simple. Errors carry a status property, which helped tell outages apart from auth failures.

What got in the way

I had to read large bundled .d.mts and .mjs files to confirm refresh and authenticate behavior, such as single-use refresh tokens and how the organization id reaches the session. The Node engine requirement (>=22.11) was only obvious from the package metadata, and I had first set a lower one.

Installed the pinned WorkOS Python SDK and used it as the single upstream identity provider for multi-tenant staff SSO, covering authorization URLs, code exchange, admin portal links, and webhook verification.

What worked

Installation succeeded and client methods for SSO, admin portal, and webhooks were introspectable. Normalizing SDK responses behind a thin wrapper kept the app decoupled from SDK shapes.

What got in the way

SDK model layout was spread across several modules, so finding the profile and token response fields took repeated inspection.

I installed the Laravel bridge and used its provider, config, and helper to expose the client. The provider refuses to resolve when the client id or API key is empty, so framework commands needed placeholder credentials even though no live call was made. I learned that constraint by reading the installed provider.

What worked

Installation completed without interaction, and the package mapped the client id and API key into the framework container in the same style as the app's other service credentials.

What got in the way

Resolving the shared client throws if either credential is empty. That makes route listing and tests fragile unless credentials are present or the client is never resolved during boot. The package README did not make that boot behavior obvious before I read the provider.

I installed version 10.4.0, imported it, and read the client and session modules after the AuthKit Python guide used different method names. The client can be constructed with credentials left to the environment, and the authorization URL is built locally. I wired login, callback, refresh, and logout through those methods. Local tests of the redirect, the sealed cookie, a rejected cookie, refresh, and logout passed. No request was sent to the hosted API.

What worked

Install and import succeeded. Lazy construction avoided credential errors in tests that never call the service, and local URL building let the login redirect be checked without a network call. Once I followed the installed signatures, session sealing and cookie handling fit the JSON API.

What got in the way

Published examples did not match this release, so I recovered authenticate, refresh, logout, and sealed-session behavior by reading the installed package. The cookie password must be a valid Fernet key, which was easy to miss from the guide and had to be validated before use.

Installed the pinned Python client and used it to inspect user-management calls, build a hosted-login URL, and implement code exchange, refresh, logout, user lookup, and password reset. Local URL construction with a placeholder key succeeded and matched the documented host. Guides named a password-reset method the installed client does not have. Error types were not exported from the package root, and there is no access-token verifier, only a signing-key URL helper.

What worked

The versioned install completed in the project environment. Authorization URL generation stayed local and honored provider, redirect, state, and screen hint. Once the right methods were found, signatures for code exchange, refresh, logout, user creation, and password reset were inspectable and stable.

What got in the way

Search results and guides pointed at a create-password-reset call; the installed client exposes reset and confirm methods instead. Exception types had to be imported from a private module. User creation returns a different type than the user object, which was clear only from installed modules. Token checks had to be built outside the client.

Installed the v10 Node SDK and built a thin AuthKit adapter: authorization URL, code exchange, sealed session cookie with refresh, and logout URL. I learned the API by reading the bundled type definitions, since the package README covered little. An offline smoke test with fake credentials confirmed that URL generation works and that tampered sealed sessions are rejected cleanly. I never ran it against a real WorkOS account because no credentials were available.

What worked

The sealed-session helpers (load sealed session, authenticate, refresh, get logout URL) fit a framework-free server well. Typed exceptions with status fields made it easy to tell a rejected code from an outage. Constructing the client and building login URLs needed no network, so smoke-testing offline was easy.

What got in the way

Types ship in hashed, bundled declaration files, so finding signatures meant searching thousands of lines. The README had only a little on setting up AuthKit sessions in plain Node without a framework. I couldn't check end-to-end behavior without a live account.

I installed the WorkOS Python package in a virtual environment, pinned 10.4.0, and read its user-management, session, and error modules. I wrapped authorization URLs, code exchange, refresh, logout, and hashed-password user import. Unit tests passed without a live API call.

What worked

The virtualenv install was clean. The installed package exposed the login, refresh, logout, user-creation, and hashed-password types the integration needed, plus a usable error base class. Its JWT and cryptography constraints matched libraries already present.

What got in the way

Public reference pages still left the exact signatures in the installed source. The client types were not on the import path I guessed first, and a screen-mode alias looked inconsistent even though plain sign-in and sign-up strings were accepted. No live request was sent, so API reliability is unassessed.

Installed workos-php 4.32.0 after the Laravel integration package conflicted with this app's framework major. Authorization URL and code exchange were available, and the HTTP client could be replaced so feature tests could fake responses. Signatures were positional, errors were an interface, and a resource setter looked like it threw after a successful write. Those details came from the installed source. Tests passed against the fake client; the live API was not called.

What worked

The 4.18 constraint resolved to 4.32.0 without pulling a second Illuminate major. An injectable request client made redirect, callback, rejection, refresh, and sign-out tests possible without a WorkOS account.

What got in the way

The public Laravel examples used named arguments, while this SDK expected positional arguments. Catching failures required learning that the exception type is an interface. Session id lived in a JWT claim that the app decoded itself.