The API User Advocate: A Role That Doesn't Exist Yet

Every team that integrates with a vendor API🔌APIInterface for software components to communicate.View in glossary builds the same thing: retry logic, rate limit handling, auth token🎟️TokenCredential for API authentication.View in glossary management, error translation⚙️Translation JobBackground process converting CAD files to viewable formats.View in glossary, bulk orchestration. They build it from scratch, every time, because the vendor won’t.

There is a name for the missing role that should build this once: the API User Advocate.

The Same Problem, Everywhere

You are a developer. You need to integrate with a vendor API. The vendor gives you:

• An SDK🧰SDKLibrary for building applications on a platform.View in glossary that wraps HTTP🔗HTTPProtocol for web communication.View in glossary calls
• Documentation that describes the happy path
• A support forum where your questions go unanswered

What the vendor does not give you:

• Retry logic for transient failures
• Graceful handling of rate limits
• Token refresh that does not race-condition under concurrency
• Error messages that tell you what to actually fix
• Bulk operations that do not require N sequential API calls
• Upload strategies that survive network interruptions

So you build all of it yourself. And so does the next team. And the next.

What the API User Advocate Is Not

These roles matter. But none of them close the gap between what the vendor ships and what production requires.

What the API User Advocate IS

The API User Advocate is someone who:

• Builds a hardened client layer between the vendor API and the developer
• Holds dual expertise: deep knowledge of the vendor’s platform AND production software engineering
• Translates vendor-centric APIs into developer-friendly interfaces

The output is not documentation. It is not a demo app. It is infrastructure: a layer that absorbs the API’s operational complexity so that every downstream developer does not have to.

The Advocacy Layer

Without the advocacy layer, every developer team builds ad-hoc solutions for the same problems. With it, the hard problems are solved once.

What the Advocacy Layer Handles

Every row in that table represents weeks of engineering time. Multiply by the number of teams integrating with the same vendor. That is the cost of the missing advocate.

Why This Role Barely Exists

The API User Advocate requires a rare combination of skills:

1. Dual expertise is uncommon. You need someone who understands the vendor’s platform deeply — its quirks, its undocumented behaviors, its operational limits — AND who can write production-grade infrastructure code. Domain experts rarely write systems code. Systems engineers rarely have domain depth.

2. Vendors do not fund it. Vendor engineering teams optimize for their own operations: uptime, throughput, feature launches. The developer’s experience of consuming the API is a secondary concern, addressed by documentation and DevRel, not by code.

3. Consultancies do not build it. System integrators bill for custom work. Building a reusable client layer that eliminates future billable hours is not in their interest.

4. Open source does not sustain it. API-specific tooling has a narrow audience. A Rust🦀RustSystems programming language known for safety.View in glossary library for retrying Autodesk API calls will never achieve the star count needed to attract sustained open source contribution. The economics do not work.

5. The gap persists. And so every team, in every company, in every industry, builds the same retry logic, the same token refresh, the same error handling — from scratch.

RAPS as Proof of Concept

We built this. Not as a thought experiment — as a shipping product.

The architecture maps directly to the advocacy pattern:

• raps-kernel is the advocacy core. It handles auth (2-legged, 3-legged, token caching, automatic refresh), HTTP (retry with exponential backoff, rate limit tracking, circuit breaker), and error classification (structured exit codes that distinguish auth failures from permission errors from network problems).

• 11 components consume it — the CLI, cloud functions, Python bindings, 7 API-specific crates, and the admin module. None of them implement retry logic. None of them manage tokens. None of them handle rate limits. The kernel does.

• 230+ CLI commands and 114 MCP tools are built on top of this layer. Every one of them inherits the same production-grade HTTP behavior without a single line of retry code.

The pattern works. And it is repeatable.

Beyond AEC: The Pattern Repeats

This is not an AEC problem. It is a vendor API problem. Everywhere you look, the same gap exists:

Every vendor API with enough complexity eventually needs an advocate. The question is whether each consuming team builds that advocacy layer independently — or whether someone builds it once.

What Comes Next

This post names the pattern. The next post in this series shows how we built it: “How We Built a 230-Command▶️CommandInstruction executed by a CLI tool.View in glossary Advocacy Layer in Rust” — covering the architecture of raps-kernel, the design decisions behind structured exit codes, and why Rust’s type system makes the advocacy pattern both safer and faster than the alternatives.