Mitch Ryan

@... I see that the OAS has been updated with fixes to remove the erroneous trailing ".yaml" in schema names, and to address the malformed array schema, that's already a big improvement, thanks.

Here are some schema which I've identified to still contain array-types without `items` properties:

• GroupSLAPolicyFilterConditionObject
• TriggerActionObject
• TriggerChangeObject
• TriggerConditionObject
• AuditObject

Thanks again, looking forward to further fixes and improvements.

Thanks for the new OpenAPI schema. I've found a couple of issues with it. Let me know if there's a better place to leave these bug reports.

Many fields/properties of `type: array` either:

1. Have no `items` property altogether. As one specific example, the `TicketUpdateInput` schema has a `tags` property, which is `type: array`, but does not specify items, and therefore we cannot programmatically determine that this is (presumably) an array of strings.

2. Have specified a `properties` property instead of an `items` property. Consider the example of `PushNotificationDevicesInput`, which is `type: array` but has `properties: …` instead of `items: …`.

Additionally, some schema/component names have a trailing `.yaml` for some reason. I assume this is erroneous, but I could be wrong.

Sanjeev Mandalapu - thanks for the long awaited update. Where should we post bugs+issues with the OpenAPI schema?

To give an example: many fields/properties of `type: array` either:

1. Have no `items` property altogether. As one specific example, the `TicketUpdateInput` schema has a `tags` property, which is `type: array`, but does not specify items, and therefore we cannot programmatically determine that this is (presumably) an array of strings.

2. Have specified a `properties` property instead of an `items` property. Consider the example of `PushNotificationDevicesInput`, which is `type: array` but has `properties: …` instead of `items: …`.

Additionally, some schema/component names have a trailing `.yaml` for some reason. I assume this is erroneous, but I could be wrong.

See also:

https://support.zendesk.com/hc/en-us/community/posts/4408861024794-Zendesk-OpenAPI

and 

https://support.zendesk.com/hc/en-us/community/posts/5054285989914-Zendesk-Types-For-Typescript-Nest-js-

There's currently no actively-supported strongly-typed Node/JS SDK for the Support API, which I strongly suspect is because there is no known publicly-available OpenAPI schema published for this API. If one were to be published, I could code-gen types, helpers and SDKs for this API. An admin in the support community indicated a couple of years that Zendesk engineers were working on this, and that he would have news for us "shortly" (2 years ago) and now does not respond to further messages in the thread.

Ah, I misunderstood, I thought you meant that Zendesk's official clients (SDKs) were accessing data over GraphQL.

Back to you for that update now Greg…

Serge, could you please provide a source for that statement (that GraphQL is being used in the clients)? If that's true, then we might be able to reverse-engineer the client source to find the GraphQL API URL, and therefore be able to do introspection.

Nope, that won't do for our needs sorry Greg. That documentation is really no more useful than the written documentation provided here. It does not solve the needs of developers who need machine-readable definitions for request and response types, aka DTO (data transfer objects). In other words, we can't use this documentation to generate an SDK, because it doesn't document things as simple as what a "Ticket" object looks like*. There's a reason why people are asking specifically for OpenAPI definitions, because there's already a massive body of open-source tooling built upon it. Conversely, one of the reasons why there's not such a body of open-source tooling built upon Zendesk (such as a stable + actively maintained Node/Javascript/Typescript SDK) is because Zendesk does not publish its DTOs in a machine-readable format.

*I am aware that there are "example responses" for the "Show Ticket" request - but demonstrating an instance of a ticket response is not the  same as the blueprint/schema of a ticket response. The latter would show *all* possible properties, which one of them are optional/nullable, what type (eg. `string`, `number` etc) they are.

Tipene Hughes I would just like to point out that if you had published OpenAPI definitions for your APIs then this would not be a problem, because we could programmatically generate types using popular open-source tools. Zendesk is neither providing official SDKs, nor the resources that the open-source community requires to build their own, and that's baffling to me, for a service of Zendesk's market share.

Perhaps you could weigh in on this other topic where a fellow support representative said two years ago that OpenAPI definitions were "getting close".

Greg Katechis, please I'm begging you, could you please respond to this issue here: https://support.zendesk.com/hc/en-us/community/posts/4408861024794-Zendesk-OpenAPI

You indicated a long time ago that you would have some news available for us very soon, but we haven't heard from you since and you don't seem to respond to people tagging you in that response so I had to find you here instead.