Team, keys and logs on the account axis

11 October 2026

The account axis (/v1/accounts/{account}/…) now tells you who did what and when, so an integration can show the same picture the app shows in Team and Developers. Everything on this page is additive: nothing was removed and no existing field changed meaning.

Daily usage of an API key

getAccountApiKeyUsage (GET /v1/accounts/{account}/api-keys/{api_key}/usage, scope account:read) returns the usage of one key over the last 7, 30 (default) or 90 days with the days query parameter. Any other value answers 422.

data.daily has one item per day, oldest first, with requests_count, successful_count, client_error_count, rate_limited_count and error_count; days without requests appear with every counter at 0. data.total sums the period, and last_used_at and last_used_ip tell when and from where the key was last used (null if it never was). It only returns counters, never quota, tier limits or prices. A key that does not exist, belongs to another account or reaches a tax ID outside your credential answers the same 404 api_key_not_found. The MCP tool is get_api_key_usage.

API keys: restrictions, authorship and rotation

The key operations (list, retrieve, create, revoke, rotate the secret and change the tax IDs) now return:

• ip_allowlist and allowed_origins: the IP addresses or ranges and the browser origins the key is restricted to, or null.
• last_used_ip, next to last_used_at.
• nif_scope: the tax IDs the key reaches, each as {id, tax_id, name, access_level} with access_level view or operate.
• created_by, revoked_by and revoke_reason: who created and who revoked the key, and why.
• secret_rotated_at, secret_rotated_by and previous_secret_valid_until: when the secret was last rotated, by whom, and until when the previous secret still authenticates.

Creating and rotating still return the secret once, and only then. A rotation made with an API credential or the MCP server never names a person: secret_rotated_by stays null. The MCP tools get_api_key and list_api_keys return the same fields.

Members and invitations: when

Members now carry joined_at and last_access_at. The second one is a lower bound: support impersonation and OAuth or MCP accesses do not count, so a member can be active without it moving.

Invitations now carry created_at, sent_at (the creation or the last resend) and invited_by, an {id, name} object that is null when that person no longer belongs to the account. The members and invitations tools in MCP return them too.

Request logs: company, axis and filters

The request logs of the account and of a company now say which tax ID each request acted on and on which axis:

• company: {id, tax_id, name}, or null when the request did not act on a company.
• axis: company or account, derived from the path prefix.

Both lists accept the new filter company=<uuid>, which limits the logs to one company; a company outside your scope answers 422 invalid_param_value with param company. The account list also accepts relationship=own|client, which limits the logs to your own tax IDs or to those of client accounts. The four log tools in MCP return the new fields and take the filters of their operation.

Stripe Connect return domains

The list of return domains now carries meta.max (20), the most domains an account can register. The list is complete when has_more is false, so data against max tells how many slots are left.

Correction: a disabled webhook endpoint can be reactivated

The account webhooks guide said that a disabled endpoint could not be turned back on. It can: send PATCH with status: active and the endpoint receives events again. The guide and the MCP descriptions now say so.

KeyRound

API keys

UsersRound

Accounts and tax IDs

Webhook

Account webhooks