Pingdom 2.1 and 3.1 apis don't work as documented

Hello bitsofinfo . Thank you so much for the feedback. This is obviously quite embarrassing and somehow slipped through our QA. I deeply apologize for the issues. Thank you for catching and reporting them. Our developers are currently working on a fix:

We’re fixing the documentation now. In short, our quick recommendation is to use urlencoded parameters instead of JSON (as described in examples in the old documentation: https://www.pingdom.com/api/2.1/). Soon the new docs (docs.pingdom.com/api) will also have urlencoded parameters in the examples.

Once we fix and complete the handling of JSON we’ll describe that in the docs to reflect that as well.

Please let me know if you have any further questions. Thank you again for calling this out to us.

- Matt Pitcher, PM, Pingdom

Just was about to go to tweet you guys as I was concerned nobody was paying attention. Thanks for the reply

Glad to hear I wasn't going nuts and that its being remedied, I contacted support and they were trial/erring through the process as well.

It appears completely non-functional.

FYI the swagger docs even for 2.1 (as of a day ago) described JSON that also didn't work.

In any case, please post an update here when 3.1 is ready. Looking to build something new, and don't want to build against an old API.

thanks

Will do. Again, I appreciate your feedback and patience. If you ever have any issues, as a member of our Thwack community, you're welcome to reach out to me directly anytime. Although our technical support folks are indeed awesome.

bitsofinfo​, we've now updated our documentation. Please take a look and let me how it works for you. Pingdom API

Unfortunately its still confusing and not clear how you specify the documented props especially now that its reverted to url encoded format

Thanks bitsofinfo​, I agree and I'm having our devs fix this with JSON support in our 3.1 docs. I'll be back in touch here once released.

Any ETA on this?

Note that the documentation for 3.1 as it currently stands, w/ the url-encoded format POST/PUT for managing "checks" appears to work so I'm likely just going to code to this published documented spec. I assume that if you change it back to the originally published JSON contract, you would then release it under a different version (i.e. like 3.2) as to not break the currently published contract of 3.1 that uses the url encoded format.

Hello bitsofinfo​ we've started the work and plan to have it done, tested and documented middle of next week. We also plan to not release it as 3.2 but add it to 3.1 as it is not a breaking change nor require any change from your side to be compatible, it is just an extension. I will post again here when it's been released.

Here are some additional issues

1. When creating/updating a check there is no way to specify the "check importance" of "low" or "high". (actually you can but its NOT documented, pass severity_level = LOW|HIGH)

2. Creating/updating checks takes comma delimited lists of userids, integrationids, teamids etc... yet the API itself provides no way to get a list of the actual userids or integrationids or teamids.... you have to go fumble around in the pingdom UI to try to inspect html elements via a browser debugger to find them! Super cumbersome. There should be endpoints like GET /users, /integrations, /teams etc....

3. There is no way to specify the "custom" alert message in the API (actually you can via custom_message) but its NOT documented

4. You can POST multiple new "checks" the same exact "name".... shouldn't that be unique? (on second thought, its best to leave functionality as-is IMHO, continue to permit duplicated names, w/ immutable check management and using tags this can be negated)

5. The "probe_filters" for example accepts multiple like "region:NA,region:LATAM", yet when you look at the created check in the website UI, only ONE of those regions is selected.

Yet if i GET the check via the API it reports back both regions

Whats really going on in the backend? are both my regions really being checked despite the UI only showing one?

NOTE looking at the test logs it IS checking from all the regions you specify in the API. the GUI is just wrong. Please fix the GUI to show checkboxes instead of radio buttons for the regions the check is configured for. Very confusing.

also FYI, I've already coded quite a against whats documented on your 3.1 docs. Please don't break it The issues above still should be addressed IMHO