Showing results for tags 'api'.

Use this to verify you are making the proper connection to an Invision Community API endpoint. If you need to get an API connection up to speed, this is your tool. It only uses GET calls, no POSTS. And there is no OAuth testing either or anything beyond what the label says: API testing of GETs. Once you have a simple GET call sorted, the rest is on you and should be simple enough now that you have the basics out of the way You can use this to query the APIs live on your own localhost machine. You can call from localhost to a live site. You can call from livesite to livesite. This is a devtool but it it is perfectly safe, and firewalled, for use on livesites where you might need to track down some connection problems. You can have as many copies of this widget on a page as you like! Test separate individual API calls with each one! ICAPIT is also fantastic for testing your own API rollouts in your applications if you have never made those yourself before. Set up your application API code, give yourself a key and the proper permissions to it, and just call it from the plugin and see what you get! Not only that but you can look at the response modal to see how the exact call was made at the code level. Nothing fancy here; copy-paste as you need - it's all basic PHP code. Great for when you are needing to READ from the Invision Community API. Every step of the way, you should either receive the correct JSON response, or a myriad of error responses which will aid you in tracking down your problems. One tab is dedicated to all the possible error responses the Invision Community API puts out internally - no need to go looking for what they mean, they are all right here. FYI this code is an INTERNAL tool for myself so if you poke under the hood you'll see a LOT of copypasta so leave me alone and you're not my supervisor. It gets the job done quite well. User MUST be in the administrators group to view this plugin. Do not install it, drag it onto a page with someone who has widget permissions but is not an administrator and expect to see the widget/s. Same if you are not logged in as an administrator. For each instance of the widget: Edit the widget's block configuration to enter your API key. API keys displayed in the widget or results modal will only show the first four characters for safety if you are using this in a public setting and someone glances over your shoulder and so on. Click the Configure API Call button on the widget to configure the actual API call. This is where you will enter the site URL, the API call, and set various options. Click the Make Call button to make the call. A results modal will display on the screen showing you the results of the call. To make subsequent calls with that particular widget you must either change the Configure API Call settings and save or refresh the page. If you are encountering problems or spurious returns, make sure to use the direct cURL option in the widget settings (as opposed to the IPS wrappers). This will provide you with the cURL error output which can be invaluable as not all the error responses will be the clean, sanitized, canned IPS API json responses. As an example, your local dev machine will probably have a self-signed SSL certificate. There is a setting that allows you to disable SSL checks when making an API call, and you will need to have this enabled when you are using this to read APIs on your own localhost. Don't believe me? What happens if you turn that off and do make those SSL checks on your local machine with the self-signed cert? Well that "0" is not too helpful for a response. However, I made that call with direct cURL so let's look at that last tab... There you go. I can see many avenues for improvement and expansion with this tool but 5x is inbound so I'm content to let this sleeping dog lie and see what's what in a few months. If you find it useful, I'm glad you did </rattles tip-jar>. Any hitches, questions, and the like, hit the forums. By the way, I do have a companion to this, a plugin that you install on the server where you are reading the API from, that lets you dump $_SERVER output to the system log when the authorizationHeaders() function is hit, which is only hit when API and OAUTH calls are made to the server. You can set how many minutes it will log these for which gives you enough time to turn this logging on, and then hit the API with ICAPIT (or any other way you like) once or however many times you like, and catch those $_SERVER outputs for debugging. I used this to spot missing or malformed headers, bad encodings of credentials, etc. You are probably in the weeds if you need this (or the server you are doing work on is...) so just give a yell and I can add that tool to the freebie pile (after I dredge it up from the 4.5 dev installation lying dormant somewhere around here...) Lastly... This plugin does require you to have your server more or less configured correctly. If you half-assed setting up friendly urls in .htaccess or nginx confs, or have made a mess of other things, don't expect this plugin to magically tell you what is wrong.