Xero package v1.1.0

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.

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 minimum R3 tier: 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 configuration to review and test; the vendor has not endorsed it.

Effect-handle equivalence for xero.invoices.create@1.1.0: effect_id_body_pointer /Invoices/0/InvoiceID makes AAES capture InvoiceID from the single invoice in the same 2xx creation response. Digest mode keeps the financial response body from the agent, the receipt digest covers the original bounded body, and effect_id_source records body.Invoices[0].InvoiceID beside the value. The body declaration is authoritative: an unexpected effect-ID header is logged as ignored and is never used or merged. Capture requires exactly one array element and a canonical UUID. A missing, malformed, over-long or non-UUID value, an oversized body, multiple invoices, or validation warnings or errors each produce a post-dispatch refusal requiring reconciliation, never a silent success or an automatic retry with a new key.

Established from the reviewed OpenAPI specification: createInvoices describes its 200 response as a newly created Invoice; InvoiceID is described as a Xero-generated unique identifier with UUID format; InvoiceNumber is described as a unique alphanumeric code that is auto-generated when omitted; GET /Invoices/{InvoiceID} retrieves a specific invoice; and the required xero-tenant-id header selects the tenant. These statements establish provider assignment, UUID shape and a readback route at specification level. They do not prove identifier stability over time, uniqueness within the tenant, or live create-versus-update behavior. Stability and tenant-scoped uniqueness remain asserted properties requiring sector/provider reviewer confirmation.

A complete equivalence argument also requires the InvoiceID to be minted by this call. The response schema has no create-versus-update marker. If PUT updates in place when InvoiceNumber or InvoiceID matches an existing invoice, extraction alone cannot distinguish that update from creation. A Xero-specific request adapter at the gateway decision boundary must pin a fresh, client-generated, unique InvoiceNumber into the single invoice for each intent and seal that exact payload before dispatch. Asserted for this design and requiring sector/provider reviewer confirmation: Xero enforces per-organisation InvoiceNumber uniqueness, so a retry with the same pinned number updates that invoice and returns the same InvoiceID. The existing scalar request contract cannot express a generated nested field, and changing the payload in the connector after the intent is sealed would break the intent binding. Pinning therefore remains outside this connector change. Until that adapter and the provider review exist, minted-by-this-call is an unproven equivalence property, not a claim made by this pack.

Versioning: pack version 1.1.0 is the release in which xero.invoices.create moved to 1.1.0 (the effect_id_body_pointer declaration above); the other capabilities are unchanged since 1.0.0 and keep it, because a capability's version is the pack version in which its registration last changed.