Your Vendor's API Is Not Your Friend

TL;DR: The API🔌APIInterface for software components to communicate.View in glossary you are integrating with was not designed for you. It was designed for the vendor’s internal architecture, then exposed with minimal adaptation. This is not a bug — it is a structural pattern that repeats across every major platform. Understanding this is the first step🔧STEPISO standard for 3D CAD data exchange.View in glossary toward building something that actually works.

The Scene

You are building an integration. The documentation says to POST a JSON📋JSONStandard data interchange format.View in glossary body to an endpoint. You do exactly that. You get a 401. No message, no hint, no breadcrumb. You check the token🎟️TokenCredential for API authentication.View in glossary — it is valid. You check the scopes — they match. You check the headers — correct. You spend two hours before discovering that the endpoint requires a different auth flow than the one documented, because the docs were written for a previous version of the platform that no longer exists.

This is not a skill issue. This is a design issue.

You are working against an API that was built to serve the vendor’s operational needs, then exposed to you as an afterthought. The documentation, the error messages, the auth flows, the rate limits — none of it was designed with your workflow📈WorkflowAutomated process triggered by events.View in glossary in mind.

The Structural Problem

This is not about incompetent engineering teams. The people building these APIs are often excellent engineers solving hard problems. The issue is incentive alignment. When a vendor exposes an internal service as a public API, the priorities are clear:

1. Security — the vendor’s, not yours
2. Stability — of the vendor’s infrastructure, not your integration
3. Scalability — of the vendor’s platform, not your use case

Your developer experience ranks somewhere below “updating the changelog.”

Auth complexity exists because the vendor needs it

Autodesk APS☁️APSAutodesk Platform Services - cloud APIs for CAD/BIM automation.View in glossary has two-legged🤖2-legged authServer-to-server authentication without user context.View in glossary and three-legged👤3-legged authUser-authorized authentication with browser login.View in glossary OAuth🔐OAuthIndustry-standard authorization protocol used by APS.View in glossary flows with different scope requirements, different token lifetimes, and different refresh behaviors. PTC Onshape requires URL-encoding client secrets that contain trailing = characters — an undocumented trap that burns hours. Dassault 3DEXPERIENCE requires separate authentication for each of its internal services, leading to developers logging in five times in one hour. Siemens Teamcenter SSO configuration⚙️ConfigurationSettings controlling application behavior.View in glossary demands understanding six or more parameters including proxy URLs, discriminators, and protocol settings.

None of this complexity exists because developers need flexible security. It exists because the vendor’s internal identity systems are complex, and that complexity was exposed rather than abstracted.

Bulk operations do not exist because the vendor’s architecture is per-request

You need to add a user to 50 projects. The API gives you an endpoint that adds a user to one project📁ProjectContainer for folders and files within a hub.View in glossary. You write a loop. The loop hits rate limits. You add backoff logic. Some requests fail silently. You add retry logic. You add error classification. You have now written an orchestration layer that the vendor should have provided.

This is not an edge case. This is the most-voted feature request on Autodesk Construction Cloud’s feedback forum — 344 votes, six years and counting, status: “Future Consideration.”

Errors are opaque because internal system names leak through

When a vendor API returns {"code": "BIM360_ERROR_0x42F1", "message": "Operation failed"}, you are looking at an internal error code that was never translated into something meaningful for an external consumer. The vendor’s support team might know what 0x42F1 means. You do not. The documentation does not. The forum post from 2019 where someone else hit the same error has no response.

Feedback requests die in public forums

Vendors maintain feedback forums to create the appearance of listening. The data tells a different story. When 96.6% of requests never move past intake, the forum is not a feedback mechanism — it is a pressure valve.

Cross-Vendor Evidence

This is not an Autodesk problem. This is a vendor API problem. The same patterns repeat across every major platform in the CAD📐CADSoftware for creating technical drawings and 3D models.View in glossary, AEC, and PLM space — and beyond.

The details vary. The pattern does not.

Naming the Pattern

This is not incompetence. It is vendor-centric design. The API is optimized for the vendor’s operations — their security model, their infrastructure constraints, their internal service boundaries. Your workflow, your deadlines, your error handling needs — these were never part of the requirements.

The result is an API that technically works and practically punishes you for using it.

The Anatomy of a Low-Convenience API

Every row in that table represents hours of debugging, thousands of lines of workaround code, and developer goodwill burned for no reason.

What Is Actually Needed

The vendor is not going to fix this. Their incentives do not align with your needs. The forum requests will continue gathering dust. The auth flows will remain complex. The error messages will stay opaque.

What you need is a hardened client layer between the vendor’s API and your code. One that:

This layer is not a “nice to have.” It is the difference between a weekend proof-of-concept and a production integration that does not wake you up at 3 AM.

We call this layer an API User Advocate — a system that stands between the developer and the vendor’s API, translating vendor-centric design into developer-centric behavior. It is not a wrapper. It is not an SDK🧰SDKLibrary for building applications on a platform.View in glossary. It is a hardened operational layer that treats the vendor’s API as an unreliable upstream dependency and protects you from its design choices.

The Series Ahead

This is post 1 of The API Advocacy Pattern series. We have named the problem. Next, we prove it repeats — with detailed evidence from four major CAD/PLM vendors that share nothing in common except their disregard for the developers building on their platforms.

Related:

• ACC Forum Analysis: 4,295 Requests, 96.6% Unresolved
• Authentication Chaos Across CAD Platforms
• The Bulk Operations Crisis
• File Translation Disasters