Let teams reshape API data at the gateway, without new screens to learn and without breaking live traffic
Kong and Apigee already let teams change headers, query parameters and body data as requests pass through the gateway. Yappes could not. I designed Transformation as a new policy inside the existing policy screens, so developers had nothing new to learn and engineers reused what was already built.
- ROLE
- Senior Product Designer, the only designer at Yappes
- TEAM
- VP Engineering, CTO, backend, gateway and frontend engineers
- TIMELINE
- Shipped early 2025
- SCOPE
- REST APIs, at endpoint and subscription level
- TOOLS
- Figma, Whimsical, Notion
- BENCHMARKED
- Kong, Apigee, AWS API Gateway, Tyk
Every data change meant a backend change
The Yappes gateway already ran policies like routing, caching, mocking and load balancing. But teams had no way to change the data passing through it. Adding a header, hiding a sensitive field, or renaming a partner's field all needed a backend code change. Kong and Apigee offer this out of the box, so enterprise buyers expect it.
Let developers reshape API data at the gateway, without a new UI to learn and without breaking live traffic?
I interviewed the VP Engineering and the backend, gateway and frontend engineers, and benchmarked four platforms. Two findings shaped everything:
Where transformation runs
The backend never changes. The gateway reshapes the request on the way in and the response on the way out.
Build it inside the policy system, not beside it
Together with the VP Engineering and the CTO, we decided to build Transformation as a policy, not as a separate module. Policies already had attach, order and detach, so teams would manage it like everything else on the gateway.
Simple forms for headers and params, scripts only for the body
Most changes are small, like adding one header. A few are big, like reshaping a whole JSON body. I gave each its own tool instead of forcing one tool on both.
| HEADERS + QUERY PARAMS | BODY | |
|---|---|---|
| INPUT | A form: pick the parameter, pick Add, Update or Remove, enter name and value | A script editor with JSON or XML content type |
| SAFETY | No code, so little can go wrong | A Test button shows the output before saving |
| SPEED | Seconds to set up | Templates, and any config can be saved as a new template |
ONE SMALL RULE · Query parameters are hidden for response transformations, because responses don't have them. The UI never offers an option that can't work.
Show the run order, and catch conflicts before save
Order changes the result. If "Remove header X" runs before "Update header X", the update has nothing to update. The gateway team named run order as their biggest worry, so I made it visible and editable.
- 1Add header · Accept
- 2Update header · X-Regiondragging up
- 3Remove header · X-Region
| IF A USER ADDS | THE UI |
|---|---|
| Update header after a Remove header with the same name | Warns and asks to reorder |
| A second Remove with the same name on the same endpoint | Flags the duplicate |
| A second Body update on the same endpoint | Blocks it: one body update per endpoint |
| A query parameter rule on a response | Never offers the option |
From whiteboard to V2
The design went through product and engineering reviews, from whiteboard sketches to V1, V2 and a validation round.
- Reuse first. The attach modal split into "choose from existing" and "create new", so teams reuse rules instead of making copies.
- Conflict checks. Added for Update and Remove rules on the same header or query name, so one rule can't silently cancel another.
- One body update per endpoint. Different bodies for different partners live in separate subscription-level policies.
- Clearer delete messages. Deleting an API or endpoint now says which policies get detached.
- A better body editor. Switch script language with a starter template, save any setup as a template, edit full screen, confirm before switching JSON to XML.
Shipped to production, and closed a feature gap with Kong and Apigee, inside the UI teams already knew.
Body scripts still need technical skill. Templates and the Test button help, but a visual field mapper would be friendlier.
Input came mostly from internal engineers and competitor research, not outside users. Next time I would test early with a few real API teams.
Put new power inside the patterns users already know, and the hard part becomes the details, not the learning.
In systems where order matters, show the order. Hiding it creates bugs no error message can explain.