Autodesk Platform Services
Twin of the Autodesk Platform Services API.
Twin of the Autodesk Platform Services API.
| Covers | developer.api.autodesk.com |
| Auth | Client credentials, three-legged OAuth, RS256 bearer tokens |
| Webhooks | No |
| Operations | 30 |
Coverage
Two families are served: Authentication, meaning two-legged and three-legged
OAuth2 with OIDC discovery, userinfo and a JWKS, and the Object Storage
Service, meaning buckets, objects, signed upload and download URLs, batch
transfer and resumable writes. Data Management, Model Derivative, the ACC and
BIM 360 admin families and Webhooks sit outside this twin: a call to one
answers 501 in the gateway’s {developerMessage, moreInfo, errorCode}
envelope rather than pretending to work.
Credentials
Any well-formed client authenticates by default, so your existing APS client id
and secret need no change. Set auth.mode to enforced to accept only the
clients the world knows. See Credentials.
Mint at /authentication/v2/token; access tokens are RS256 JWTs and the
signing keys are published at /authentication/v2/keys. A client id has to
have Autodesk’s shape, 48 mixed-case alphanumerics, and anything else is
refused at the gateway before the secret is looked at. scope is mandatory on
the token request: omitting it is a 400, not an unscoped token. A
client_credentials grant cannot ask for openid, because there is no user
for it to assert.
Vendor specific details
- The credential is checked ahead of the family. Calling an unserved family
with no token is a
401, so a missing env var looks like an auth bug, which is what it is. - Signed upload and download URLs point back at this twin instead of at
s3-accelerate.amazonaws.com. Your code follows the URL it was handed and is unaffected, but the host differs from production, and an allowlist that pins the AWS host will block it. - Bucket keys are global and lowercase only,
[-_.a-z0-9]{3,128}. A deleted key stays taken for a moment before it frees up, and a key another client owns is never available. - The token endpoint reads
grant_typeandscopefrom the query string as well as the form body, so a client that puts them in the wrong place still gets a token.
Its own notes
Once a sandbox is running, this twin serves its own operating notes at
{control_url}/veris/manual: the credentials it accepts, the API versions it
serves, and the fault statuses you can arm against it. They are generated from
the same source as its behaviour, so they cannot drift.