Its probably easiest to think of this route as a view onto a users [reputation graph][1].

+/- a user's questions/answers is returned, but the `on_date` is intentionally ambiguous.  `on_date` ends up being the *last* voting event that occurred in a collapsed group.  All votes on a post in a given period our collapsed based on `post_id`.  No indication is given as to when any vote but the last one was made, nor whether it was an up or down vote.

`user_id` is returned because the route is vectorized, in that use-case you need to be able to map a returned value back to a user.

The key on the results (once de-vectorized, for lack of a better word) is the `post_id`.  Though for caching purposes, you probably want to key on the [`post_id`, `on_date`]-tuple, with a caveat.

That caveat is that since the underlying votes are collapsed into [`on_date`, `post_id`]-tuples based on the queried window, you have to be aware of that window when updating your cache.

----

Be aware that depending on how you're using this data, conceptually, there's no guarantee that `post_id` is unique in the stream.

  [1]: https://stackoverflow.com/users/22656?tab=reputationhistory#tab-top