[requestid] (string): Alphanumeric string to uniquely identify this datapoint. Clients can use this to verify that Beeminder received a datapoint (important for clients with spotty connectivity). Using requestids also means clients can safely resend datapoints without accidentally creating duplicates. If requestid is included and the datapoint is identical to the existing datapoint with that requestid then the datapoint will be ignored (the API will return “duplicate datapoint”). If requestid is included and the datapoint differs from the existing one with the same requestid then the datapoint will be updated. If no datapoint with the requestid exists then of course the datapoint is simply created. In other words, this is an upsert endpoint and requestid is an idempotency key. NB: Must contain only alphanumeric characters or it will be ignored.
Can you clarify “uniquely identify”
Does it mean it is unique within this goal or within this user or within beeminder?
I’m hoping it means within the goal. I want to be able to have separate goals for Strava that allow you to track number of activities (I want to run 3x a week) as well as distance (I want to run 5k a week). The datapoints for these 2 goals will have the same requestid (in one case the value is 1 indicating you have run, in the other it is the distance).
If requestid is unique for the user rather than the goal I will need to add something to the strava id to show if I am using it in a counter goal or a distance goal.
I am delighted that you’re asking these things out loud. Some of them will prompt improvements to the API and/or the documentation, others will serve as guideposts for generations of future searchers.
I’ve already learned things that have improved my own integrations, thanks to your active questioning.
This is yet another vote, incidentally, for the ability to have multiple goals based on the same underlying datapoints.
The API isn’t really set in stone, and the expected behaviour is only defined by ‘what the API does’.
This is what is described on the API documentation page.
If you have suggestions for how the documentation can be improved please post them, so we can work on updating it.
I if you find a case that you think should work differently start a thread, the most active API users are also active here on the forum and if there’s agreement it’s quite likely that a change can be made.
P.S. Thanks for all your posts, it’s good to see how other people are using the API
Just to confirm that I have checked and the requestid is unique within the goal only (which is exactly what I would have hoped).
The implications are that you can have 2 goals each updated by from the same source and not have to worry that the same requestid will appear in datapoints for both goals.
For example this is ok out of the box:
Goal 1: Cycle 7 times per week. Load each ride from Strava with a value of 1 (ie 1 ride) and with the Strava activity id in the requestid (to make sure you don’t add the same ride twice).
Goal 2: Cycle 50 miles per week. Load each ride from Strava with the value set to the length of the ride in miles and with the Strava activity id in the requestid (to make sure you don’t add the same ride twice).
NB. Saving a datapoint with the same requestid will cause a duplicate (status 422) if ALL fields are the same but otherwise a status 200 with an update to the new values if any field is different.
In my Emacs client, I have a feature where I clock in and out (i.e., track time spent on various things), and on clocking out, data is sent to Beeminder. The requestid is constructed from the start and end times. Now imagine that I accidentally clocked on the wrong task. If requestid were unique for the user and not for the goal, I could just move the clocking info to another task and resent it to Beeminder. Now I have to delete the datapoint first.
A rare scenario, I admit, but IMHO it makes sense.
