Overview
In the Expense API, organizations are accessed through the user context (/me/organizations). Unlike the Admin API where you manage organizations directly, the Expense API returns only the organizations the authenticated user is a member of, along with their permissions, design settings, and support configuration.
This is typically the first call after authenticating a user — the organization ID is required for nearly every subsequent Expense API call.
Key concepts
List user organizations
Retrieve all organizations the authenticated user belongs to.Query parameters
Example request
bash
Example response
Get a single organization
Retrieve details for a specific organization.Path parameters
Query parameters
Permissions reference
Themeta.permissions object controls which actions the user can perform within an organization. Always check these before rendering action buttons in your UI.
Organization sub-resources
Once you have an organization ID, you can access its configuration. These endpoints return the data needed to populate dropdowns, validate input, and render expense forms.Expense types
Retrieve the expense types available in the organization. Use this to determine which types of expenses a user can create.Categories
Retrieve expense categories for a specific expense type. Categories can include suggestions when ascanResultId is provided.
Currencies
Retrieve available currencies for the organization.Payment types
Retrieve available payment types (e.g., cash, corporate card, private card).Countries
Retrieve the list of countries available in the organization.Custom field lists
Retrieve values for a custom field list (used for custom dimensions like cost center, project, etc.).Chart of accounts
Search the organization’s chart of accounts.Policy documents
Retrieve a policy document for the organization.Common integration patterns
Pattern 1: Organization selector
If a user belongs to multiple organizations, present an organization selector at startup and store the selected ID for subsequent API calls.design object (logo, accent colors) to visually distinguish organizations and the permissions object to show/hide features in your UI.
Pattern 2: Cache organization configuration
Categories, currencies, payment types, and other list data change infrequently. Cache these per organization and refresh periodically rather than fetching on every form render.Pattern 3: Permission-driven UI
Build your UI conditionally based on the user’s permissions:Integration best practices
Always fetch permissions on login
Always fetch permissions on login
Call
GET /v1/expense/me/organizations?include=meta.permissions immediately after authentication. Store the permissions object in your app state and use it to conditionally render UI elements. Never assume a user has a specific permission — organizations can configure these independently.Cache sub-resource data per organization
Cache sub-resource data per organization
Expense types, categories, currencies, and payment types rarely change. Fetch them once per session (or cache for up to 24 hours) and store them keyed by organization ID. This avoids redundant API calls when users navigate between expense forms.
Handle multi-organization users
Handle multi-organization users
Users can belong to multiple organizations, each with different permissions, expense types, and configurations. Always prompt for organization selection when
meta.total > 1, and reload all sub-resource data when the user switches organizations.Use include parameters to reduce payload size
Use include parameters to reduce payload size
Only request the data you need. For an organization selector screen,
include=design,meta.permissions is sufficient. Skip settings unless you need to display support information or enforce receipt size limits.Respect settings constraints in your UI
Respect settings constraints in your UI
The
settings object contains values your UI should enforce — such as expenseReceiptMaxSize (max upload size in MB) and reportMaxNumberOfExpenses (max expenses per report). Validate these client-side before making API calls to avoid unnecessary errors.Error handling
The API uses standard HTTP status codes. Handle these common scenarios when working with organization endpoints:Example error response
When a user receives a
403 or 404 on an organization they previously had access to, their membership may have been revoked. Refresh the organizations list and redirect to the organization selector.
