You can connect Claude to Xero without giving Claude the Xero OAuth token. The default should be read-only: Claude asks questions about invoices and contacts, the proxy holds the Xero grant, rules block writes, and every call is logged.
Most unofficial connectors do the opposite. They complete Xero’s OAuth dance and drop the refresh token into a Claude Desktop or MCP (Model Context Protocol) config file. Claude then holds owner-level access to the organisation file.
The bookkeeper’s token in Claude Desktop
A bookkeeper at a suburban practice wanted Claude to answer “which invoices are overdue this week” while she was on the phone. She installed a Xero MCP server from a public repo, clicked through Xero’s consent screen as the practice owner, and pasted the resulting token into claude_desktop_config.json. The first prompt worked. The second prompt, from a colleague testing “create a bill for this supplier”, also worked. Xero saw the owner. There was no separate identity for Claude, and no log in the practice of what the model had written.
Xero’s Accounting API can read and write invoices, payments, bank transactions, contacts and settings. An owner-level grant is the whole file. An assistant that holds that grant is not a read-only helper. It is a second bookkeeper with no timesheet.
The stance for this guide is read-only and audited by default. The Xero token stays behind a proxy. Claude holds a scoped proxy credential. Writes are denied unless someone later changes the rules on purpose.
This article uses RequestRocket’s public object names – target, target credential, proxy, proxy credential, rules – and Xero’s published scopes. Screen labels from the console are left as placeholders until the existing Xero getting-started guide is applied. Do not treat the placeholder captions as UI text.
What does Xero’s API expose?
It exposes the accounting file: invoices, bills, payments, bank transactions, contacts, settings and reports, depending on the scopes you request.
Xero uses OAuth 2.0. A connected app receives an access token and, if you requested offline_access, a refresh token. Every Accounting API call also needs the organisation’s xero-tenant-id. The token is not a narrow invoice-reader unless you asked for a narrow scope.
From 2 March 2026, apps created on that date or later use granular scopes rather than the old broad ones. Xero’s 6 August 2026 changelog records that accounting.transactions is replaced by accounting.invoices, accounting.payments, accounting.banktransactions and accounting.manualjournals. Report scopes split the same way. Existing apps have until 13 September 2027 to migrate. For a new Claude connection, request only what the assistant needs – typically offline_access plus a read-only invoices scope such as accounting.invoices.read if your app is on granular scopes. Do not request payments, payroll or settings for a “what’s overdue” assistant.
Even a read-only Xero scope is still a Xero token. If it lives in Claude’s config, a leak works at Xero until you revoke the connection. Giving an agent API access without the API key is why the token belongs on the target, not in the MCP file.
Why Claude should not hold the Xero OAuth token
Because Claude’s config, logs and context are not a secrets store, and because a single owner grant cannot express “this assistant may only GET invoices”.
Three things go wrong when the token sits in the client:
- The secret is copyable. MCP configs are the files GitGuardian found thousands of secrets in. A shared repo or a support screenshot leaks a live refresh token.
- The grant is too wide. Xero scopes are chosen once, at consent. They do not change per prompt. A token that can read invoices can usually read every invoice in the organisation.
- Writes are one prompt away. If the scope includes write, Claude can post a bill. If it does not, a second unofficial server with a wider token often appears the same week.
The proxy holds the OAuth grant. Claude authenticates to the proxy. Rules on the proxy can deny POST, PUT and DELETE even when the stored Xero token would have allowed them. That is how read-only becomes a control, not a hope.
The same isolation is what you want when Claude calls Microsoft Graph without a tenant-wide mailbox token.
How to connect Claude to Xero through RequestRocket
Create a Xero target with an OAuth 2.0 credential, put a deny-by-default proxy in front of it, allow only invoice reads, then point Claude at the proxy as an MCP server.
These steps use documented objects only. Console click-paths wait on the getting-started guide.
1. Create a Xero app and decide scopes
In the Xero developer portal, create an app for this assistant, not a reuse of a production integration. For a new app, prefer granular read scopes. A payables helper needs invoice reads and offline_access. It does not need accounting.payments or settings.
[SCREENSHOT: Xero developer portal – new app, redirect URI, requested scopes]
2. Create the target
In RequestRocket, create a target whose base URL is Xero’s Accounting API. Attach a target credential of type OAuth 2.0. Complete the authorisation so RequestRocket stores the access and refresh tokens. Claude is not in this step and never sees those tokens.
[SCREENSHOT: new target – Xero base URL and OAuth 2.0 credential, after consent]
3. Create the proxy and a proxy credential
Create a proxy that uses that target. Issue a proxy credential that will identify this Claude assistant only. Set the proxy’s default rule effect to deny so nothing is allowed until you write an allow rule.
[SCREENSHOT: new proxy – bound to the Xero target, default deny]
4. Write read-only rules
Add rules that allow GET on the invoice paths you actually need. Do not allow POST, PUT or DELETE. Do not allow payments, bank transactions or users. If the invoice payload includes fields the assistant does not need, add a filter that removes them before the response reaches Claude.
[SCREENSHOT: rule list – GET invoices allowed, writes denied]
5. Connect Claude via MCP
Expose the proxy as an MCP server. In Claude, add that server. The MCP configuration contains the proxy URL and the proxy credential. It does not contain the Xero client secret, access token or refresh token.
[SCREENSHOT: Claude MCP connector – proxy URL only, no Xero token fields]
This is the same broker pattern as outbound API governance: identity at Claude, vendor secret on the target, policy on the call.
6. Run a test prompt
Use a prompt that should succeed:
List invoices that are overdue as of today. Include contact name, invoice number, due date and amount due. Do not create or change any records.
Then use a prompt that should fail:
Create a draft bill for $1.00 to a test contact.
The first prompt should return a short list. The second should be denied by the proxy, not accepted by Xero.
[SCREENSHOT: Claude conversation – overdue list returned, create-bill denied]
7. Review the audit trail
Open the proxy’s request log. You should see the allowed GET and the denied write, both attributed to this proxy credential. That is the record the practice keeps when a partner asks what Claude touched.
[SCREENSHOT: request log – GET allowed, POST denied, same caller]
What to check before you roll it out
A short list for the bookkeeper and the person who owns the Xero app.
- The Xero app’s scopes are read-only for the job. No payments, no payroll, no settings.
- The Xero tokens live only on the target credential.
- Claude’s MCP config has a proxy credential, not a Xero token.
- Default deny is on. Only named GET paths are allowed.
- A write prompt is denied in the log, not only “in the chat”.
- A second staff member using Claude does not share the first assistant’s proxy credential if you need separate attribution.
Where RequestRocket fits
RequestRocket holds the Xero OAuth credential, applies the read-only rules, can filter invoice fields, meters the assistant if you set a cap, and records every call. It can expose that proxy as an MCP server so Claude never needs a Xero MCP that stores tokens. It does not replace Xero’s own user permissions, and it does not provide a model. Claude still reasons. The proxy decides what Xero is asked.
FAQ
Can I use Xero’s granular scopes and skip the proxy?
Granular scopes are the right consent at Xero. They still put a Xero token in Claude if you stop there. Use both: narrow consent at Xero, and per-call deny of writes at the proxy.
Does this work with Claude.ai, Claude Desktop, or both?
The pattern is the same wherever Claude can add an MCP server or an HTTP tool that points at the proxy. The exact connector screen depends on the Claude product you use. Leave that label to the screenshot once the getting-started guide is applied.
What if we later want Claude to create drafts?
Change the rules on the proxy to allow a specific write path, preferably to a drafts endpoint only, and keep the audit on. Do not paste a wider Xero token into Claude to save a step.
Will Xero see Claude as a separate user?
Xero will see the connected app and the consenting user. RequestRocket will see the proxy credential. That is how you tell two assistants apart when they share one Xero grant.
Is payroll in scope of this guide?
No. Do not request payroll scopes for a payables assistant. If a later use case needs them, treat that as a new proxy with its own rules, not an expansion of this one.
Where is the official Xero getting-started guide?
Ask the RequestRocket team for the existing Xero walkthrough before you treat console labels in this article as final. Placeholders above mark every screen that still needs a captured image.
Book a walkthrough of RequestRocket