This new standalone page has all the same information, but provides a purpose-specific page layout. The left-hand navigation displays the API operations, grouped by category. It can be pinned open for use on larger displays or collapsed to fly out on hover for smaller displays. Clicking on a resource opens it in the tabbed content in the main window.
The account switcher and dark mode toggle work the same as the main site. To exit the standalone interface and return to the main site, click the "Return to Developer Center" button in the header.
There are also two new features in the request body editor to help ease the workflow for power users.
There is a button to load a stubbed out JSON object based on the request's schema. If you're writing requests by hand instead of using the wizard editor, this will give you a quicker starting point. Click the "Load empty schema" button at any time to reset the JSON object to the default schema.
Pro mode! If your primary interest is editing the JSON object instead of using the guided editor, enable pro mode. This will replace the guided request builder with the more compact schema documentation.
Coming soon, this standalone API Explorer instance will replace the legacy dev tools in the Genesys Cloud embedded client app.
If you have any feedback, please reply to this post or create a new topic in the site feedback category.
Change Category
Infrastructure
Informational
Change Context
Feedback was received from the community that the legacy developer tools (which are slated for removal) offered a more convenient interface for some use cases. This standalone tool attempts to incorporate that feedback into the new API Explorer tool.
One suggestion: Having only one nesting level in the endpoints list can be a little bit messy... It would be nice to have sub-categories for each API, as the legacy developer tools had.
Another suggestion... AFAIK, the Legacy Analytics Query Builder feature is being absorbed by these new API Explorers. But the old one had something that the new one does not have: An Interval string builder via UI.
It's kinda annoying having to write the interval manually with the ISO 8601 format, as now it is just "string". It would be nice to have a similar feature to make it easier.
There was an interval picker for a while, but it unfortunately caused more problems than it solved so we reverted it to a plain string. I'll take another pass at trying to find a workable off-the-shelf solution as part of this effort; it's a ludicrous amount of work to build a custom date picker component from the ground up, which is why it hasn't been prioritized yet.
Oh, so it's one of those things that seem simple at first but end up taking an absurd amount of time... It's surprising how often it happens.
However, for people without a developer background, but who still want to have basic usage of the API, the format can be... intimidating. That date picker is way more user-friendly for them. But I understand it not being worth the effort that it takes.
Would you be open to using a new base-10 method of counting dates and time? That would significantly reduce the effort... lol. The intervals at which our planet spins and orbit the sun are quite inconvenient when juxtaposed with our numbering system. It makes every calculation a corner case; there is no "normal" way to handle any of it.
I've been looking at some component packages this morning, and I think we can get something in place without a ton of work.
Adrian, one thing that I've found useful is to open Genesys Cloud in a web browser, not the desktop app.
Navigate to the Performance workspaces and use the UI there to setup the date ranges and filter criteria that you want. When you've got it returning the records that you expect then open the browser's developer tools, navigate to the network tab, and the hit to refresh button on the performance workspace. That will cause the workspace to execute the Analytics query and you can then find that query in the network trace to find the payload that it is sending. Copy and paste that payload into your code and away you go.
There's an issue with category filtering on the category-specific API doc pages. Will get a fix out early next week for those pages. The category filters in the main API Explorer page or the standalone should still work for this purpose in the meantime.
I think that if someone has no problem dealing with the browser dev tools, then he or she shouldn't be having problems with Datetime formats hahahaha
Anyway, this is just a convenience thing. If someone has to learn the ISO 8601 format, then, it's ok. I was just mentioning it as the legacy tools had it. But it's far from being a must-have thing, of course.
One of the great features from the legacy tool was that it remembered your tabs. I would leave all the tabs I would frequently use open and have easy access to them each time I visited the page.
Not only does it remember your tabs, but the list of open resources is shared with the toolbox so you can continue to access them as you browse around the site.
An additional improvement has been deployed for the dev center app to cache the OpenAPI definition file locally in the browser's Indexed DB storage until it detects that the Platform API has been updated and has a different build number. This should mean that your browser will load the 13MB definition once every week or two (the API's deployment cadence) instead of once every 50 minutes per the file's cache header.
