API Console feature
RomanHotsiy opened this issue · 117 comments
Implement API Console functionality.
Each method in ReDoc will have a button: “Try this method” which will open interactive console modal window.
There is the list of key features that should be implemented in the first version:
- Ability to send GET, POST, PUT, DELETE, UPDATE requests
- Ability to input/use/save authorization credentials
- Show UI for easy entering parameters for path, headers, query and body (payload) parameters
- UI should show selectbox for enums, checkboxes for boolean, text input for other simple types
- Request should be validated before send according to OpenAPI spec
- Support different environments (e.g. sandbox, dev, testing, etc) through OpenAPI vendor extension (each env will have unique base url and description) + ability to set default env specially for API-console
- For most parts response will be shown “as is”. JSON response will be only prettified (with possibility of collapsing). The other responses will be represented as strings.
- Show response headers that are documented in swagger. HTTP response headers that are not documented will be hidden under “Show undocumented response headers” button
A few mockups:
Do you have a timeline for this feature? If you are done with it, SwaggerUI should be replaced by Redoc as the official solution ;)
@SebastianStehle can't promise anything. It is on our list but before we have a few other things to implement. I will update the roadmap shortly.
Hopefully, we will get this ready in 3-4 months
Hey, any update on this?
API Console is one of the priorities now. But so far we haven't started working on that :(
This seems to be the next big task on our roadmap.
I will post here once we start work on this.
It may be good if the console can also send PATCH requests too.
About the support for "different environments" in the description of this issue, I don't think this should be a priority: the host and the basePath are specified in the Swagger spec and allowing to switch environments would imply to override the information from the spec. But there would be a much simpler to way to have this feature: have multiple instances of ReDoc with its own spec with the specialized spec with the specific host/basePath settings. That's how I'm handling multiple environments with swagger-ui right now.
Note that sandbox/dev/testing environments are usually not information you want to expose (and accidentally leak), so using a vendor extension of the spec does not seem to be the right place.
It will be awesome to have API Console. +1
+1 for API Console. Do you guys have a timeline for this?
+1 for API Console.
+1 for API Console
+1 for API Console
+1 for API Console
+1 for API Console
Please stop adding "+1" comments. Use instead the reaction feature of GitHub.
You can even delete your own useless comments!
Hey @RomanGotsiy Thanks for such an awesome API documentation tool :) Are you currently working on implementing API console ? Do you have any timeline for this feature?
@j26nz no, I'm on 2-week vacation now and don't have any timeline for now.
I have this partially implemented for very simple use-cases but swagger has so many ways to describe the same thing that there's still a lot of work to finish this.
I will try to keep all you guys updated on the progress
@RomanGotsiy - did you all look into the support that Postman has for generating collections from swagger? (you have to scroll down a bit)
I'm not saying that there's no reason for ReDoc to have a console, but if there's another workable option, I wonder if there are other features that would be more valuable. Especially when I think about not only the complexity of supporting the multiple ways of expressing the same thing that OpenAPI supports, but also the tough time properly supporting built-in security features and allowing for user extensions.
I know the community is really looking forward to a built-in console, but having come to ReDoc from the disappointments of SwaggerUI, I'd hate to see this great tool get bogged down in the implementation and support of a "nice to have" feature when there are workable alternatives.
I hope over the next few days to look into Postman's support and will share my experience here too.
Update on trying out Postman-generated collections, first impressions:
- imported a couple specs that make use of "advanced" OpenAPI features without issue, including:
- use of
discriminator(polymorphic types) - use of
additionalProperties
- use of
- interpretation of markdown in descriptions (including tables and fenced code) ...
- (this is a little bit handy, but I'd still have the ReDoc rendering for real documentation)
- ability to add a pre-request script for calculating any security headers
Generated Postman collections look good for our use cases, at least. We'll proceed beyond the quick POT I've done and see what more we learn.
@RomanGotsiy (and others) I would be really interested in hearing about your exploration of generated Postman collections and understanding what advantages a custom built-in API console has over them.
Thanks for the update @seanpk .
I have this partially implemented for very simple use-cases but swagger has so many ways to describe the same thing that there's still a lot of work to finish this.
@RomanGotsiy you can release a very simple version. After releasing, people interested in more features will create new issues.
hey @RomanGotsiy like @raderio said Is it possible for you to release a simple version of API console or you can put it on a separate branch and people interested in more features can start contributing to it. Thanks.
hi is there any update on this feature. May be we can have a PR for this??
@indolent-developer @j26nz @raderio sorry for the long delay. The last couple of months were pretty busy for me.
For those who haven't seen it yet, I'm migrating ReDoc to React. Here is the corresponding issue to track: #327
Console feature is definitely the next in the queue but there is no point to work on it before I finalize React version.
Thanks for being patient and for pinging me! It really motivates me to work on this!
This is a great feature for us. It would be useful to have in ReDoc (vs. Postman) for us because we want to provide an integrated online experience.
@RomanGotsiy Do you have a better idea when this can be available now? It looks like #327 is nearing completion but it is still open and the latest release is v2.0.0-alpha.5.
Per @j26nz and @indolent-developer, if it will speed things up, is it possible to allow others to start working on this to send a PR?
Hey @RomanGotsiy ! is this feature still on roadmap and is something will see soon?
@grokify @j26nz this feature is still on the roadmap! T
I just have to finalize #327. There is a bit of dirty work left that I want to finish before letting other to start working on this.
I will try my best to finish this asap (ETA is 1 week)
Also, I have already implemented a dead-simple try-with console based on angular version. I can't share it but I think I know where should we start from. I will share updated requirements for this feature soon.
Great @RomanGotsiy! We'll try out v2.0.0-alpha.10 and let you know our feedback.
Thanks @RomanGotsiy. Did you get a chance to update requirement for this feature? Thanks.
A word of caution when implementing this for API console purpose is to handle redirects properly. Browsers follow redirect transparently. There is no way to prevent it in XHR, but the Fetch API allows redirect: manual as an option when creating a request. This will make sure that the browser does not automatically follow if the returned response is 3xx which might be the expected response as per the documentation of a specific API endpoint. If the browser follows redirects then the console will never be able to show what was returned from the server. Imagine documenting a URL shortner service API where a 301 response with an appropriate Location header woyld be more interesting than letting the console dereference and load the eventual URL.
I think redirect can be added later, usually API do not use redirects.
I think redirect can be added later
Any particular technical motivation/reason to push it back?
usually API do not use redirects.
I differ from you on this. While 3xx codes might be less common than 2xx in documented APIs, they are more common than 5xx and perhaps 4xx.
Any particular technical motivation/reason to push it back?
To release this feature as soon as possible.
To deliver this feature as soon as possible.
I did not propose anything difficult, I just noted it here not to miss this caveat and mentioned the potential solution too.
@ibnesayeed thanks for the note! 👍
@raderio no need to worry. Adding one field to request option won't take so much time 😄
@j26nz didn't have time to update requirements. But I can share a gif of what I have right now locally:
And here is the request with request body payload:
@RomanGotsiy, thanks for the preview. By looking at these GIFs, I feel like a toggle switch is not a suitable/intuitive UI element to use for this purpose. It is best suited when the state of an object or the value of a field is toggled, for example, enabling/disabling dark mode of a UI or enabling/disabling airplane mode in a device. Try it out is more like an action, hence a button UI will make more sense here.
@ibnesayeed thanks for the note! +1
@raderio no need to worry. Adding one field to request option won't take so much time smile
It is possible that the real documented response of an API endpoint is served after a few redirects (though, cases like that should be documented) while in other case the redirect response itself is a potential valid response. To handle situations like this, there are a few approaches that can be used:
- Match the response with documented response signatures (to see if redirect response is expected, if so, then display that otherwise follow the redirect)
- Make it part of the API documentation to add an annotation that tells the UI whether following redirects is intended or not (with not following as the default).
- Add a toggle switch in the Try it out UI to Follow redirects (disabled by default) and let the users decide what they want
- In the response UI, add a Follow next link button to allow the user to step through redirection chain manually, only if the returned response has a
3xxstatus and contains aLocationheader
In the response UI, add a Follow next link button to allow the user to step through redirection chain manually, only if the returned response has a
3xxstatus and contains aLocationheader
Actually I believe that could also be useful for 201 status codes, that provide a link to the newly created object. Those responses may also provide a Location header.
Actually I believe that could also be useful for 201 status codes, that provide a link to the newly created object. Those responses may also provide a Location header.
It occurs to me that we can also show such a button if the response contains a Content-Location header, irrespective of the response code.
This feature would be useful to release even with a bare minimum of features
Indeed, could be a game changing feature and make us use redoc instead of swagger UI v3 which became awful compared to v2.
Still don't know why they now all of a sudden have to wast half of the space on my screen, make me scroll endlessly and provide no visual clue anymore where a parameter starts or ends...
Absolutely! We will try to "Make Swagger Console Great Again" 🇺🇸
I pledge to release it soon after 2.0 release 🎉
Thanks @RomanGotsiy any ETA for this?
This feature is the last that stopping us to switch from swagger-ui. Really waiting for it!
@RomanGotsiy Entire world is waiting for this feature.... Please add it soon...
@RomanGotsiy we at Nutanix really like your ReDoc platform. We are looking at replacing it with current swagger ui we use. API Console feature is something we cannot live without. I have forked this repo and would start working on this. I'll follow the ui mocks that we have in this issue and keep everyone in the loop.
If someone has already started working on it please let me know, otherwise I'll keep marching.
Any recommendations for what validator to use for validating request payloads against schema. I have used AJV before and is quite good. Also for building complex request payload I was thinking of using an editor like ace. Schemas get complicated and editor will be handy.
Few other issues I noticed are #461 and slowness for large spec files as everything is rendered right away. Lazy render or rendering only selection endpoint/operation will help.
@harjeethans I cannot speak for the project owner but I think it's safe to say that your work is much appreciated by the community. The lack of response probably isn't due to lack of interest but rather the fact that he had a mad dash getting 2.0 out of the door and needs a little break.
I for one am very excited for this feature.
Personally I would not pull in a heavy depency like ace for the first iteration of the feature, but rather get something out of the door quickly and easily. To me, even a very stripped down version, that doesn't have a lot of features, would be extremely helpful.
@harjeethans - we've used tv4 + some code for handling polymorphism (models that use discriminator) and request parameters.
We run it in node, but can probably get extracted if you like. I think this code would be the place to start looking ...
Also, I mentioned above, on this this issue, how we were going to start using Postman collections generated from our swagger. That has really turned out great for us. Not only are we able to share the docs with our API users, but we're giving them executable samples in the Postman collection that we know work. It has got to the point where non-technical business users are also using those collections to explore behavior and to confirm that business rules are properly implemented.
An even bigger benefit of that investment is that we've hooked Newman into our deployment pipeline to run API tests automatically.
I bring this up again because I'd recommend that approach to anyone who asked (and clearly a bunch of folks who didn't) over counting on a console in the docs. For us, at least, the console is a nice to have, but it is no longer a requirement at all.
Here is an update, the api invocation works to some extent, for my samples I have used a proxy with basic auth but will have to work on it. Also validation is running into some issues. OpenAPIParser.ts has deref at https://github.com/Rebilly/ReDoc/blob/master/src/services/OpenAPIParser.ts#L148 and it is not dereferencing the schema. Some of the open source validators either run into issues with OpenAPI 3.0 . Will have to research a bit more on that.
Hey @harjeethans!
Sorry for not responding for the last two weeks... I was getting married: https://twitter.com/RomanHotsiy/status/991280469332422656
Thanks for your interest in the feature and your efforts to implement it.
Unfortunately, I don't have much time to help you with this right now 😞.
I need a short break (~1 month) on ReDoc to build an MVP of a new product based on ReDoc we are working on.
Check out an article: https://medium.com/redoc-ly/from-redoc-to-redoc-ly-42319f100ac0
Because of this, I would not be able to review your work for at least next month.
You're free to use anything you find convenient (just one restriction - try to keep bundle size small, i.e. do not use heavy deps).
Also, this feature will definitely not get into 2.0. Most likely it will get into 2.1.
I will get back to this once I'm done with MVP and release ReDoc 2.0.
Thanks again for your hard work!
congratulations @RomanGotsiy my apologies had I known, would have mentioned you. Have fun and enjoy, let me add more to it and will get back.
Hi @harjeethans!
Could I checkout your implementation, for my demo about ReDoc. Thanks.
@longit644 you can checkout https://github.com/nutanix/ReDoc/tree/add-validation that we forked from ReDocs. It uses proxy in dev environment to connect to api server. We have no-cors for our api server and had to do it this way for development environment. If you do not need it you can remove proxy settings from package.json
Hi @harjeethans ,
I just did a demo about ReDoc. I'm trying to move away from swashbuckle and this looks like my best bet. My only worry is the test console. I see it's on the roadmap. Could you please share the expected timeline for this feature?
Thanks
Congratulations! I will get married, too.
Hi, do you know when approximately this feature will be implemented ? I think you can commit initial version then gradually add new features to api console.
I'm also waiting for this feature, thanks :)
While waiting on this issue, I hacked up a small demo for the try-out feature using JQuery to provide some basic features, hopefully being a stopgap solution before the real implementation is released. You can find it at https://github.com/edmunds/redoc-tryout
A demo has been setup at:
http://technology.edmunds.com/redoc-tryout/demo.html
Was busy with some work and just got some time for Console, I have made few minor changes to enable console as part of option that we pass to ReDoc like
const specUrl = '/static/v3/swagger.json';
const options = {
theme: {baseFont: 'ProximaNovaSoft'},
providedByName: 'Intent ApiDocs by Nutanix',
providedByUri: 'http://www.nutanix.com',
enableConsole: true
};
Redoc.init(specUrl, options, document.getElementById('redoc-container'), (args) => console.log('Done bootstrappoing docs!'));Will enable/disable console. Few other options like provider* for setting up right name url etc for a hosting. Had to spend some time pulling from master and making sure everything works as expected.
Few minor things I'll clean up and then post a PR, here is a gif of ReDoc hosted on out local Nutanix cluster enabling Console feature.
Was debating for a lean JSON editor for forming request with some sort of validation against the schema. Started with Ace but adds a lot of generated bundle. Also do we add a full screen button to pull out request response for easy visibility. At Nutanix most of the request and response are quite large and small space available right now does not scale very well. We can make it configurable if all of us do not want it.
I'm using the workaround proposed by @yuhanz but I need can select the 'Content Type' (application/json, text/json or text/xml). Some suggestion?
@harjeethans Is possible setup it enabling the console?
Thanks in advance
@ExeLeeVanCleef would you be able to clone https://github.com/nutanix/ReDoc and then checkout nutanix-master , this branch is quite close to ReDoc/master is I pull from master last week. After you build you can try out console by enabling it thru option flag enableConsole set to true. Ping me if you run into any issues. Would be nice as we'll have some testing also done.
@harjeethans could you publish a standalone version like the one at
https://cdn.jsdelivr.net/npm/redoc@next/bundles/redoc.standalone.js
@fantastory will by EOD today.
@fantastory @ExeLeeVanCleef I just tried an adhoc release for this feature that can be access from
https://cdn.jsdelivr.net/gh/harjeethans/NuReDoc@2.0.0-alpha.29/bundles/97bac402f768ee91f5c3.worker.js.map
https://cdn.jsdelivr.net/gh/harjeethans/NuReDoc@2.0.0-alpha.29/bundles/redoc.lib.js
https://cdn.jsdelivr.net/gh/harjeethans/NuReDoc@2.0.0-alpha.29/bundles/redoc.lib.js.map
https://cdn.jsdelivr.net/gh/harjeethans/NuReDoc@2.0.0-alpha.29/bundles/redoc.standalone.js
https://cdn.jsdelivr.net/gh/harjeethans/NuReDoc@2.0.0-alpha.29/bundles/redoc.standalone.js.map
Also take note there are few for options that you can pass namely
// if you do not want to have console feature
enableConsole?: boolean;
// any additional headers that you want to add to api request calls. We have some custom we add.
additionalHeaders?: object;
// String that shows up on let side navigation defaults to Documentation Powered by ReDoc
providedByName?: string;
// String that shows up on let side navigation defaults to https://github.com/Rebilly/ReDoc
providedByUri?: string;
// For a url like /pet/{petId} it would be { also defaults to { , value for petId will be picked from path parameters values that are provided thru textbox
queryParamPrefix?: string;
// For a url like /pet/{petId} it would be } also defaults to }
queryParamSuffix?: string;I need to get all this reviewed asap meanwhile this can be tried out. @ExeLeeVanCleef the contenttype you can select by selecting the one you want from dropdown. I have tried this with json only, will try to setup something with xml support, the editor also just supports json for now, that seems to work for us at Nutanix as json is ll we support, but may not work for others. These issues are delaying me from filing a PR for now.
@harjeethans is somehow can not add show/hide-console button
I tried your
https://cdn.jsdelivr.net/gh/harjeethans/NuReDoc@2.0.0-alpha.29/bundles/redoc.standalone.js
The same when using bundle from bc59d13
I add option as:
I can not check it in sources because
npm start run:demo
shows me an error of
ReDoc/node_modules/typescript/lib/typescript.js:107655
var entry = hostCache.getEntryByPath(path);
@fantastory I just set up a sample project to test, try cloning https://github.com/harjeethans/test-redoc followed by nm install and npm start , the ReDocs seem to show up with console option. This test app uses redoc from https://cdn.jsdelivr.net/gh/harjeethans/NuReDoc@2.0.0-alpha.29/bundles/redoc.standalone.js
Great thanks for your contrib @harjeethans. It works for me and I am currently rephrasing it for my project.
as it goes for
"Cannot read property 'getEntryByPath' of undefined"
I get the same error on https://github.com/Rebilly/ReDoc/tree/master branch
@harjeethans Do you plan to make your ReDoc branch public? Seems you've only distributed the bundled version.
I ended up giving it a go myself, and its quite achievable. Although there is still a lot of edge cases for me to find and handle...
This is the design I went with:
If Samples are available I use a <select> to let the user pick between viewing samples or the sandbox.
Is it not the console branch?
https://github.com/nutanix/ReDoc/tree/nutanix-master
Any way nutanix version does not cover query string parameters.
Its not, and it does. The example given just doesn't have any query params.
Guys, I might sound like snob here but do we really need API console feature in REDOC. I believe adding this feature will complicate the core ReDoc functionality. Also from my experience in API from last few year, it is almost impossible to create a good enough API console feature. Also even if it is created it is sparingly used. It happend to product I created. No wonder big player like apigee themselves are removing this feature and paying attention to more important topics.
https://apigee.com/about/blog/api-technology/were-sunsetting-classic-api-consoles
This is not to discourage lot of hard work that has been going on this.. but I feel we can work on more high value and high usage features.
I agree with @indolent-developer that the console is not an essential part of doc tool.
Since switching to ReDoc from Swagger UI, we've been using Postman collections to give our consumers a headstart on using our APIs. In addition to helping these users get up and running faster than the built-in API console, we've been able to reuse those collections for automated testing as part of our CI/CD pipeline to protect against regressions in our API implantations.
I'm not saying our solution is the one for everyone, but I do wonder if better Postman integration (it might not take much work since you can create a basic collection from the OpenAPI spec that you can download from ReDoc) would solve most people's needs.
Partially that is the reason I was not motivated to do a PR with console so far. To make it useful we need to have more then just console being able to execute some api calls. Here are few things that were useful in past for console like feature I worked on
- pre populate the request with required only or all the request object.
- have ability to validate the request we are trying to send against the schema and report errors for missing or invalid input.
- be able to have a way to add multiple api requests in a series/parallel scenarios for some playbook like functionality. Import/Export the same.
- better editor for building request (lots of editors available)
- better way to show response like full page view just for response.
- generate some code like curl/python etc.
Again list can keep evolving!
The console that I tried to add, I had made it optional thru configuration, if you do not want we can cut it out. I can do a PR if we need.
In my experience postman collections have worked pretty good. I have even integrated postman collection download with documentation.
The collection are rich and already usable test parameters for various environment. Also there is possibility to embedded test client credentials in them. So in terms of API try outs postman just is more easy and flexible for my use-case.
Why would I create postman collections when I put so much of effort in creating and maintaining example values in my API Spec ?
Or are you suggesting to import API specs to postman every time it changes? I am not sure if postman even allows you to import OpenApI v3 specs
postman collections and params may be more suitable for testing, but a quick and dirty try-out within the doc can be beneficial to some.
I would like to go with @harjeethans opinion, presence of optional(configurable) console wont do a lot of harm and will play on par with Swagger's official UI
from @harjeethans it seems clear this feature is a much bigger enterprise than it looks at quick glance, have we considered building this as a separate project, eg. as a React component that depends only on swagger spec? (and not ReDoc dependant) if a swagger-based sandbox component existed that could be embedded by ReDoc (or any other swagger UI).
Hi all, Adam here (the ReDoc project founder). We have built an API Console "try it out" feature, but have decided it should not be a part of ReDoc core. We'll write more about this within the next two months. We are expecting to open up the beta somewhat in about a month.
I feel bad about not writing something here to let you know of our direction. And even though this message is incomplete, I wanted to post something sooner rather than later, as this thread continues to be active.
Thank you all for supporting ReDoc.
Too bad, I was looking forward to using ReDoc.
@adamaltman,
Is this API Console feature you are alluding to the one demonstrated as "Try It" in the Rebilly "Real-life usages" example linked to in the README for this repo?
If not in core, will it be an add-on or plug-in and work like the in the example above or will it be free standing?
I really wanted interactive API docs like Unity Cloud Build and Contentful, but the Apigee link @indolent-developer shared convinced me that it might not be the best way to go after all.
Instead of Postman, it is also fairly simple to open requests in Restlet Client instead, see this Restlet doc.
The decision not to include an API console in ReDoc could possibly mean it will only be available with a paid https://redoc.ly account?
have decided it should not be a part of ReDoc core. We'll write more about this within the next two months. We are expecting to open up the beta somewhat in about a month.
Cool, we really need it. Have you created another repository?
Thanks.
Too bad, I was looking forward to using ReDoc.
You can still use ReDoc. It works great, and powers thousands of companies API reference docs.
If not in core, will it be an add-on or plug-in and work like the in the example above or will it be free standing?
@worthlutz it is part of a software (that we called ReDoc Pro) that uses ReDoc in its core. It's trying to solve some different problems than ReDoc was initially. For example, speeding up the load time of API documentation:
See here: https://www.zuora.com/developer/api-reference/ (this takes about 5 seconds on my laptop, and used to take about 45 seconds -- and they don't use the "try it out" feature).
- speed (mentioned above)
- Handling multiple specs/api definitions (we find this common in large enterprises who have adopted microservices, where each dev team may be responsible for its own spec, but they roll up into part of a more cohesive API)
- Handling authentication
- Handling more complex search scenarios.
The decision not to include an API console in ReDoc could possibly mean it will only be available with a paid https://redoc.ly account?
We don't know exactly. We believe it will still be free for certain types of usages. May be similar to how you have a free plan on Headjack.
@raderio
Yes, we have created another repository -- it is a private repository for now.
We think there is a really big and missing gap in the market of developer documentation. ReDoc was focused on the API Reference docs exclusively. And these days tutorial docs (or use cases) are largely free-form. We subscribe to a "docs like code" philosophy, where all the developer docs should be treated as code (kept in a source control repository such as Github). This opens up an opportunity to leverage the spec and reference docs within tutorial docs. While this is not very useful for APIs with very few endpoints that serve few use cases, it becomes more important for larger APIs that can serve a variety of use cases. We've already committed a year of R&D to the idea, and we can't pursue it to its full potential without commercializing.
Thank you all for your feedback. We really appreciate it, as it helps us shape our views for the future.
@harjeethans Trying to set up the demo you provided https://github.com/harjeethans/test-redoc seems like https://github.com/nutanix/ReDoc/tree/nutanix-master doesn't support query parameter input? If yes, could you point out if there is any configuration I need to set to enable this feature? If not, could you provide some thoughts on how to add this? Thanks!
Yes, we have created another repository -- it is a private repository for now.
@adamaltman do you have an ETA when you'll mke it public for testing?
If you are looking for API console feature, then go for
RapiDoc - a custom element for OpenAPI spec viewing, with plenty of customization options
Can someone give an update on when it will be possible to test ReDoc API console? It is highly needed function.
Can't understand why are you referring to these comments? I've read them but they aren't giving answer if API console is publicly available, no matter in which form, whether it's a part of ReDoc project (as it's still on their roadmap - https://github.com/Rebilly/ReDoc/#roadmap) or as a standalone project or as part of some commercial project. I want to see it in action on some demo project in web or see it's source code if it is published somewhere on github. I didn't find any signs of "API console" on https://www.zuora.com/developer/api-reference/. @adamaltman can you please give an update where API console can be seen in usage on some live example or give answer when and how it will be available for developers.
@paperplanemove
the comments are pretty clear that the console wont be a part of the core-product.
They do have a console as a paid plan. If you are interested get in touch with them here
or if you want to play around a bit with the console before, check Rebilly API
Comment is not an official statement, they still have api console feature on redoc roadmap, so it's not 100% clear that it won't be implemented in no shape or form . Thank you, I tried api console at Rebilly web page and tried contacting redocly team via "Request your invitation" form at https://redoc.ly but didn't get a response letter.
I tried api console at Rebilly web page and tried contacting redocly team via "Request your invitation" form at https://redoc.ly but didn't get a response letter.
@paperplanemove
Hang on tight, they must be getting a lot of such request, meanwhile try out what Google chrome/polymer team is excited and recommending on twitter
I emailed you @paperplanemove ...
Added to Todo list:
- update roadmap
- make it clear how to get/try the API console
@adamaltman could you please email me as well? I tried "Request invitation" a couple of times but didn't get any invite.
@mona24 I don't know your email address.