> For the complete documentation index, see [llms.txt](https://help.openloyalty.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.openloyalty.io/technical-guide/data-exports/data-structure-and-types/unit-transfers.md). # Unit Transfers Every unit transfer (added, spent, expired, blocked, transferred), exported daily as a delta file. The Unit Transfers file contains every unit movement on member wallets: units added, spent, expired, blocked, and transferred between members. {% hint style="info" %} **Delta export.** Each daily file contains the transfers that were created or updated during that day. A transfer reappears whenever its state changes, for example when it is cancelled or a pending transfer becomes active. Upsert on `transferId` and keep the row with the latest `updatedAt`. {% endhint %} **File:** `analytics/Points/points_YYYY_MM_DD.csv`\ **Primary key:** `transferId` A sample file is provided below: {% file src="/files/4MZ2BGCf6scdBa3CYuhv" %} **Available Data** (in column order, see Column types for how each type is written):

Column	Type	Can be empty	Description
`transferId`	uuid	No	Unique ID of the transfer
`tenantId`	uuid	No	ID of the tenant where the transfer was created
`points`	decimal	No	Number of units in the transfer. Always a positive number. Use `type` to determine the direction (see Transfer types).
`memberId`	uuid	No	ID of the member who owns the wallet
`walletId`	uuid	No	ID of the wallet (links to `walletId` in the Wallet Balance file and `defaultAccount.accountId` in the Members file)
`walletTypeCode`	string	No	Code of the wallet type
`firstName`	string	Yes	Member's first name
`lastName`	string	Yes	Member's last name
`email`	string	Yes	Member's email address
`phone`	string	Yes	Member's phone number
`loyaltyCardNumber`	string	Yes	Member's loyalty card number
`type`	enum	No	Type of the transfer: `adding`, `p2p_adding`, `spending`, `p2p_spending`, `blocked`, `expired` (see Transfer types)
`createdAt`	datetime	No	Date when the transfer was created
`expiredAt`	datetime	Yes	Date when the units of this transfer expire or are scheduled to expire
`cancelled`	boolean	Empty = false	Whether the transfer is cancelled
`cancelledAt`	datetime	Yes	Date when the transfer was cancelled
`locked`	boolean	Empty = false	Whether the transfer is currently pending, meaning its units are not yet active
`unlockAt`	datetime	Yes	Date when a pending transfer is scheduled to become active
`comment`	string	Yes	Comment on the transfer (for example a manual comment, the campaign name, or the reward name)
`campaignId`	uuid	Yes	ID of the campaign that created the transfer
`transactionId`	uuid	Yes	ID of the transaction that triggered the transfer
`customEventId`	uuid	Yes	ID of the custom event that triggered the transfer
`internalEventName`	string	Yes	Name of the internal event that triggered the transfer
`performedAt`	datetime	Yes	Business date of the transfer (the transaction's purchase date or the custom event's `eventDate`)
`updatedAt`	datetime	No	Date when the transfer was last updated
`labels`	json array	Yes	JSON with the custom attributes set on the transfer

**Transfer types**


`type`	Direction	Meaning
`adding`	+	Units added (campaign, manual, import). Can be pending (`locked`) and can be cancelled.
`p2p_adding`	+	Units received from another member
`spending`	−	Units spent, for example on a reward
`p2p_spending`	−	Units sent to another member
`blocked`	−	Units blocked. Can be cancelled, which releases them.
`expired`	−	Units that expired. Each expiry creates a new `expired` row. The original `adding` row is not modified.

{% hint style="warning" %} Because `points` is always positive, a plain sum of the column is meaningless. Apply the sign from the table above before aggregating. See Reconciliation for how to rebuild a wallet balance from this file. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.openloyalty.io/technical-guide/data-exports/data-structure-and-types/unit-transfers.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.