API Updates

This update introduces new fields for expenses and connection health, along with changes to connection statuses and API rate limits.

Payment methods on expenses

The Expense object now includes a nullable payment_method array that provides payment information for product-origin expenses.

Each entry contains:

• card_name: The name of the card used.
• date: The payment date and time.
• amount: The payment amount in USD.

For transaction-origin expenses, payment_method is null. It can also be null when payment information is unavailable.

Connection health status

The Merchant and Administrator objects now include a status field that indicates connection health.

Possible values are:

• HEALTHY
• DEGRADED
• DOWN

This field provides visibility into the health of supported merchant and administrator connections.

Connection status renamed to syncing

The connection status aggregating has been renamed to syncing.

This change affects:

• Connection object: The Connection.status field now uses syncing.
• List Connections: The status query parameter now accepts syncing instead of aggregating.
• Connection status webhooks: The connection.status_changed event can include syncing in its status and previous_status fields.

The supported connection statuses are now:

active, syncing, user_input_required, error, and disconnected.

Action required: If your integration checks for aggregating or uses it when filtering connections, update it to syncing.

API rate limits

The API documentation now specifies rate limits per API key and endpoint, including both per-minute limits and per-second burst limits.

API responses include the following headers to help you monitor usage:

• RateLimit-Limit: The request limit for the current window.
• RateLimit-Remaining: Requests remaining in the current window.
• RateLimit-Reset: Seconds until the current window resets.
• RateLimit-Policy: The configured rate-limit windows.

Requests that exceed a limit return HTTP 429 with a Retry-After header indicating how long to wait before retrying.

When handling rate limits, use exponential backoff and respect the Retry-After value.