Recent searches
No recent searches
Zendesk OpenAPI
Posted Mar 28, 2021
Is there an Open API spec / Swagger file for Zendesk? I've seen a few threads from a while ago but wondered if there's any updates:
- https://develop.zendesk.com/hc/en-us/community/posts/360028870454/comments/360004529253
5
26
26 comments
Official
Sanjeev Mandalapu
Thank you all for you patience and understanding.
The schema file is now available in the Zendesk Developer Docs > Download Open API file.
We have prioritised Ticketing APIs in this release and will work to make the schema available for other APIs as well.
Greg Katechis has been very active and instrumental in pushing this up the priority list internally.
0
Greg Katechis
Hi Jamie! We don't have this yet, but we are rapidly getting to the point where this will be available. We have been on a company-wide project to get all of our documentation into the OpenAPI spec and once that is complete, the work to get this exportable will begin. I'm banging on the drum for this too and I'm very excited that we're finally getting close, so you have internal allies!
0
Jamie Cuffe
Hi @... - thanks for the response and excited to hear that! Any chance we could be added to a beta for the openapi spec even if for limited endpoints? At Retool we have a ton of customers using our product with Zendesk for support and operations flows. We'd love to get a partnership going here!
0
Greg Katechis
I'm not sure if we are opening up any of that in beta, but I will check next week when I meet with that team and I'll let you know after the meeting what I find out!
0
Test Test
Hi Jamie, I was facing the same issue and decided to do something about that, I have released some basic yaml with endpoints I was using during work.
https://github.com/ItamarBittton/zendesk-openapi
Hopefully you will find that useful :)
1
Amjad Talib
Hey @...,
Following up on this question, how's the progress on the OpenAPI spec? Is there an EAP available or plans to make one available before a general public release?
Thanks in advance for the info,
Amjad
0
Paul West
Any further news? Seems very odd for a company of this size not to have an Open API spec...
0
Greg Katechis
Hi Paul, apologies for the delay on this one, it has been a lot of work getting all of our APIs up and running on this project. We have been working on making the OAS publicly available and I'm not sure what that timeline is looking like. I'm going to reach out to the team responsible for this today and when I hear back, I'll drop an update here for everyone!
1
Mitch Ryan
Gidday Greg, what was that update?
0
Stewart Armbrecht
Any update? Is there any place we can go to get a partial file?
0
Grant Rodger
Hi Greg Katechis,
Any news on when your API documentation will be available in the OpenAPI spec? Either publicly, or via a beta/early access programme?
Thanks,
Grant
0
jon
+1. Any chance that work on this has been completed yet? This would definitely help us stay organized and create a clean API layer for Zendesk through our internal systems. Greg Katechis
1
Greg Katechis
Hi all! Could you take a look at the Postman collection that we have for our APIs and let me know if that will give you what you're looking for?
0
Mitch Ryan
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.
5
Daniel Williams
Any updates on when this will be available?
1
Beto DJ
Greg , Greg, Greg .... so many promisses ... so many broken ...
1
Serge Pincon
Greg Katechis More than 2 years ago since you mentioned that we should "rapidly" get the Open API spec.. Any news and/or ETA?
It feels ever more awkward as it seems as if you are using GraphQL yourself for your clients...
1
Mitch Ryan
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.
0
Serge Pincon
https://support.zendesk.com/hc/en-us/community/posts/4486825535258-What-is-the-Access-log-API-
Quote (1st official comment): A large part of our frontend uses a tool called GraphQL. For the purposes of this EAP it means that the URL path is obfuscated and we don’t know what was accessed as part of the request an agent made. You will see this /graphql path in some of the URLs.
1
Mitch Ryan
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…
0
Enrico Stahn
Greg Katechis Any updates on that OpenAPI schema?
0
Brandon Taylor
Wondering the same?
0
Daniel Williams
@Sanjeev Mandalapu
Is there a way to generate the OAS for our specific instance of ZD so that it includes custom fields, objects, etc?
0
Mitch Ryan
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.
0
Sanjeev Mandalapu
Daniel Williams: Nah! We wanted to keep it generalised for now as part of the (initial) documentation offering. I will take your suggestion/feedback to the team and do a feasibility check to do such customised generation within the Admin Centre UI.
Mitch Ryan your comments on this page are a good start. The team are working on the reported `items` already. The trailing .yaml is a source file issue and is being rectified too. We will post an updated file soon in the documentation.
With more OAS files (as we cover more products), we will create a public GH repo which could help with issue management.
Honestly, thank you for the feedback in improving this resource.
0
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:
Thanks again, looking forward to further fixes and improvements.
0