Identity reflection

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:

{
   "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.