xero v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-xero-access-token

Custody

customer_vault

Injection

header (Authorization)

An OAuth2 access token for the Xero Accounting API, held in the client's own secret manager under this reference. Xero issues tokens through the OAuth2 authorization-code flow (authorization endpoint login.xero.com, token endpoint identity.xero.com); a refresh token is issued only if the app requested the offline_access scope at authorization, so the external token process's authorization must include it. Per Xero's documented expiry times, the access token lives 30 minutes and the refresh token 60 days, and Xero rotates the refresh token on every refresh — the refresh response carries a new refresh token that must be saved in place of the old. Exactly one external token process therefore owns the refresh path: it refreshes, stores the FRESH access token under this reference, and keeps the rotating refresh token and the app's client credentials to itself — the executor and the agent never see them, and this pack does not store one. The consequence of splitting the refresh path is real but not instantaneous: Xero documents a 30-minute grace period after each refresh during which the previous refresh token still works (so a client that lost the response can retry) — two processes refreshing independently may both succeed within that window, and invalidation follows when the grace period ends, at which point one side's token chain is dead and re-authorization is required. Treat any second refresh process as a wiring fault regardless. Revocation is documented and active: POST identity.xero.com/connect/revocation with the refresh token revokes it and removes the app's connections, and a single tenant connection can be dropped with DELETE api.xero.com/connections/{connectionId}; an already-issued access token otherwise stands until its 30-minute expiry. The stored material must be the complete Authorization header value (scheme included: 'Bearer <access-token>'). Choose the least-privilege scopes the spec names for these endpoints: accounting.contacts.read, accounting.transactions.read, and accounting.transactions for invoice creation. At execution time the resolved bearer material exists in the executor process's memory for the moment of injection only — the deployment owns the executor's memory, log, trace and crash hygiene; the agent never receives it.

• xero-organisation (api, financial): https://api.xero.com/api.xro/2.0

The registered host api.xero.com is Xero's single shared API host, and the registered paths and methods are from Xero's official Xero-OpenAPI specification: collection GETs on /Contacts, /Invoices, /Payments and /BankTransactions, and invoice creation as PUT /Invoices — the narrower fact is that THIS PACK registers PUT creation; Xero's specification also offers POST create-or-update on the same collection, which this pack does not register. Every call also requires the xero-tenant-id header, which the same specification declares a required header; this pack registers the Authorization injection only, so the tenant id is connector or deployment configuration, set by the operator — never supplied by the agent. The developer.xero.com documentation pages require a JavaScript browser to render; this review verified the operations, methods, scopes and required headers against the official spec instead, and the OAuth lifecycle claims against Xero's rendered OAuth 2.0 auth-flow guide. Invoice creation is declared as create plus approve at the R3 floor: Xero invoices can be created in DRAFT or AUTHORISED status from the caller-controlled request body, an AUTHORISED invoice is a posted ledger document — an approved financial record, not a draft — and the registered endpoint cannot enforce a draft-only choice, so unrestricted creation on this route includes approval of the created document. An installer's intention to request only DRAFT is not a restriction the pack can enforce. This pack does not register payment creation (see below), bank transaction creation, invoice email, attachments, history-and-notes writes, updates, or deletes — and note what a payment is here: a Xero Payment records a payment against an invoice in the ledger, a bookkeeping entry, not an instruction that moves funds; actual money movement happens through the organisation's bank outside this API. Recording such a payment is still a financial write this pack leaves out. AAES has not been certified by Xero; the endpoints here are a reviewable default, not a vendor guarantee.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• https://raw.githubusercontent.com/XeroAPI/Xero-OpenAPI/master/xero_accounting.yaml (retrieved 2026-09-21)
• https://developer.xero.com/documentation/guides/oauth2/auth-flow/ (retrieved 2026-09-21)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.