The problem
Manual toil and architectural drift in a multi-language ecosystem
Auth0 maintains a vast library of SDKs divided into two categories: Authentication APIs that handle login, logout, and related flows, and a growing suite of Administrative APIs. The administrative category includes the primary Management API, which programmatically manages users, applications, and connections. It also covers a growing set of self-service APIs, including MyAccount for end users to manage their own accounts and MyOrg for business customers to manage their own organizations, plus the upcoming Teams API.
Before Fern, Auth0's in-house SDK team wrote and maintained every one of these SDKs by hand, language by language. That investment makes sense for the Authentication SDKs, which require high-touch bespoke logic, but the administrative APIs were buckling under the same manual, per-language effort. The SDK team faced three problems:
- Repetitive engineering toil. Adding a single property to a request object or supporting a new endpoint meant writing the same change by hand across every supported language: Node, Java, PHP, Python, and more.
- Feature drift. Individual SDKs drifted apart over time. The way one SDK refreshed a management token or paged through a list of users could differ from the next, so a developer's experience depended on which language they picked.
- Downstream bottlenecks. Delays in manual SDK updates held up the teams that depend on those SDKs, including the Customer Developer Tools team behind the Auth0 Terraform Provider and Deploy CLI.
Auth0 compared Fern against other SDK providers on features, pricing, and how each team worked with them early in the process. Fern being open source was the factor that stood out. Auth0 restructured its administrative APIs around Fern's OpenAPI-driven generation, working with Fern to meet its developer experience bar rather than settle for generic generated code.
Adding a feature used to mean implementing it seven times, once per language. Now we change the spec once and it ships in every SDK, so we scale features as fast as we can define them.
The solution
Transitioning to an OpenAPI-first SDK workflow
Auth0 turned the OpenAPI specification into the contract for every administrative API. A change to the spec flows out to every SDK, so the team scales a feature across seven languages by editing one source instead of writing the same code seven times.
- One spec, every SDK. A change to the Management, MyAccount, or MyOrg API regenerates the SDK layer across all seven languages at once, so a single edit to the spec propagates everywhere instead of being copied into seven codebases by hand.
- Reviewable diffs for code that handles credentials. Auth0 engineers now review and merge autogenerated pull requests rather than hand-coding each endpoint. For a security company whose SDKs handle tokens and credentials, every change arriving as a reviewable diff matters as much as the speed of the change itself. The workflow moves new features from spec to shipped SDK far faster than manual updates allowed.
- Consistency across the languages customers actually use. Auth0 customers integrate identity across a wide range of language stacks. Fern's generators hold the SDK structure to the same pattern whether a developer reaches for Go or Java, so token handling, pagination, and error shapes read the same everywhere.
- Fern fixed the spec, not just the output. Auth0's schema started with rough edges. Fern resolved them either by accommodating them in generation or by directing Auth0 on how to improve the artifacts the spec produced, clearing the OpenAPI architectural blockers that would have stalled the migration.
- SDK behavior built for the Management API. The administrative APIs are the part of identity where these behaviors earn their keep, and every generated SDK handles them the same way. OAuth 2.0 token management with automatic refresh means a developer calling the Management API never hand-rolls the client-credentials exchange or watches for an expiring token. Retries with exponential backoff absorb the rate-limit responses that bulk operations like provisioning users or rotating credentials trigger against Auth0's Management API. Pagination via async iterators pages through a long list of users or tenant logs without the manual page or cursor tracking the Management API otherwise requires.
- Downstream teams ship sooner. The Customer Developer Tools team builds the Auth0 Terraform Provider and Deploy CLI, the tools customers use to manage their Auth0 configuration as code and promote it from development to production through CI/CD. Both depend on the SDKs, so hand-written updates used to delay their support for new features. Now that the SDKs are generated and available faster, that team starts integration work much sooner, and new identity features reach customers' as-code workflows without the old lag.
Looking ahead
A sustainable architecture for the future of identity
With maintenance off its plate, the SDK team reclaims that capacity for the higher-priority work it never had room for. The generated workflow saves the SDK team over 7,000 engineering hours a year. The administrative APIs that once consumed that time now regenerate from the spec, freeing the team for the initiatives it had less bandwidth to take on.
As Auth0's identity surface keeps expanding, that architecture lets the team roll out support for a new API almost instantly, reusing existing Fern configuration across every language rather than building each client by hand. The Teams API, now in development, is the next to ship this way.