CASE 01 / SUNGROW · DEVELOPER EXPERIENCE

Energy APIs.
From docs to working calls.

I lead a standalone renewable-energy API platform, with responsibility for the React frontend, European delivery, online API debugging and application management.

Try API debugging My platform role ↓

Configured sitesChina · International · Europe · Australia · India

Authorization pathsUser-level V1 · OAuth2 V2

TOOLS & FOCUS

React · TypeScript
API integration · Developer experience

01 / THE INTERACTIVE CONSOLE

Follow a request.

Choose a site, check application access and run a sample call. Then try a missing permission or a timeout.

Developer playgroundSAMPLE MODE

01 / CONFIGURE

Business site

Sample application

Example endpoint

Gateway condition

REQUEST PREVIEW

POST/demo/plant-summary

Europe gateway↓

appkey: demo-app-001Synthetic application credentials

02 / FOLLOW THE REQUEST

Local simulation

App permissionReady
Site gatewayEurope
Raw responseWaiting

Ready to explore

Choose a site, then run a request to see how access, routing and the response fit together.

One request layer. Two different contracts.

The API debugger uses application credentials and shows the raw response. Ordinary portal calls can use encrypted payloads and unwrap the result. This reconstruction simulates the debugger; it performs no encryption.

Interactive reconstruction · Sample data · No live requests.

02 / THE PRODUCT BEHIND THE API

Two sides of one platform.

Developers need a path to integration. Operators need tools to manage access and keep that path working.

FOR DEVELOPERS

From the docs to a working call.

Browse API documentation, create an application, obtain authorization, debug a request and inspect usage.

Documentation & quick start
Applications & credentials
Online debugging & usage

FOR OPERATORS

The workflows behind access.

Review applications and manage API versions, plans, call logs and help content within the same frontend.

Application review
Versions, plans & call logs
Documentation & FAQ maintenance

Applications connect API access with plans, allowlists, Webhook and MQTT settings. The frontend makes these relationships navigable.

03 / ENGINEERING IN CONTEXT

Where the complexity lives.

Explore the platform’s request, regional and access boundaries—and their implications for frontend implementation.

The site is part of the request.

A build environment and a business region answer different questions.

The platform separates build configuration from the selected business site. Site initialization determines the default gateway; individual requests can override it, including registration against another server. The interface needs to make the target site explicit and send each request to the intended gateway.

A region selector has consequences beyond the label in the header.

One request layer. Different contracts.

An online debugger needs to preserve what the API actually returned.

Ordinary portal requests can use the shared encryption and response-handling path. The debugger reuses that request layer with application-level credentials, a permission check and a raw-response mode. Its request-body encryption is disabled for that flow; the ordinary portal result wrapper is bypassed.

Shared infrastructure still needs explicit options for different callers.

HTTP success is not business success.

A resolved request can still contain a business failure.

The API reports business outcomes through result_code and result_data. The default POST wrapper can resolve with an error value rather than reject the promise. Callers must inspect that outcome; debugging instead exposes the full response. Network failures and business failures require different UI states.

The frontend must understand the response contract, not just await it.

Navigation is only one access layer.

Visible routes and authorized API calls are separate responsibilities.

The frontend matches user permission codes to route metadata and registers the permitted pages. Menus and management entry points follow that context. Backend services remain responsible for identity, authorization and resource scope; hiding an action does not secure its API.

A coherent access experience spans routes, actions and server checks.

04 / PLATFORM LEADERSHIP & DELIVERY

Where I contribute.

Platform leadership alongside hands-on React frontend work, European delivery, online debugging and application-management interfaces.

01
European delivery
Led the platform’s frontend delivery for the European site, connecting product requirements with the developer-facing workflows.
02
Online debugging
Work on the developer-facing flow for making API calls and inspecting their responses.
03
Application management
Work on the application interfaces that developers use to manage their API integrations.

BUILDING A DEVELOPER PRODUCT?

Let’s make the complex parts usable.

Let’s talk