GET /subscription_seat/user_subscriptions
get_subscription_seat_user_subscriptions
Returns a bare hash of user id to subscription string with no data and no links, holding only some HumanUser rows, and a null value means the user has no subscription rather than no such user.
API
Which subscription each user holds. One call, no parameters, the whole site.
Params
| part | value |
|---|---|
| (none) | /spec.json declares "parameters": []. There is no filter, no page and no user selector |
Sample requests
r = c.get("/subscription_seat/user_subscriptions")
On the probed site, 237 bytes for 14 keys. Ids replaced with placeholders:
{
"<id1>": null,
"<id2>": "not_for_resale",
"<id3>": "not_for_resale",
"<id4>": null
}
The response is the hash. There is no data key wrapping it and no links.
| part | shape |
|---|---|
| key | the HumanUser id as a string, never an integer |
| value | the subscription name, or null |
Response codes
| status | when |
|---|---|
| 200 | always |
| 401 | Request rejected due to invalid credentials. |
Edge cases
- The hash holds a subset of HumanUser rows and the endpoint gives no rule for which. On the probed
site it held 14 of 24 HumanUser rows, and
sg_status_listdid not predict membership: 5 of 6actusers were present and 9 of 18disusers were too. Treat a missing key as unknown, not as "no subscription". nullis a value in the hash, not an absence. A user present withnulland a user absent are two different states and only the first one is stated.- Keys are strings. Comparing them against an integer id from
/entity/human_usersmatches nothing. - On the probed site the only non-
nullvalue wasnot_for_resale. The vocabulary of subscription names is site data; read it off the hash rather than hardcoding a list. - The size of this hash is not
assignedfromGET /license_info. On the probed site they were 14 and 4.