> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myabode.ca/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication and API keys

> How to authenticate to the myAbode Deals API with bearer API keys, the difference between member keys and brokerage service keys, and what each scope allows.

Every request to the myAbode Deals API sends an API key as a bearer token:

```http theme={null}
Authorization: Bearer mya_your_key_here
```

A request with no key gets `401 API_KEY_REQUIRED`. A key that is unknown, revoked or expired gets `401 API_KEY_INVALID`. The response is the same in all three cases, so it never reveals why a key was rejected or whether it ever existed.

## Kinds of key

| Key | Created by | Reads |
| - | - | - |
| **Service key** | A brokerage admin | The whole brokerage, read-only, within the scopes chosen. It keeps working if the admin who created it leaves. |
| **Member key** | A member, for themselves | Exactly what that person can see in myAbode Deals, and deals only. |
| **Partner application key** (`myapp_…`) | myAbode, for an integration partner | Every brokerage that has granted the application access. See [Partner applications](https://docs.myabode.ca/api/partner-applications.md). |

Use a service key for a system that serves the brokerage, such as reporting, a CRM sync or accounting. Use a member key for a personal tool that should see only what that person sees.

## Scopes

A key holds one or more scopes, and each endpoint requires one:

| Scope | Allows | Notes |
| - | - | - |
| `deals:read` | Deals | The only scope a member key can hold |
| `tasks:read` | Tasks | Requires `deals:read` |
| `events:read` | The event feed | Requires `deals:read`; task events also need `tasks:read` |
| `users:read` | Users | Service keys only |
| `offices:read` | Offices | Service keys only |

`tasks:read` and `events:read` need `deals:read` because task descriptions and events can name clients. Granting `deals:read` is how a brokerage agrees to share client details with the key.

A valid key without the scope an endpoint needs gets `403 INSUFFICIENT_SCOPE`.

## Keeping keys safe

* A key is shown once, when it is created. Store it in a secrets manager.
* Give each system its own key, so you can revoke one without breaking the others.
* Grant only the scopes a system needs.
* Revoke a key from **Get API Keys** as soon as it is no longer used or may have leaked. Revocation takes effect on the next request.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.