Jan '26 Highlights: New API Playground Experience, Flexible Page Layouts and Precise Error Handling in SDK Code Samples

API documentation should not get in the way of developers exploring APIs. This month, we redesigned the API playground into a drawer-based experience that keeps your docs visible while developers test endpoints. We also shipped customizable layouts for custom content pages, sidebar icons, and several documentation quality improvements, in addition to typed error handling in code samples across five SDK languages.

Here's everything that shipped in January 2026.

🚀 Developer Portal Improvements

This month brings six major improvements to your developer portal experience, making documentation more accessible, flexible, and developer-friendly.

API Playground

Custom Layouts

Sidebar Icons

API Recipes

Redesigned API Playground Experience

Your API playground now opens in a slide-out drawer, keeping endpoint documentation visible while developers test requests. No more scrolling back and forth between reference material and the testing interface.

🔗 View Changelog

Customizable Layouts for Custom Content Pages

Choose from three layout modes (Default, Wide, and Custom) for your content pages. Long-form tutorials and integration guides now have the breathing room they need with flexible layout options.

🔗 View Changelog

Hiding the third column on a documentation page

Icons in the Developer Portal Sidebar

Sidebar navigation now supports visual icons from the Lucide library, helping users scan and navigate your documentation faster through familiar visual cues.

🔗 View Changelog

Enhanced API Recipe Completion Flow

When developers complete an API recipe, they now see a celebration modal with options to continue their journey. Add confetti animations for milestone achievements to make learning more engaging.

🔗 View Changelog

🚀 Typed error handling in code samples across SDKs

Code samples for PHP, TypeScript, Java, .NET, and Go now include typed error handling, giving developers precise control over individual error scenarios.

Generic catch blocks tell developers that something went wrong. Typed error handling tells them exactly what went wrong and lets them respond accordingly.

Generated code samples now expose response status codes and headers prominently, use typed error branches where the language supports them, and follow idiomatic patterns for each language. Here's what that looks like in practice:

• PHP uses instanceof checks for specific exception types, giving granular control over individual error scenarios. Requires the "Map Error Types in Complete Response for PHP" setting.

• TypeScript preserves error metadata logging while adding typed branches with instanceof checks, maintaining access to statusCode, headers, and body properties.

• Go replaces generic log.Fatalln(err) calls with type-switched error handling, including a default case for unexpected errors.

• Java moves from generic stack trace printing to typed exception inspection using exception.getCause() with branching to specific exception types.

• .NET expands the single ApiException handler with is operator checks for specific exception types while maintaining message logging.
  

🔗 See the Error Handling documentation for code examples in each language.

🛠 Improvements

• Model documentation for collected parameters:  For methods with long parameter lists, input fields are collected into a single model class rather than listing them individually. For instance, instead of documenting six separate parameters like firstName, lastName, email, phoneNumber, address, and preferences, the endpoint now shows a single required input: CreateUserProfileInput.

  The SDK documentation for Java, .NET, and Go SDKs now includes dedicated entries for these parameter collection classes. Endpoint documentation presents them as unified model references that match how the SDK actually works, making it easier to understand the method signature and prepare the required input structure.

  This documentation improvement applies automatically when you regenerate your SDK

  🔗 See the Collected Parameters documentation for before/after examples.

• Consistent enum representation in SDK documentation: SDK documentation across Java, .NET, Go, TypeScript, Ruby, Python, and PHP now displays environment enumeration values consistently in the Getting Started section, matching the casing used in the SDK.  

  Enum casing in the Java model documentation has also been enhanced.

  🔗 Learn more about this change in the changelog.