Organizing APIs around business services, standardizing documentation and supporting developers through configuration and testing.
Scattered documentation and limited testing guidance made energy-market integration harder. From 2024 to May 2026, I worked from discovery through development support to organize APIs by business service, standardize documentation and support request testing.
The launch prioritized service categories, consolidated documentation and testing within implementation constraints. The gallery presents a later AI-assisted reconstruction; it is not a historical capture of the shipped interface.
Read the context and decisions ↓Nine individual screens of the reconstructed experience. These are later AI-assisted reconstructions, not historical production screenshots; data and playground interactions are simulated.
Long screens scroll vertically inside the image.
Separate entry paths for market agents and developers exploring public data.
Prerequisites and a guided path from access approval to the first SOAP request.
Company, application scope and technical contact grouped in one access request.
Access to the authenticated area for integration and credential management.
Request and response examples alongside authentication requirements and header parameters.
Request configuration and generated XML side by side, with a visible test-environment warning.
Service health, credentials, usage and rate-limit warnings in an authenticated overview.
Availability, incidents and planned maintenance without entering the agent area.
A public REST catalogue with categories and guidance for a first request without credentials.
CCEE’s Integration Platform allows member companies to consume energy-market data and transmit contracts, generation and consumption information. The DevPortal was created to improve the experience of internal developers and business analysts, as well as customer teams building their own software to query and cross-reference data.
My involvement ran from 2024 to May 2026: initially through incremental improvements, then as a structured project in 2025–2026. Documentation was scattered and inconsistent, with insufficient guidance on request configuration and testing. This created avoidable integration problems, including temporary access blocks.
Developers and business analysts needed to find the right API, configure a request and understand its response. Documentation was scattered and inconsistent, while limited testing guidance led to avoidable integration problems, including temporary access blocks. These recurring difficulties framed the problem: completing an integration required assembling information across sources.
I worked end to end, from discovery through development support, connecting stakeholders, technical teams and user needs:
Collaborative workshops defined scope, personas, journeys and Jobs-to-be-Done. I helped translate the needs of developers and business analysts into a shared structure for the portal. The decision was to organize the experience around what each audience needed to accomplish, giving the team a basis for discussing navigation and service discovery.
We grouped APIs into business-service categories rather than relying only on a technical catalogue. This connected service discovery to the user's task. A fuller vision included journeys and guidance for individual services, but the volume of APIs made that scope impractical for launch. We prioritized categories and consolidated, standardized documentation.
I developed wireframes and final interfaces and supported implementation with the technical team. Documentation, playground and request testing addressed the gap between reading a specification and trying a call. The IBM solution and its API-management integrations constrained implementation; delivery capacity also required compromises. The shipped scope implemented only part of the broader service-journey vision.
This comparison reconstructs the fragmented information model and illustrates the later prototype. It is not a historical before-and-after capture. The original launch consolidated documentation, categorized services and supported request testing.
Documentation explained the protocol; it did not guide the developer through the job.
Configure a safe, fictional request and experience the loop designed to move developers from reading documentation to validating a SOAP call.
Safe demonstrationNo certificate or real market data is used.
<!-- Configure the request to generate XML -->
<totalRegistros>3</totalRegistros> <ambiente>PILOTO</ambiente> <status>SUCESSO</status>
The fragment demonstrates interaction and information hierarchy. Authentication, rate limits and responses are simulated for portfolio review.
The following examples connect the design decisions to their supporting exploration. Original prompts are available on demand.
The synthesis revisited audience profiles close to those defined with the original team and supported the reconstructed entry journeys.
Act as a Developer Experience specialist for the Brazilian electricity sector. Based on the rules of CCEE's Integration Platform...
The output supported the reconstructed task-oriented documentation, annotated XML and simulated SOAP playground.
Analyze the WSDL/XSD documentation for CCEE's ListarAtivoMedicao service. Restructure it following a modern API documentation pattern...
These prompts illustrate the reconstruction process. They do not replace or establish the authorship of the original collaborative discovery, and the prototype’s components are independent of CCEE’s official design system.
AI supported the later interface reconstruction and simulated prototype. The original discovery, service organization and delivery were collaborative work with the team; I reviewed the reconstruction against that context.
Explore the reconstructed prototype. Calls, authentication and responses are simulated; this is not the production portal.
The original project consolidated documentation, organized APIs into business-service categories and supported request testing. The reported outcome was approximately 40% fewer basic technical support requests following the project improvements. This is a project-level result; it does not isolate the contribution of an individual interface change. The later reconstruction illustrates the design direction and is not evidence of the original project's measured impact.
Centralized documentation: previously scattered information brought together and standardized
Reported outcome: approximately 40% fewer basic technical support requests after the project improvements
Developer enablement: playground and request testing provided important support beyond the earlier limited Postman experience
Business-service organization: categories aligned with user tasks, with the broader service-journey vision only partially implemented at launch
The key trade-off was how much service-specific guidance the team could deliver within the IBM tooling and delivery constraints. Categories and documentation standards created a feasible first step, while the broader journey vision remained only partially implemented. The later prototype makes that direction tangible, but validating it with users would be a separate step; its simulated interactions do not establish usability or business outcomes.
