We probably want to use assert_params_in_dict for dehydration_token since it is required -- this will raise a sane error message. (This is true for any parameters that are required in the added endpoints.)

Not sure if this is supposed to show up only in unstable or also r0 (the current code would do both).

The documentation about what this callback might be (see the check_auth info in there) is less than ideal. It comes from password auth modules and might be None or a Callable that is "called with the result from the /login call (including access_token, device_id, etc.)"

I do not know of any auth providers which use this frankly, but I think calling it like below is the reasonable thing to do. Is there a particular reason you think it should not be called?

We talked a bit more about this and the reason we can't just call it here is that we don't yet have the access token (the client hasn't acknowledged that they've been able to use the dehydrated device).

It seems like we would ideally want to call this at the end of the call to /restore_device, but we no longer have the callback at that point. Will need to think about what the best option is here.