**Rationale:** For some use-cases it is important to know the 'own' account id / account information. **Possible solutions:** **a)** Add a filter to `accounts_list` operation: `/accounts?self=true` **Cons:** - The behavior of unknown filters is currently undefined in the API and could lead to unexpected results, if the implementation does not support the filter. - Not discoverable if the implementation of the API supports the operation. **b)** Use a 'special' user id `self` with `accounts_retrieve` operation: `/accounts/self` **Cons:** - Not discoverable if the implementation of the API supports the operation. **c)** Add a new operation `identity_retrieve`: `/identity` The response could return an object derived from authentication information: ```json { "consuming_account": "<ID>", "managing_account": "<ID>", "billing_account": "<ID>", "expires_at": "<datetime>", } ``` As the **use-cases** have shown, for almost every create operation the fields `consuming_account`, `managing_account` and `billing_account` are required. Providing the information using a single query could be helpful. For convenience the billing account could also be included explicitly in the response object. In most cases this would be the same as the `managing_account`. I'm not too invested in including this. **Whose account is this anyway?** Referring to the "own" account depends on the implementation of the API, especially when it comes to authentication. For the `legacy` authentication method the `consuming_account` and `managing_account` will be the same and will point to the reseller. We only identify the reseller using the API Key and Secret. As an alternative the consuming account could be set to `null`. Using `oauth` *allows* for issuing an API access token specific to a "subcustomer", using the `auth_code` workflow. In this case the `consuming_account` and `managing_account` could correctly reflect the relationship between the reseller and subcustomer.