Discrepancy between the resource server API response schema documented, and that returned by the API

Help
,
1

There is a discrepancy between the resource server API response schema documented, and that returned by the API. This kind of thing makes it extremely frustrating for developing clients against the Auth0 management API. Auth0 Management API v2
Response schema according to API browser:

{
  "identifier": "",
  "scopes": 
    "object"
  ],
  "signing_alg": "",
  "signing_secret": "",
  "allow_offline_access": false,
  "skip_consent_for_verifiable_first_party_clients": false,
  "token_lifetime": 0
}

Actual response from API :

{
  "id": "59675.....36e92a90d30",
  "name": "......",
  "identifier": ".....endpoints......cloud.goog",
  "allow_offline_access": false,
  "skip_consent_for_verifiable_first_party_clients": true,
  "token_lifetime": 86400,
  "token_lifetime_for_web": 7200,
  "signing_alg": "RS256",
  "scopes": 
    {
      "value": "test",
      "description": "test"
    }
  ]
}

Note the missing id, name, and token_lifetime_for_web fields. I asked a question previously about generating a client from API documentation (swagger) but received no response. Please, I implore you - if you have the up to date swagger documents, please make them available!

2

For the three fields you mentioned I can’t indeed see no reason why they can’t be documented, however, this is just my opinion at this time. I’ll check with the relevant team to see if there’s something I’m missing and if not push to have this documented.

In relation to Swagger, to my knowledge, there’s no currently documented and supported way to obtain such Swagger compatible information for the Management API; I know there’s a suggestion in the backlog about supporting this, but at this time I have no additional information about if/when it will make it. In addition, although the documentation should not lag behind the API for such long time, please take in consideration that exposing a new field is should not be considered a breaking change so the application performing calls should consider that possibility.

3

What frustrates me is that the api documentation UI must have been autogenerated from a swagger document. Why not just make that available somewhere? The source html of the UI even has a (hidden) link to the (out of date) definition.


base url: https://xxx.auth0.com/api/v2/api-docs, api version: 2

4

Yes, but going from an implementation detail to something that is explicitly linked to means it would have to be formally supported which is something that at this point is not planned.