Musings (and frustrations) from a Rachio API user

I have a vacation property located in a microclimate area that frequently trips up Rachio’s Weather Intelligence feature. I see frequent schedule skips based on predicted and observed rainfall in my surrounding area but while it might be (or have been) raining nearby, the rain frequently misses my immediate area. If this happens sporadically, the effects are negligible. But last summer it happened often enough that when I returned after being away for 6 weeks my lawn was baked to a crisp. Shortly thereafter I purchased a WeatherFlow Tempest weather station and used the Rachio integration to connect the two. While this has mostly fixed the “observed” rainfall part of the problem, the “predicted” rainfall issue is a harder one to solve.

So after that long winded problem statement here’s what I’m trying to do and the hurdles I’ve run into:

I created a Windows service that runs on an always on Window 10 PC. The service uses the WeatherFlow Tempest API to open websocket that listens for observation data from the Tempest. Messages are received every minute and shortly after midnight each day, I receive the previous day’s final adjusted rainfall values for my unit which I save to a database. My Rachio schedule runs on Tuesday, Thursday, and Saturday. My intention/hope is to calculate the total rainfall inches and estimated irrigation inches for the week on Saturday afternoon of each week. And if the total is under a certain threshold of say 1.5-2.0 inches for the week, use the Rachio API to initiate another schedule run.

I’m using the Rachio API to poll for events every minute and I’m saving the event data to a database. The problem is that event data returned by the API when polling is missing lots of information compared to what’s received by a webhook. For example: A “SCHEDULE_STATUS” event type with a subtype of SCHEDULE_COMPLETED includes a “durationInMinutes” property in the webhook event data but not in the event data returned when calling the endpoint. This makes it very difficult to get the actual schedule run time particularly if the scheduled stopped part way through or (worse) was manually paused.

So I tried using zone status events to calculate zone run time. But using the event “ZONE_STATUS” type and “ZONE_STARTED” and “ZONE_COMPLETED” subtypes present similar issues; the data received by the webhook includes “zoneNumber”, “zoneId”, “zoneName”, “durationInMinutes”, and “executionType” which are all invaluable but surprisingly missing in the data returned when using the API. So the end result is that I have to parse the “summary” property to determine which zone the event belongs and then calculate the elapsed time between the “ZONE_COMPLETED” and “ZONE_STARTED” event times to determine run time for each zone.

This should be a fairly trivial programming exercise but the poor API documentation and differences in the data provided using the webhook compared to the API have made it an extremely frustrating exercise. Are there any plans to align the scant data returned by the API with that received by a webhook?

Next, I tried to explore the webhook receiver route. I created an AWS account and have a lambda function receiving webhook event data from Rachio. But getting that data to my Windows service has proved daunting. I considered running my own webserver to handle receiving the webhook data but is seems like such a useless expense and hassle (not to mention potential security implications) when the API really should be sufficient for my needs.

To put some context on this I have over 20 years of application development experience and this has been a painfully convoluted, frustrating, and time consuming task.

I love my Rachio but the API and documentation seem like such a half-hearted effort that it takes away from an otherwise brilliant user experience. Please consider fixing this.

Thanks – Steve

Are you aware that there is a second, more powerful Rachio API that is not publicly documented? If not, let me know and I’ll go find my notes on it.

Not sure it will solve your problem, but if you e not seem it you definitely need to take a look at it.

No, I was unaware there is another API and would be grateful for any info you can pass my way.

Thanks – Steve

Hi Steve,

Happy to pass along what tidbits of info I can. First a bit of background. I’m a retired software architect/developer and still do a good bit of coding just for fun, on numerous platforms. .Net Core, Arduinoo (C++), and Swift.

For a number of years I’ve enjoyed developing and using an Arduino based plant watering system. it has grown more complex over the years, and a year or two ago I started using my Rachio based irrigation system as the source of the water used by my Arduino plant watering system. This led me down the path of using the Rachio API to control a dedicated zone from which I get my water for the plants.

The Arduino stuff is in C++, but the backend support for it is all C#. So I’ll pass along some of the C# resources also, in case they help. Even if that is not your language, you may find some useful “how to’s” by scanning the source on GitHub.

I discovered a 5-6 year old C#/.Net based GitHub project at GitHub - jaymclain/Rachio.NET: .NET access to the Rachio API. When I used it a couple of years ago it appeared abandoned, but I checked this morning, and it does seem to have been updated some in the last year. So you can check that out as it was a pretty nice base to start from.

Now as for the “private” API; seems the documented API is hosted at, but there is a more powerful API that is hosted at It is what is used by most of the Rachio online web pages that you are interacting with when you log in to Rachio.

But since it is undocumented, you’ll have to do a bit of poking around. Here are my notes on how to do that:

  1. Using Google Chrome, log in to using your standard Rachio userid/password.
  2. Hit F12 in Chrome to open the developer tools window.
  3. Click on “Network” on the top menu of the developer tools window.
  4. Click on “Fetch/XHR” in the developer tools window.

Now, use the Rachio web page to do different things. Each time you interact with the web site, the background REST API calls are listed in the Fetch/XHR window on the right. You can study any message of interest and see the format that is required to use that API call, and the JSON responses from each API call.

Note that many if not most of the API calls that their webpage is doing is using the URL for the API.

Looking at my plant watering system use, I see that I used this alternate URL in 3 different API calls:

  • getDeviceState
  • setManualSchedule
  • stopWatering

I had made note of the following other API calls, which I will include. But unfortunately, I failed to note which of these (a) do not exist in the public API, and (b) those that may be similar but different from the public API version. But with the Google Chrome approach you can easily zoom in for a close look at whatever functionality you want to do via the API.

API calls to investigate:

I’m not currently using the API anymore for my Arduino stuff, but I did check just now and the instructions I gave for using Chrome to see the workings of the API does still work.

Hope this helps.



Hi Brad,

Thanks for the info—very helpful. Small world; I’m also a retired software architect/developer. I started with C++ in the late nineties and moved to C# during the 1.0 release in 2002. Like you, I still code for fun but also keep busy with contract software development work for my former employer. It never occurred to me that the Rachio web app might use a different API so I never looked further than what’s exposed via the public API docs. I’m very familiar with using Chrome/Firefox developer tools so this should get me going.

I’ll post an update once I’ve had a good poke around.

Thanks again – Steve

5years later… What I was looking for was the forecast / future schedule. I was able to retrieve that using the events/upcoming method. This is a ‘post’ method with a json body “{“device_id”: “40425af5-a1d4-43eb-9fa0-f097cec91cf3”, “hours_ahead”: 360}”.
Pretty nice.