Access & Authentication
Every request to the Addepar API must be authenticated. The API supports two authentication methods, and which one you use determines how your integration accesses data, how permissions are scoped, and how credentials are managed over time.
Choosing your authentication method
| Factor | API Key (Basic Auth) | OAuth 2.0 |
|---|---|---|
| Use when | Your integration runs as a single service account within one firm | Your application accesses data on behalf of multiple users or across multiple firms |
| Credential model | Static key/secret pair tied to a specific user | Access token (240s) + refresh token, issued per user authorization |
| Permission scope | Inherits the creating user's full data and tool permissions | Scoped to specific OAuth scopes authorized by each user |
| Multi-firm | One key per firm | Single application authorized across multiple firms |
| Rotation | Manual: create new key, update integration, delete old key | Automatic: refresh token obtains new access tokens without user intervention |
| Setup effort | Minutes (create key in Firm Admin) | Hours (register application, implement authorization flow, handle token lifecycle) |
Decision rule: If your integration serves a single firm with a dedicated service account, use API Key authentication. If your integration serves multiple users, multiple firms, or is distributed as a product, use OAuth.
API Key authentication (Basic Auth)
How it works
Addepar uses HTTP Basic Authentication. You create an API key in Firm Administration, receive a key/secret pair, and include the pair (base64-encoded) in every request header.
| Property | Value |
|---|---|
| Protocol | HTTPS only. HTTP requests are rejected. |
| Auth scheme | HTTP Basic Authentication |
| Credential format | Base64(key_id:key_secret) |
| Required headers | Authorization, Addepar-Firm |
Permission inheritance
The API key inherits the permissions of the user who created it. This is the critical design constraint: the key can access exactly what that user can access, nothing more.
| Permission layer | What it controls | Where configured |
|---|---|---|
| API Access | Whether the user can create keys and make API calls at all | Firm Administration > Users > Permissions > API Access |
| Tool Permissions | Which operations are allowed (view, create, update, delete) across entity types | Firm Administration > Users > Permissions |
| Portfolio Access | Which specific entities, groups, and portfolios the user can see | Firm Administration > Users > Portfolio Access |
If a request returns 403 Forbidden, the issue is in one of these three layers. If a request returns 404 Not Found for a resource that exists, the user behind the key likely lacks Portfolio Access to that specific entity.
Setup
1. Grant API Access to the user:
- Navigate to Firm Administration > Users (under User Permissions).
- Select the user who will own the API key.
- Open the Permissions tab.
- Set API Access to "Create, edit, and delete."
2. Create the API key:
- Navigate to Firm Administration > Admin Tools > API Access Key.

- Click the + button in the table header.
- Enter a description (use the integration name for traceability).
- Click Create.

- Record the key and secret immediately. The secret is displayed only once.

3. Determine your firm subdomain and firm ID:
- Your firm subdomain is in your Addepar login URL:
https://{subdomain}.addepar.com - Your firm ID can be found in the application URL path when signed in, or by using the API URL generator in the Analysis Tool (Export > Generate API URL >
addepar_firm=value).
Request format
GET and DELETE requests:
curl -X GET "https://{firm}.addepar.com/api/v1/entities/1234" \
-H "Authorization: Basic {base64(key_id:key_secret)}" \
-H "Addepar-Firm: 1" \
-H "Accept: application/vnd.api+json"
POST and PATCH requests (include Content-Type):
curl -X POST "https://{firm}.addepar.com/api/v1/entities" \
-H "Authorization: Basic {base64(key_id:key_secret)}" \
-H "Addepar-Firm: 1" \
-H "Content-Type: application/vnd.api+json" \
-H "Accept: application/vnd.api+json" \
-d '{
"data": {
"type": "entities",
"attributes": {
"currency_factor": "USD",
"model_type": "PERSON_NODE",
"original_name": "New entity"
}
}
}'
| Header | When required | Value |
|---|---|---|
Authorization | Always | Basic + space + base64-encoded key_id:key_secret |
Addepar-Firm | Always | Your numeric firm ID |
Content-Type | POST and PATCH | application/vnd.api+json |
Accept | Recommended on all requests | application/vnd.api+json |
Key management
| Practice | Why |
|---|---|
| One key per integration | If a key is compromised, only that integration is affected. Revocation is surgical. |
| Dedicated service account | Separates API access from a human user's account. The integration continues working if the person leaves the firm. |
| Store in a secrets vault | Keys grant full access to the user's data scope. Treat them as production credentials. |
| Review usage regularly | In Firm Administration > API Access Key, "Display all access keys" shows last-used dates. Delete keys that have not been used in 90+ days. |
| Rotate on personnel change | When the key owner leaves the organization or changes roles, create a new key under a new owner and revoke the old one. |
Related
- OAuth - Token-based authentication for multi-user and multi-firm applications
- Rate Limiting - Request budget shared across all credentials at a firm
- Response Codes - 401 vs 403 diagnostic and troubleshooting
Updated 5 days ago