APIv2 is Ready to Use … (APIv1 will be retired on 1 June 2017)

Uptime Robot’s API is consumed pretty much (with over 5,000,000+ requests/day) for “automating monitor management”, pulling the data to generate custom reports and more.

As the usage grows every day, the APIv2 is built for a faster, more secure and stable experience with added features.

SSL and POST only

The APIv2 expects all parameters to be sent as a POST request and works SSL-only where both changes together help making it more secure.

Updated parameter names and speed

The parameter names and responses are very consistent now. They are all lower-case, separated with “_” (like api_key).

And, most methods are now ~ 2x to 5x faster.

Added features

It is now possible to pull more data with getMonitors method, including:

  • getting the uptime % of a range (or multiple ranges) with custom_uptime_ranges parameter
  • getting the all time duration of statuses with  all_time_uptime_durations parameter
  • getting the logs of a given period with logs_start_date and logs_end_date parameters
  • getting maintenance windows of a monitor

And, maintenance windows can also now be managed with the API too.

Code samples

The updated documentation page now has code samples for each monitor in multiple scripting and programming languages including PHP, Python, Nodejs, Go, Ruby, C# and Java.

When will APIv1 be retired?

APIv2 is the version that will be improved from now on and APIv1 is planned to be retired by 1 June 2017. So, please make sure that you switch to the new API before then.

Suggestions and bug reports

We are already using APIv2 in production, so, it is pretty stable. Yet, there is always a change of bugs and please let us know if you experience one.

Also, look forward to any suggestions and feature requests to make it better.

If you find Uptime Robot useful, help us spreading the word:

Comments

  1. David

    I don’t see any way to pause monitoring in the v2 editMonitor API, am I missing something?

    Also why 4 required fields? The api_key and id of the monitor seem like they should be all that is necessary…

    Reply
    1. Umut Muhaddisoglu Post author

      Thanks very much for pointing them out.

      Just updated the docs accordingly.

      Reply
  2. Phil

    Is there a migration guide? or do I really need to trawl both apis to compare the differences?

    Reply
    1. Umut Muhaddisoglu Post author

      Once the APIv2 is out of beta, a migration guide will be shared to ease the transition.

      Reply
  3. waldo

    I get Error 404, why?

    Reply
  4. waldo

    I can get “Response Time” chart from my monitor or the values to generate one.

    Reply
  5. Martin

    Having a nightmare trying to update to API v2 using Curl via PHP…

    Curl appears to be connecting but no data is being returned by Curl. Just a 200 status code to confirm connection and then nothing…

    Using full API key, format=xml and logs=1… Tried all manner of different approaches but to no avail…

    Any suggestions?

    Reply
    1. Martin

      Found my problem… The API update wasn’t the issue… for me it was the simple change in the API keys…

      friendlyname has been changed to friendly_name and this is NOT documented as part of the update…

      Lessons learned:
      1. XML doesn’t output properly in an HTML error log
      2. Sanity check the variables you’re expecting so you don’t waste 8 hours like this…

      Hope the above discovery helps someone else avoid this facePalm moment…

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>