This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Pingdom 2.1 and 3.1 apis don't work as documented

Using my trial account I am trying to eval the API to create a new "check" with the pingdom API 3.1 (or 2.1)

Here is the published documentation with the sample code I am following: Pingdom API (https://docs.pingdom.com/api/#tag/Resource:-Checks/paths/~1checks/post)

HERE IS MY POST: (response follows below)

------------------

curl -X POST \

  https://api.pingdom.com/api/3.1/checks \

  -H 'Accept: */*' \

  -H 'Accept-Encoding: gzip, deflate' \

  -H 'Authorization: Bearer REMOVED' \

  -H 'Cache-Control: no-cache' \

  -H 'Connection: keep-alive' \

  -H 'Content-Length: 459' \

  -H 'Content-Type: application/json' \

  -H 'Cookie: __cfduid=d9176e894c9e7447aaa6fe93b74da28e51569381518' \

  -H 'Host: api.pingdom.com' \

  -H 'Postman-Token: 31f0c5af-86db-4c7a-a9ed-56db4ddddad0,1194f682-4c16-4ba3-92d4-c761bb2919ae' \

  -H 'User-Agent: PostmanRuntime/7.16.3' \

  -H 'cache-control: no-cache' \

  -d '{

  "http": {

    "url": "https://pingdom.com",

    "encryption": true,

    "port": 443

  },

  "name": "mycheck1",

  "host": "pingdom.com",

  "type": "http",

  "paused": false,

  "resolution": 5,

  "sendnotificationwhendown": 2,

  "notifyagainevery": 0,

  "notifywhenbackup": true,

  "tags": [

    {

      "name": "pingdom",

      "type": "whatever",

      "count": 2

    }

  ],

  "probe_filters": [

    "region:LATAM"

  ],

  "responsetime_threshold": 30000

}'

HERE IS PINGDOM'S RESPONSE

----------------------------------------

{

   "error": {

   "statuscode": 400,

   "statusdesc": "Bad Request",

   "errormessage": "Invalid parameter: 'http'"

  }

}

Huh? I've even tried removing the 'http' object from the request above.... when I do that then I get back

{

   "error": {

   "statuscode": 400,

   "statusdesc": "Bad Request",

   "errormessage": "Invalid parameter value: paused"

  }

}

Huh? I've even tried removing the 'paused' property from the request above.... when I do that then I get back

{

   "error": {

   "statuscode": 400,

   "statusdesc": "Bad Request",

   "errormessage": "Invalid parameter value: notifywhenbackup"

  }

}

Huh? I've even tried removing the 'notifywhenbackup' property from the request above.... when I do that then I get back

{

   "error": {

   "statuscode": 400,

   "statusdesc": "Bad Request",

   "errormessage": "Invalid parameter tags value Array"

  }

}

Huh? I've even tried removing the 'tags' property from the request above.... when I do that then I get back

{

   "error": {

   "statuscode": 400,

   "statusdesc": "Bad Request",

   "errormessage": "Invalid parameter: filters"

  }

}

Huh? There is NO 'filters" property! Ok next best guess, I've even tried removing the 'probe_filters' property from the request above.... when I do that then I get back

{

   "check": {

   "id": 5454775,

   "name": "mycheck1"

  }

}

So.... what is going on here? the final request I posted looks like this.... a far cry from what the documentation states... Pingdom API

{

  "name": "mycheck1",

  "host": "pingdom.com",

  "type": "http",

  "resolution": 5,

  "sendnotificationwhendown": 2,

  "notifyagainevery": 0,

  "responsetime_threshold": 30000

}

Parents
  • 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

    Pingdom API 2019-09-27 11-59-33.png

  • 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.

Reply
  • 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.

Children
  • 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

       "probe_filters": [

       "region: EU",

       "region: LATAM"

      ]

    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 emoticons_happy.png The issues above still should be addressed IMHO

  • The changes we are working on are not breaking which is why we can add it to our Public API version 3.1. Adding proper JSON support should not affect any existing integrations that our customers have, and since you are using URL-encoded parameters, you should be fine with the changes made. Once there's JSON support a user can choose to use that instead if they want to.

    Fetching teams and contacts is being worked on as well. It's in the team's sprint, we're enabling support for fetching teams and contacts via the Public API (and will be added to 3.1).

  • Great, and what about the GUI issue w/ the radio buttons vs checkboxes. The GUI does not properly reflect the actual regions bound via the API, and if you hit modify you change it to a single region which is not the intent.

  • Hey there bitsofinfo​, I just wanted to let you know that we have officially added JSON support as the request body schema in our Public API 3.1 and updated the documentation: https://docs.pingdom.com/api/.

    There's a description that is shown for the endpoints also -  the user can click the dropdown to see the 2 different ways of passing in the request body.

    Public API JSON.png

    Public API query string.png

    As for the API reflecting what's in the GUI, there isn't a 1:1 mapping and we are working through some of those issues.