Skip to content

feat: Bank Transfers: soft-delete, status, and tracking categories#822

Open
jeremy-drummond-xero wants to merge 1 commit into
XeroAPI:masterfrom
jeremy-drummond-xero:feature/transfers-uplift
Open

feat: Bank Transfers: soft-delete, status, and tracking categories#822
jeremy-drummond-xero wants to merge 1 commit into
XeroAPI:masterfrom
jeremy-drummond-xero:feature/transfers-uplift

Conversation

@jeremy-drummond-xero

Copy link
Copy Markdown

Overview

Extends the Accounting OpenAPI spec for /BankTransfers to reflect new endpoint capabilities: soft-deleting transfers (single and bulk), a Status field on responses, and tracking categories on reads and create.

Changes

New Status field (BankTransfer schema, read-only)

  • Added to all GET and create responses. Values: AUTHORISED or DELETED.

New tracking categories (BankTransfer schema)

  • Added FromTracking and ToTracking arrays, surfaced on GET (index + by-id) and create responses.
  • Introduces a TrackingReference schema: TrackingCategoryID + TrackingOptionID on write; resolved Name + Option echoed back on read (read-only). Max 2 per account.

Soft-delete operations (two new POST operations)

  • deleteBankTransferPOST /BankTransfers/{BankTransferID}, single transfer; body carries Status: DELETED (BankTransferDelete schema).
  • deleteBankTransfersPOST /BankTransfers, bulk array of {BankTransferID, Status} (BankTransfersDelete schema).
  • Both return the deleted transfer(s) with Status: DELETED.

New includeDeleted query parameter (GET /BankTransfers)

  • Opt-in boolean to include DELETED transfers in the index response. Default behaviour (deleted excluded) is unchanged.

Comment thread xero_accounting.yaml
- accounting.transactions
tags:
- Accounting
operationId: deleteBankTransfer

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I named the soft-delete ops delete* (not update*): delete is the only mutation the endpoint honours today — any other field-update 400s — and delete* keeps us consistent with deletePayment/deleteBatchPayment. The one tension is that if transfers ever become editable, renaming delete*update* is a breaking SDK change for a non-breaking API addition — but I've check and it looks like SDK versions can be managed independently of the spec, so that rename can be absorbed without forcing a spec-version break.

Comment thread xero_accounting.yaml
type: array
items:
$ref: "#/components/schemas/BankTransferDelete"
TrackingReference:

@jeremy-drummond-xero jeremy-drummond-xero Jun 11, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Introduced TrackingReference rather than reusing TrackingCategory or LineItemTracking because the bank transfer tracking contract is write-by-ID-only with names echoed back on read. That requires Name/Option to be readOnly. TrackingCategory is the wrong entity (carries Status + nested Options[]), and LineItemTracking presents Name/Option as writable — reusing either would have the contract slightly wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant