REST API Example Creator
Writers couldn’t see which of hundreds of API endpoints lacked examples. I designed a tool that finds them and drafts each one for review.
Role
Team
Timeline
Outcome
Names, data and screens are modified for confidentiality. The process and my contribution are accurate.
One scan shows every endpoint in the guide that has no example. Each flag links straight to its documentation topic, so a writer can confirm the gap before generating anything.
Writers found missing examples by hand, one endpoint at a time
Each gap then took five more manual steps: read the spec, build the request and response, format the XML, test it against an environment, and name the file to standard while stripping sensitive data. With more than 6k endpoints (in Oracle CX Sales) in a single guide, gaps grew faster than writers could close them.
"We are trying to address only the newer endpoints. We create the examples for older content only when there are infodev bugs asking for them"
API documentation writer, research interview
It matters because developers read examples first and descriptions second, and most API documents ship with no input or output examples at all (Maalej and Robillard). Finding the gap was its own manual search, and it came before five more steps per example.
- Find which endpoints have no exampleNo way to see gaps
- Read the spec to understand behaviour
- Build the request and response
- Format the XML file
- Test against an environment
- Name the file and strip sensitive data
Repeated for every endpoint in the guide.
AI could draft, but it could never publish
Two limits shaped every screen, and both made the design more trustworthy.
Nothing generated could reach customers unreviewed
Examples run against real environments and can carry sensitive or environment-specific data, so publishing a generated example directly was off the table. I made “draft” a visible state: every generated example lands in review, and the tool shows what was scanned, selected, generated, skipped or excluded.
The tool had to fit the existing documentation pipeline
Writers already had a publishing workflow and a file-naming standard I couldn’t change. So the output is standard-named XML that drops into that workflow, not a new place to publish from.
I owned the workflow from gap identification and research to final design
I owned research with 14 API writers, the AI prototype, the information architecture and the interaction design, alongside one other UX designer, over 4 months.
I built the GPT prototype to test whether generation alone could solve the problem. When it couldn’t, I made the call to redesign the tool around scanning for gaps first.
I killed the chatbot and designed a scanner
My first prototype generated good examples but solved the smaller half of the problem.
Scan-first workflow over a generate-on-request GPT
I built a GPT that, given one endpoint, produced the cURL command, request and response, and XML file. It worked for single examples but couldn’t tell which endpoints across a guide were missing examples, and it couldn’t name files to standard reliably.
Writers were already spending time just finding what was missing, so I rebuilt the experience around a scan. It checks every endpoint topic for an Examples heading or subheading, flags the ones without one, and links each flag to its topic. None of the enterprise platforms I reviewed offered this. What I gave up: the simplicity of a chat interface.
curl -X POST …/v1/opportunities -H "Content-Type: application/json"
- POST/v1/
opportunities No example - GET/v1/
accounts Example found - PATCH/v1/
leads/ No example{id} - DELETE/v1/
quotes/ No example{id}
The prototype proved generation was possible and that it wasn’t enough. Finding the gap was the costlier half of the job, so the scan became the front door. At hundreds of endpoints, speeding up one example doesn’t change the workload; managing many does. I designed filtering, multi-select and saved searches so writers can work through a guide in batches and pick up where they left off.
"I want to work on the opportunities endpoint, finding this is getting cumbersome among these 2000+ missing examples"
API documentation writer, user testing
"The search is taking a lot of time"
API documentation writer, user testing
Writers work in batches, not endpoint by endpoint. Try selecting rows: the action always says exactly how many drafts it will create.
Where it landed
Status: Piloted (Used by the Infodev API writing team from July 2026)
Designing for this workflow pushed me past individual screens to system states, bulk actions, exceptions and user confidence.
Outcome
"We in SCM needed something like this, this is an effectiveness booster"
SCM API documentation writer, on pilot
"I've been using it for my work, and I've created 56 examples using this tool, normally it would have taken me two releases worth of time"
CX API documentation writer, 3 month user
The REST API Example Creator evolved from a simple GPT experiment into a structured workflow for identifying, generating, and reviewing missing API examples. The early prototype showed that GPT could generate cURL commands, request and response bodies, and XML files from an endpoint, but it also exposed the limitations of generation alone, there was no reliable way to find missing examples across a documentation set, and file naming and consistency remained difficult. This led to designing a more complete experience around scanning, filtering, selecting, generating, and reviewing examples at scale.
The final experience reduces repetitive work while keeping writers in control of what gets generated, reviewed, validated, and eventually published. Designing for a technically complex workflow also pushed me to think beyond individual screens and consider system states, bulk actions, exceptions, and user confidence as core parts of the UX.