Do I understand it correctly that there is no way to get through API something like the table available under the “stats” tab, i.e. how much is due (or what total is due) by a certain date?
Not that it is too complicated to calculate this from “roadall” matrix, just wanted to make sure I will not be reinventing wheel.
I think you mean the ‘due by table’ and yes this is available in the API. That is, the API provides it but it is not yet documented at api.beeminder.com.
Yes, exactly! How can I know the name of the attribute then? It’s not in the documentation, indeed, which is where I started before posting this thread 
Here are some older iOS app tickets discussing it.
github com /beeminder/BeeSwift/issues/36#issuecomment-627741771
(in the API but not documented)
github com /beeminder/BeeSwift/issues/209#issuecomment-756426791
(Some examples of what the data in the API looks like)
Wonderful, thanks!
Just to be clear, you are looking for the amount that will be due for a future date, rather than how much was due (say) yesterday? Beeminder “knows” some of the future requirements for any goal that’s got a graph , and I don’t see why we couldn’t expose it over the API.
Yes, for a future date. I am thinking of making a script that would allow introducing breaks while preserving the average rate. E.g. I want to do something 3 times a week, and I don’t care on which days I will do that, but I absolutely do not want it to be required on the day when I am, e.g. travelling, or have a full-day commitment. Currently, if I introduce a 1-day break, I will only do that thing 3*6/7 times that week. Current way around if I want to stick to the average of 3/week: do not introduce the break and just manually plan ahead to have enough buffer by the day in question. Too much manual planning when beeminder is there specifically for this work to be delegated! So I was thinking of a script that would increase the road before and after the break day slightly to compensate. Didn’t get to actual coding yet, just juggling concepts in my head, one of which is that it would be extremely helpful if I had a way to get the amount required by a certain day from the API. To see exactly how much needs to be compensated and how to spread that out. But if not - I will just calculate that from the roadall.
Just thinking this through: we can definitely raise a gissue to add this “dueby” list of [date, delta, total] triplets for the next 7 days (as per the statistics screen) to the stuff returned from the existing goal API.
The tricky bit is going to be changing the rates within that range while keeping within the akrazia horizon “rules”. Beeminder won’t let you make things easier for yourself within the akrasia horizon - iirc, it checks every day to see if it’s easier than before the change. Say it’s Monday today, and you want to introduce a break on Friday - that’s within the horizon, so even if you present back a segment with a steeper slope before Friday, so that across the week it averages out the same, I don’t think the code will pass it, because you are making things easier on Friday.
If you are looking for a 1-day break after the horizon, then the code doesn’t currently have a statistics-style view of the dueby stuff beyond the horizon.
Does this make sense? Is it what you were trying to do, or were you after something different?
My impression was that it cares about totals by each day within the akrasian horizon (not rates on individual days), and making it steeper and then flattening should pass by the akrasia horizon limitations. At least, that’s how a kind of customary “ratcheting” works for one of my goals, where I am doing this both via API and occasionally manually with the standalone road editor: add a jump today, then the rate for the rest of the week is lower - this is accepted as long as the new road is above or equals the old road.
Yes, I will probably want it to be generalizable. So, I will calculate then!
Thanks for clarifying what info is available!
Yes, I think that’s exactly right - I wasn’t being clear when I said “it checks every day to see if it’s easier than before the change”, but you are spot-on as to how it does this. It just checks if the target total number each day is easier than it was before, not if the rate itself is easier. So if you are careful with your target adjustments, by aggressively moving a do-more line up in the first few days, say, then you can add in a break during the akrasia horizon.
I have some code that calculates the amount due on any future date; I use it for some fairly similar purposes (figuring out what I should do today given what I know about my future schedule/capacity).