{ "aid": "pingdom.com:pingdom-api-3.1", "name": "Pingdom Public API", "type": "Index", "description": "# Welcome to the Pingdom API!\nThe Pingdom API is a way for you to automate your interaction with the Pingdom system. With the API, you can create your own scripts or applications with most of the functionality you can find inside the Pingdom control panel.\n\nThe Pingdom API is RESTful and HTTP-based. Basically, this means that the communication is made through normal HTTP requests.\n\n# Authentication\nAuthentication is needed in order to use the Pingdom API, and for this a Pingdom API Token is required. You generate your Pingdom API Token inside My Pingdom. The Pingdom API Token has a property called “Access level” to define its permissions. All operations that create or modify something (e.g. checks) need the Read/Write permission. If you only need to read data using the API token, we recommend to set the access level to “Read access”.\n\nThe authentication method for using tokens is HTTP Bearer Authentication (encrypted over HTTPS). This means that you will provide your token every time you make a request. No sessions are used.\n\nRequest\n```\nGET /checks HTTP/1.1\nHost: api.pingdom.com\nAuthorization: Bearer ofOhK18Ca6w4S_XmInGv0QPkqly-rbRBBoHsp_2FEH5QnIbH0VZhRPO3tlvrjMIKQ36VapX\n```\n\nResponse\n```\nHTTP/1.1 200 OK\nContent-Length: 13\nContent-Type: application/json\n{\"checks\":[]}\n```\n\n## Basic Auth\nFor compatibility reasons, the Pingdom API allows to use HTTP Basic Authentication with tokens. In cases where this is necessary, input the API token as the username and leave the password field empty.\n\nAn example request of how that would look like with the following API token: ofOhK18Ca6w4S_XmInGv0QPkqly-rbRBBoHsp_2FEH5QnIbH0VZhRPO3tlvrjMIKQ36VapX\n\n```\nGET /checks HTTP/1.1\nHost: api.pingdom.com\nAuthorization: Basic b2ZPaEsxOENhNnc0U19YbUluR3YwUVBrcWx5LXJiUkJCb0hzcF8yRkVINVFuSWJIMFZaaFJQTzN0bHZyak1JS1EzNlZhcFg6\n```\n\n# Server Address\nThe base server address is: https://api.pingdom.com\n\nPlease note that HTTPS is required. You will not be able to connect through unencrypted HTTP.\n\n# Providing Parameters\nGET requests should provide their parameters as a query string, part of the URL.\n\nPOST, PUT and DELETE requests should provide their parameters as a JSON. This should be part of the request body. Remember to add the proper content type header to the request: `Content-Type: application/json`.\n\nWe still support providing parameters as a query string for POST, PUT and DELETE requests, but we recommend using JSON going forward. If you are using query strings, they should be part of the body, URL or a combination. The encoding of the query string should be standard URL-encoding, as provided by various programming libraries.\n\nWhen using `requests` library for Python, use `json` parameter instead of `data`. Due to the inner mechanisms of requests.post() etc. some endpoints may return responses not conforming to the documentation when dealing with `data` body.\n\n# HTTP/1.1 Status Code Definitions\nThe HTTP status code returned by a successful API request is defined in the documentation for that method. Usually, this will be 200 OK.\n\nIf something goes wrong, other codes may be returned. The API uses standard HTTP/1.1 status codes defined by [RFC 2616](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html).\n\n# JSON Responses\nAll responses are sent JSON-encoded. The specific responses (successful ones) are described in the documentation section for each method.\n\nHowever, if something goes wrong, our standard JSON error message (together with an appropriate status code) follows this format:\n```\n{\n \"error\": {\n \"statuscode\": 403,\n \"statusdesc\": \"Forbidden\",\n \"errormessage\":\" Something went wrong! This string describes what happened.\"\n }\n}\n```\nSee http://en.wikipedia.org/wiki/Json for more information on JSON.\n\nPlease note that all attributes of a method response are not always present. A client application should never assume that a certain attribute is present in a response.\n\n# Limits\nThe Pingdom API has usage limits to avoid individual rampant applications degrading the overall user experience. There are two layers of limits, the first cover a shorter period of time and the second a longer period. This enables you to \"burst\" requests for shorter periods. There are two HTTP headers in every response describing your limits status.\n\nThe response headers are:\n* **Req-Limit-Short**\n* **Req-Limit-Long**\n\nAn example of the values of these headers:\n* **Req-Limit-Short: Remaining: 394 Time until reset: 3589**\n* **Req-Limit-Long: Remaining: 71994 Time until reset: 2591989**\n\nIn this case, we can see that the user has 394 requests left until the short limit is reached. In 3589 seconds, the short limit will be reset. In similar fashion, the long limit has 71994 requests left, and will be reset in 2591989 seconds.\n\nIf limits are exceeded, an HTTP 429 error code with the message \"Request limit exceeded, try again later\" is sent back.\n\n# gzip\nResponses can be gzip-encoded on demand. This is nice if your bandwidth is limited, or if big results are causing performance issues.\n\nTo enable gzip, simply add the following header to your request:\n\nAccept-Encoding: gzip\n\n# Best Practices\n## Use caching\nIf you are building a web page using the Pingdom API, we recommend that you do all API request on the server side, and if possible cache them. If you get any substantial traffic, you do not want to call the API each time you get a page hit, since this may cause you to hit the request limit faster than expected. In general, whenever you can cache data, do so.\n\n## Send your user credentials in a preemptive manner\nSome HTTP clients omit the authentication header, and make a second request with the header when they get a 401 Unauthorized response. Please make sure you send the credentials directly, to avoid unnecessary requests.\n\n## Use common sense\nShould be simple enough. For example, don't check for the status of a check every other second. The highest check resolution is one minute. Checking more often than that won't give you much of an advantage.\n\n## The Internet is unreliable\nNetworks in general are unreliable, and particularly one as large and complex as the Internet. Your application should not assume it will get an answer. There may be timeouts.\n\n# PHP Code Example\n**\"This is too much to read. I just want to get started right now! Give me a simple example!\"**\n\nHere is a short example of how you can use the API with PHP. You need the cURL extension for PHP.\n\nThe example prints the current status of all your checks. This sample obviously focuses on Pingdom API code and does not worry about any potential problems connecting to the API, but your code should.\n\nCode:\n```php\n\n```\n\nExample output:\n```\nUbuntu Packages is up\nGoogle is up\nPingdom is up\nMy server 1 is down\nMy server 2 is up\n```\n\nIf you are running PHP on Windows, you need to be sure that you have installed the CA certificates for HTTPS/SSL to work correctly. Please see the cURL manual for more information. As a quick (but unsafe) workaround, you can add the following cURL option to ignore certificate validation.\n\n`\ncurl_setopt($curl, CURLOPT_SSL_VERIFYPEER, 0);\n`\n\n# TMS Steps Vocabulary\n\nThere are two types of transaction checks:\n