Autodeskautodesk.com
Autodesk's API program shows strong foundations in API design, discovery, and agent usability, but two areas represent meaningful friction for partners and their AI agents: Developer Experience is the clearest gap, with no self-service onboarding path, no code samples, and no published changelog — meaning partners can't get started independently or trust that their integrations won't break silently. Agent Understanding also needs attention, as the absence of structured metadata in docs prevents answer engines and AI agents from accurately surfacing and citing Autodesk's APIs.
API DesignA clean, typed, well-governed API contract agents can reason about4 pass1 warn0 fail94A+
| Signal | Points | Findings | Rationale | |
|---|---|---|---|---|
| pass | Machine-readable, versioned contractvia spec | 25/25 | The API declares version "1.0" and uses url-based versioning, so an agent can pin to a stable contract. Investigated: spec 100%, docs 100%. | A current OpenAPI version with a declared versioning scheme lets agents reason about the contract. |
| pass | Schema coverage & depthvia sdk | 25/25 | 9/9 (100%) public params are fully typed (no any/**kwargs). Analyzer confirms all methods have a derivable input schema. Investigated: sdk 100%, spec 62%. | Typed, complete request/response schemas are what make agent function-calling possible. |
| warn | Auth declared & discoverablevia spec | 18.8/25 | The spec declares no authentication scheme, so an agent can't tell how to authenticate a request. Investigated: spec 75%, docs 75%, wellknown 0%. Fix: Declare an authentication scheme and apply it globally or on every operation that requires credentials. | Agents can only call an API when they can determine its auth posture — a declared scheme, or an explicit statement that none is required. |
| pass | Security & governance hygienevia sdk | 15/15 | Code is formatter-clean with zero linter errors and zero style warnings. Investigated: sdk 100%, spec 80%, wellknown 0%. | No leaked secrets, no critical lint violations, no OWASP API Top-10 spec smells, and a published vulnerability-disclosure channel. |
| pass | Example coveragevia spec | 10/10 | Only 25% of parameters and responses (65 of 263) include example values, so an agent has little grounding in real payload shapes. Investigated: spec 100%, sdk 100%, docs 0%. | Examples carry shape semantics schemas under-specify — for humans and agents alike. |
Developer ExperienceThe context both developers and agents need to integrate fast — onboarding, code samples, complete descriptions and worked examples2 pass0 warn3 fail55D
| Signal | Points | Findings | Rationale | |
|---|---|---|---|---|
| pass | Quickstart presentvia docs | 25/25 | Quickstart at https://get-started.aps.autodesk.com/ includes a runnable first-call code sample. Investigated: docs 100%. | A quickstart is the fastest path from landing page to first successful call. |
| pass | Description completenessvia spec | 15/15 | Only 23% of operations and parameters have descriptions (12 of 36 ops, 23 of 181 params), leaving an agent to guess what most endpoints do. Investigated: spec 100%, sdk 95%. | Complete descriptions are the context humans and agents need to use endpoints. |
| fail | Self-service developer portalvia docs | 0/29 | No self-service signup detected — no signup link on the homepage or docs, and no conventional signup path (/signup, /sign-up, /register, /get-started, /console/signup, /dashboard/signup, /try, /try-free, /free, /free-trial, /start, /start-free, /join, /create-account, /account/signup, /auth/signup, /users/sign_up) resolved — so an agent can't onboard on its own. Investigated: docs 0%. Fix: Publish a public signup endpoint and link it from your homepage/docs to compress time-to-first-call. | A first call without a human in the loop — self-serve credentials, a free tier, or an API that needs none. |
| fail | Code samples in docsvia docs | 0/18 | No code samples detected across 1 sampled docs pages, so a coding agent gets no ready-to-use examples. Investigated: docs 0%. Fix: Add copy-pasteable code samples to API reference and quickstart pages. | Multi-language samples shorten time-to-first-call. |
| fail | Changelog publishedvia spec | 0/13 | No changelog link or mention appears in the spec, so an agent can't tell what changed before something breaks. Investigated: spec 0%, docs 0%. Fix: Publish a structured changelog (e.g., /changelog.json or releases.atom) and reference it in info or externalDocs. | A published changelog lets partners track changes without surprise. |
Agent DiscoveryPartners and their agents can find your APIs — llms.txt, registries, crawlable and reachable docs3 pass1 warn0 fail93A+
| Signal | Points | Findings | Rationale | |
|---|---|---|---|---|
| pass | Docs reachable, not hard auth-gatedvia docs | 30/30 | All 1 pages are publicly accessible. Investigated: docs 100%. | Agents can only index and fetch docs they can reach — past auth gates and over correct HTTP semantics. |
| pass | Registry & SDK presencevia docs | 28/28 | Indexed on Context7 (websites/help_autodesk_view_vredproducts_2027_enu, 9164 snippets). Investigated: docs 100%, sdk 92%, cli 0%. | Listing in MCP registries and publishing SDKs puts the API where agents and their tooling look. |
| warn | llms.txt present, valid & comprehensivevia docs | 22.5/30 | llms.txt covers 0/1 sitemap doc pages (0%); 1 missing — Missing: https://aps.autodesk.com/developer/documentation. Investigated: docs 75%, sdk 0%. | A valid, comprehensive llms.txt is the machine-readable entry point for agents. |
| pass | Crawlable / AEOvia wellknown | 12/12 | robots.txt lets all monitored AI crawlers reach the docs paths. Investigated: wellknown 100%. | Bots allowed plus a fresh sitemap make docs findable by agent crawlers. |
Agent UnderstandingAgents can correctly interpret your APIs — machine-readable errors, consistent descriptions, structured data, parseable docs3 pass1 warn1 fail88A
| Signal | Points | Findings | Rationale | |
|---|---|---|---|---|
| pass | Machine-readable errors (RFC 9457)via docs | 28/28 | No error responses (4xx/5xx or a catch-all default) are documented anywhere in the spec, so an agent can't anticipate or handle failures. Investigated: docs 100%, sdk 100%, spec 50%. | RFC 9457 problem details and a documented error-code inventory let agents parse failures without burning tokens. |
| pass | Operation purpose clarityvia sdk | 25/25 | Surface uses a single dominant casing convention (camelCase). Investigated: sdk 100%, spec 90%. | Agents select the right endpoint from its summary + operationId; clear, named operations make tool-selection reliable — the strongest driver of correct tool choice. |
| pass | Agent-navigable, token-efficient docsvia docs | 22/22 | All 1 pages contain server-rendered content. Investigated: docs 100%. | Server-rendered, clean, small-footprint docs are what an agent can cheaply fetch and parse correctly. |
| warn | Agent instructions file (AGENTS.md)via sdk | 5/10 | No agents.md or skill.md context file found (nice-to-have for agent operation). Investigated: sdk 50%, wellknown 0%. Fix: Add an agents.md or skill.md describing how an agent should use this SDK (auth setup, key operations, gotchas). | An AGENTS.md gives coding agents explicit setup, auth, and usage instructions to interpret and operate the API — beyond llms.txt's link index. |
| fail | Docs structured datavia docs | 0/8 | No JSON-LD or OpenGraph/meta tags found across 1 assessed pages (1 JS-rendered), so answer engines have nothing to cite. Investigated: docs 0%. Fix: Server-render structured data (JSON-LD) so AI answer engines can cite your docs. | Structured data (JSON-LD/schema.org) on docs pages gives agents an unambiguous parse target and is what answer engines cite. Detected on the JS-rendered head (Firecrawl) for a bounded page budget, so JS-injected JSON-LD is now caught; pages we can't render are excluded rather than failed. |
| na | Description consistency across surfaces | —/7 | Only 1 surface description(s) with ≥6 tokens available; need at least 2 to compare. | Every surface tells the same story about what the product is. |
Agent UsabilityAgents have the context to use your APIs reliably, not just find them4 pass0 warn1 fail81A
| Signal | Points | Findings | Rationale | |
|---|---|---|---|---|
| pass | Idempotency documentedvia sdk | 27/27 | Built-in retry machinery is present (grep-derived). Investigated: sdk 100%, spec 0%, docs 0%. | Documented idempotency lets agents retry safely. |
| pass | Pagination documented & consistentvia sdk | 22/22 | 6/6 list method(s) return an auto-paginating iterable. Investigated: sdk 100%, docs 67%, spec 58%. | Consistent, documented pagination lets agents traverse collections. |
| pass | Sandbox separationvia sdk | 20/20 | Sandbox environments are exposed (sandbox). Investigated: sdk 100%, spec 0%, docs 0%. | An isolated environment lets agents exercise destructive operations safely. |
| pass | Runnable collection with test scriptsvia sdk | 9/9 | README is present and includes a runnable quickstart. Investigated: sdk 100%, platform 0%. | A public, maintained collection with assertions is runnable truth agents validate against. |
| fail | Rate-limit signalingvia spec | 0/22 | No rate-limit response headers are documented, so an agent can't tell when it is approaching a limit and will get throttled. Investigated: spec 0%, docs 0%. Fix: Add x-ratelimit-* response headers and document retry-after semantics. | Machine-readable rate-limit headers let agents throttle adaptively. |
Resources Discovered
The public resources we found for Autodesk — the evidence behind the score. All discovered from public sources; nothing here requires access to your systems.
| Agent hints | Context7 (9,164) |
|---|---|
| APIs analyzed | 10 — Data Management, Autodesk PWS Sales & Customer Success APIs, Construction.Account.Admin, Autodesk PWS Quoting and Ordering APIs, oss, Construction.Issues, Model Derivative, Webhooks, Secure Service Account, Authentication |