Cox Automotive Developer API Platform

Overview

As Cox Automotive expanded its API ecosystem, developers faced a fragmented experience. APIs were distributed across multiple business units, documentation varied in quality, and common tasks like requesting access, generating credentials, and finding endpoint information required navigating multiple systems or relying on direct support from engineering teams.

At the time, there wasn't a centralized developer platform. Accessing an API typically meant receiving a PDF specification and coordinating directly with an engineer.

I designed a centralized Developer API Platform to replace that experience: a single destination where developers could discover APIs, request access, generate credentials, and begin integrating through a consistent, self-service workflow. One of the biggest improvements was a redesigned access request experience that automated validation and reduced API onboarding time from up to six weeks to under an hour.

My Role

I led the end-to-end UX design of the platform, defining how developers discovered, accessed, and managed APIs throughout their lifecycle. My work included information architecture, onboarding, documentation, authentication, application management, and credential workflows. Engineering partnered closely throughout implementation to bring the designs to life.

I worked alongside the Product Director to define the platform strategy and collaborated directly with engineers and developers throughout the design process. Rather than relying solely on stakeholder assumptions, I incorporated feedback from the people integrating with APIs every day to ensure the platform addressed real developer pain points.

Responsibilities

• Defined the platform's information architecture and navigation model.

• Designed the centralized API Storefront and reusable API page template, including Overview, Use Cases, Glossary, and FAQs.

• Designed the self-service API access workflow, including automatic dealer ID validation.

• Designed authentication, OAuth, and credential management experiences.

• Created application and team management workflows with role-based permissions.

• Established reusable UX patterns and templates that enabled new APIs to be added without redesigning the platform.
  
  

The Challenge

This project wasn't about redesigning documentation, it was about designing an end-to-end developer platform.

Developers needed a seamless path from discovering an API to requesting access, authenticating, building an integration, and maintaining that integration over time. At the same time, the platform had to support two distinct audiences with different needs.

Internal developers prioritized speed and discoverability while building products across Cox Automotive.

External integration partners required additional onboarding, authentication guidance, documentation, and account management to successfully integrate from outside the organization.

The challenge was creating a single platform that served both audiences without feeling like two separate products.

Design Goals

Understanding the Platform

Rather than designing a documentation site, I designed a platform that supported the entire API lifecycle. Discovery, onboarding, authentication, documentation, application management, and ongoing maintenance needed to function as one cohesive system.

Every interaction had to support the next, creating a clear path from first discovering an API to maintaining a production integration over time.

I mapped the end-to-end experience to identify where developers encountered delays, relied on engineering support, or moved between disconnected systems. This helped us prioritize the moments where self-service workflows could create the greatest impact.

Platform Architecture

Before this project, APIs were scattered across multiple teams, each with different documentation formats, terminology, and onboarding processes. As the ecosystem grew, developers had no predictable way to understand where information lived or how one API related to another.

I defined an information architecture that organized the platform around consistent developer tasks rather than internal business-unit structures. The resulting hierarchy made navigation predictable across products and provided a repeatable framework for adding new APIs without redesigning the platform.

My Approach

Rather than approaching the project as a collection of screens, I designed it as a connected platform.

Search, documentation, access requests, authentication, application management, and credential workflows all needed to work together so developers could move naturally through the integration lifecycle without unnecessary friction or context switching.

This systems-first approach also shaped how I collaborated. I partnered closely with the Product Director to define the overall experience, but I also brought developers into the design process from the beginning, not simply to review mockups, but to help identify where the existing process was breaking down. Their firsthand experience integrating with APIs informed key architectural decisions early, ensuring the platform solved meaningful problems rather than simply improving the interface.

Designing a Consistent API Storefront

Each API product page served as the primary destination for developers deciding whether an API met their needs. Rather than presenting documentation as a long technical reference, I designed a reusable product-page framework that helped developers understand the value, requirements, and next steps before writing code.

The template organized information around the questions developers were already asking:

What does this API do?
Is it right for my use case?
What has changed from previous versions?
What terminology do I need to understand?
How do I request access or get help?

The same structure—Overview, Use Cases, Glossary, FAQs, and Support—could be applied across API products regardless of which team owned them. This made the storefront easier for developers to learn and easier for internal teams to maintain.

Giving Developers Control After Access

Getting access to an API was only the beginning. Once approved, developers needed a clear way to manage credentials, understand how their integrations were performing, and complete routine maintenance without returning to an engineer for help.

I designed the authenticated experience as a centralized workspace for each API product. From one place, developers could manage API keys, review usage, monitor errors, and return to documentation when they needed implementation support.

Secure credential management

API keys were displayed in a structured table with sensitive values hidden by default. Developers could quickly distinguish between production, staging, and development credentials, see when each key was created or last used, and understand its current status.

The experience also supported common lifecycle tasks such as creating a new key, revealing or copying a credential, editing its name, and rotating it when needed. Keeping these actions within the same workspace reduced the need for manual support while making security-sensitive tasks easier to understand.

Usage without leaving the platform

I paired credential management with usage reporting so developers could see whether an integration was working without switching tools.

The dashboard surfaced key signals such as:

• Total and successful requests

• Error rate

• Average response time

• Request volume over time

• Most frequently used endpoints

This gave developers a faster way to identify failures, unexpected traffic patterns, and performance issues while maintaining an integration.

Designing for self-service maintenance

The broader goal was to support the full lifecycle of an integration, not just the initial setup. Documentation, authentication, credentials, team access, and usage data were intentionally connected so developers could move between building and operating their applications without hitting a dead end.

By bringing these workflows together, the platform turned tasks that previously required direct engineering support into repeatable, self-service experiences.

Outcomes

The Developer API Platform established a shared foundation for how APIs were discovered, accessed, and managed across Cox Automotive. By replacing fragmented documentation and manual engineering workflows with a centralized, self-service experience, the platform made it easier for both internal teams and external integration partners to successfully integrate with APIs.

The project resulted in:

• Reduced API onboarding time from up to six weeks to under an hour by replacing a manual, engineer-led access process with a self-service workflow and automated validation.

• Established a centralized API Storefront for discovering and evaluating APIs.

• Standardized documentation through reusable templates and consistent information architecture.

• Unified authentication, API key management, and credential workflows across the platform.

• Created scalable UX patterns that enabled new APIs to be added without redesigning the experience.

• Reduced reliance on engineering support by enabling developers to discover APIs, request access, manage credentials, and maintain integrations independently.