Accounts

Every API token is scoped to exactly one account, and the accounts endpoints exist to tell you which one. An integration calls them once — at connection time — to discover and persist the account id, then sends that id back as a cross-check on every subsequent request.

The account model

An account is the tenant every other object hangs off: assets, wipe results, certificates, device tokens, and API tokens all belong to one account. With a bearer token, the accounts list always contains exactly one account — the token's own. There is no way to see, or even confirm the existence of, any other account.

Properties

Name
id
Type
integer
Description
Unique identifier for the account. This is the value you persist and send back as account_id.
Name
name
Type
string
Description
The account's display name.
Name
personal
Type
boolean
Description
Whether this is a user's personal account rather than a team account.
Name
owner_id
Type
integer
Description
Identifier of the user who owns the account.
Name
created_at
Type
timestamp
Description
When the account was created.
Name
updated_at
Type
timestamp
Description
When the account was last updated.
Name
account_users
Type
array
Description
The account's memberships — each entry carries its own id and the member's user_id.

GET/api/v1/accounts

List accounts

Returns the accounts visible to your token. With a bearer token this is always exactly one account — the account the token belongs to. That makes this endpoint the canonical way to discover your account id at connection time.

No parameters.

Errors

A missing or invalid token gets a 401 with an empty body. There are no other error cases — a valid token always sees its one account.

Request

GET

/api/v1/accounts

curl https://averase.com/api/v1/accounts \
  -H "Authorization: Bearer $TOKEN"

Response

[
  {
    "id": 1,
    "name": "Acme ITAD, LLC",
    "personal": false,
    "owner_id": 3,
    "created_at": "2026-07-01T15:04:11.000Z",
    "updated_at": "2026-07-27T00:15:39.000Z",
    "account_users": [
      { "id": 5, "user_id": 3 }
    ]
  }
]

GET/api/v1/accounts/:id

Retrieve an account

Returns a single account object by id. Since your token sees exactly one account, the only id that succeeds is your own — an unknown id and another account's id both return the same 404, indistinguishable by design.

Errors

Status	Body	Meaning
`401`	(empty)	Missing or invalid token
`404`	`{"error": "Account not found"}`	Unknown id, or an account outside your token's scope

Request

GET

/api/v1/accounts/1

curl https://averase.com/api/v1/accounts/1 \
  -H "Authorization: Bearer $TOKEN"

Response

{
  "id": 1,
  "name": "Acme ITAD, LLC",
  "personal": false,
  "owner_id": 3,
  "created_at": "2026-07-01T15:04:11.000Z",
  "updated_at": "2026-07-27T00:15:39.000Z",
  "account_users": [
    { "id": 5, "user_id": 3 }
  ]
}

Not found

{ "error": "Account not found" }

Linking an account to your integration

Do this once, when the customer first connects:

Fetch the account. Call GET /api/v1/accounts with the new token. The array always contains exactly one account.
Persist the id. Store the account's id alongside the token in your integration's configuration.
Send it back thereafter. Pass the stored id as the account_id parameter on every assets request. It isn't required — the token already pins the scope — but it acts as a cross-check: if configuration ever drifts (a token swapped between environments, say), the mismatch surfaces as a 404 instead of silently syncing the wrong tenant's data.

Both id forms are accepted for account_id: the numeric id from these endpoints and the prefixed acct_… form that appears on asset objects.

Sync your assets