Every API here is available over the APIs.io API and to AI agents over MCP.
openapi: 3.2.0
info:
title: Memo Bank Transfers API
description: '**Welcome!** You can use our [Premium Bank API](https://memo.bank/produit/api/) to check your company’s accounts, fetch your transactions, make SEPA transfers, initiate SEPA direct debit collections, create virtual IBANs, and access most of Memo Bank features.
> info
> If you are a **third-party payment service provider** complying with PSD2, you may be more interested in our [NextGenPSD2 API](https://docs-nextgenpsd2.api.memo.bank).
'
version: '2.0'
servers:
- url: https://api.memo.bank
description: Production
- url: https://api.sandbox.memo.bank
description: Sandbox
tags:
- name: Transfers
description: 'Transfers are transfers within the SEPA-zone, including SEPA standard transfers, SEPA instant transfers and Target 2 transfers.
They can be initiated asynchronously, one by one or in bulk.
They have a similar lifecycle compared to [transactions](#endpoint-transactions) but note that there are some minor differences for the `canceled` and `failed` states.
<img src="https://assets.memo.bank/memobankapi/transfers-lifecycle-api-v3.png" alt="Transfers lifecycle" width="750">
'
paths:
/v2/transfers/{id}:
get:
tags:
- Transfers
summary: Get a transfer
description: '**Scope**: `transfers:read`'
operationId: getTransfer
parameters:
- name: id
in: path
description: ID of the transfer.
required: true
schema:
type: string
format: uuid
example: aa431134-bdc4-416e-8b7e-58a39e389707
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/TransferV2'
security:
- JWT: []
delete:
tags:
- Transfers
summary: Cancel a SEPA transfer
description: 'This endpoint allows you to cancel a SEPA transfer before its execution has actually started.
Concretely a transfer can be canceled while in `scheduled` or `authorized` state. However, attempting to cancel a transfer in `authorized` state may result in a `transfer_not_cancelable` error if the transfer has already been sent to the creditor''s bank. For the same reason, instant transfers cannot be canceled at all.
**Scope**: `transfers:write`'
operationId: cancelTransfer
parameters:
- name: id
in: path
description: ID of the transfer.
required: true
schema:
type: string
format: uuid
example: aa431134-bdc4-416e-8b7e-58a39e389707
responses:
'200':
description: OK
security:
- JWT: []
/v2/transfers:
post:
tags:
- Transfers
summary: Initiate a SEPA transfer
description: 'This endpoint allows you to initiate a SEPA transfer from your account.
**Scope**: `transfers:write`'
operationId: createTransferV2
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreateTransferV2'
required: true
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/TransferV2'
security:
- JWT: []
/v2/transfers/bulks:
post:
tags:
- Transfers
summary: Create bulk transfers
description: 'This endpoint allows to create up to 5000 transfers with a single call. It acts exactly as if you called the `POST /v2/transfers` endpoint 5000 times yourself, except you don''t need to worry about rate limiting. It also allows you to get an aggregated state for this bulk.
This endpoint does not perform the transfers synchronously, a `200 OK` response means the bulk will be handled in the near future. You can either poll the `GET` endpoint or use the webhooks to follow its progress.
Note that the completion of a bulk does not mean all transfers are settled, it only means the transfers were initiated (the equivalent of a call to `POST /v2/transfers`).
**Scope**: `transfers:write`'
operationId: createTransfersBulk
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreateBulkTransfers'
required: true
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/BulkTransfers'
security:
- JWT: []
/v2/transfers/{id}/proof:
get:
tags:
- Transfers
summary: Generate a proof of transfer
description: 'Proofs can only be generated for confirmed transfers.
**Scope**: `transfers:read`'
operationId: getProofOfTransfer
parameters:
- name: id
in: path
description: ID of the transfer.
required: true
schema:
type: string
format: uuid
example: c70bd7bc-58e0-4fdb-8c1f-70186e0de587
responses:
'200':
description: OK
content:
application/octet-stream:
schema:
type: string
format: binary
security:
- JWT: []
/v2/transfers/bulks/{id}:
get:
tags:
- Transfers
summary: Get a bulk and its current progress
description: '**Scope**: `transfers:read`'
operationId: getTransfersBulk
parameters:
- name: id
in: path
description: ID of the bulk.
required: true
schema:
type: string
format: uuid
example: 6ba07619-24ff-43f3-b1f0-cdc9b06bf8a7
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/BulkTransfers'
security:
- JWT: []
/v2/transfers/bulks/{id}/transfers:
get:
tags:
- Transfers
summary: Get the status of individual transfers in a bulk
description: '**Scope**: `transfers:read`'
operationId: getTransfersBulkItems
parameters:
- name: id
in: path
description: ID of the bulk.
required: true
schema:
type: string
format: uuid
example: 6ba07619-24ff-43f3-b1f0-cdc9b06bf8a7
- name: status
in: query
description: Filter transfers by status.
schema:
uniqueItems: true
type: array
items:
type: string
enum:
- pending
- scheduled
- authorized
- confirmed
- returned
- canceled
- failed
- name: page
in: query
description: Index of the requested page. Deprecated, use `page_token` instead.
deprecated: true
schema:
minimum: 1
type: integer
format: int32
- name: page_token
in: query
description: Token used to fetch a specific page, as returned by the `next_page_token` or `prev_page_token` field of a previous response. Mutually exclusive with `page`.
schema:
type: string
- name: size
in: query
description: Number of elements per page in response.
schema:
maximum: 100
minimum: 1
type: integer
format: int32
default: 10
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/TransferV2Page'
security:
- JWT: []
components:
schemas:
CreateBulkTransfers:
required:
- transfers
type: object
properties:
transfers:
type: array
description: Transfer creations to execute. There should not be more than 5000 transfers in a single bulk, and there should be at least one.
items:
$ref: '#/components/schemas/CreateTransferV2'
TransferV2Page:
required:
- has_next
- has_prev
- results
type: object
properties:
results:
type: array
description: Elements of the page.
items:
$ref: '#/components/schemas/TransferV2'
has_prev:
type: boolean
description: Flag indicating if there is a previous page. Deprecated, use `prev_page_token` instead.
deprecated: true
has_next:
type: boolean
description: Flag indicating if there is a next page. Deprecated, use `next_page_token` instead.
deprecated: true
next_page_token:
type: string
description: Token to fetch the next page, to be passed in subsequent requests as the `page_token` query parameter. `null` when there is no next page.
nullable: true
example: eyJwIjozfQ
prev_page_token:
type: string
description: Token to fetch the previous page, to be passed in subsequent requests as the `page_token` query parameter. `null` when there is no previous page.
nullable: true
example: eyJwIjoxfQ
BulkTransfers:
required:
- id
- status
- transfers_canceled
- transfers_confirmed
- transfers_failed
- transfers_total
type: object
properties:
id:
type: string
description: ID of the bulk.
format: uuid
example: fe98f29d-5165-45ff-83f9-d7aa83e970b5
transfers_total:
type: integer
description: Total number of transfers in the bulk.
format: int32
example: 3000
transfers_confirmed:
type: integer
description: Number of transfers that were processed and confirmed.
format: int32
example: 1552
transfers_canceled:
type: integer
description: Number of transfers canceled before processing.
format: int32
example: 2
transfers_failed:
type: integer
description: Number of transfers that were processed and failed.
format: int32
example: 57
status:
type: string
description: Aggregated status of the bulk.
example: pending
enum:
- pending
- completed
TransferBeneficiaryAddress:
required:
- city
- country
- postal_code
- street
type: object
properties:
street:
maxLength: 256
minLength: 1
type: string
description: Name of the street.
example: rue de la Boétie
postal_code:
maxLength: 256
minLength: 1
type: string
description: Postal or zip code.
example: '75008'
city:
maxLength: 256
minLength: 1
type: string
description: Name of the city.
example: Paris
country:
pattern: ^[A-Z]{2}$
type: string
description: ISO3166-1 alpha-2 country code.
example: FR
description: Address of the beneficiary. Will be used to create the beneficiary if one doesn't already exist with the same `account_identifier`, will be ignored otherwise.
CreateTransferV2:
required:
- amount
- beneficiary_iban
- local_iban
type: object
properties:
amount:
minimum: 1
type: integer
description: Amount of the transfer, in cents. The currency is always EURO.
format: int64
example: 500
beneficiary_name:
type: string
description: Name of the beneficiary. Will be used to create the beneficiary if one doesn't already exist with the same `beneficiary_iban`, will be ignored otherwise. If you know the beneficiary exists, you don't need to provide a name here.
example: John Doe
beneficiary_address:
$ref: '#/components/schemas/TransferBeneficiaryAddress'
beneficiary_iban:
pattern: ^[A-Z]{2}[0-9]{2}[a-zA-Z0-9]{1,30}$
type: string
description: IBAN of the beneficiary. Note that when you perform a transfer between your own accounts, you can't use a virtual IBAN.
example: FR2512739000308553756377J95
local_iban:
pattern: ^[A-Z]{2}[0-9]{2}[a-zA-Z0-9]{1,30}$
type: string
description: Existing IBAN to be used as the source of the transfer. Can be the main IBAN of an account or a virtual IBAN. Note that when you perform a transfer between your own accounts, you can't use a virtual IBAN.
example: FR6430003000509825397888D64
type_strategy:
type: string
description: Determines whether to use an instant transfer (available in a few seconds on the beneficiary account), or a standard transfer (1-3 business days). By default, use an instant transfer if available for the given beneficiary, use a standard transfer otherwise.
default: instant_if_available
enum:
- standard_only
- instant_only
- instant_if_available
- rtgs_only
scheduled_date:
type: string
description: The ISO8601 formatted date on which the transfer will be executed. This date must not be in the past. If not set, the transfer is executed immediately. Setting this date is incompatible with `instant_only` and `instant_if_available` strategies.
format: date
example: 2022-12-05
message:
maxLength: 140
minLength: 1
type: string
description: Message attached to this transfer, visible to all involved parties.
example: invoice no12345
end_to_end_id:
maxLength: 35
minLength: 1
pattern: '[a-zA-Z0-9\-\?\:\(\)\.\,\''\+\ ]{1,35}'
type: string
description: Unique identification to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. It can be used for reconciliation or to link tasks relating to the transaction.
example: b0bfb42baa2642c2af0ca3e880fcd590
internal_note:
maxLength: 3000
minLength: 1
type: string
description: Internal note attached to this transfer, visible only in your Memo Bank workspace.
example: phone bill
custom_id:
maxLength: 256
minLength: 1
type: string
description: Custom identifier that will be attached to the transaction resulting from this transfer. It will not be transmitted nor visible in your Memo Bank workspace. It can only be retrieved or used to search for transactions via Memo Bank API.
example: 637406efda8534de8c0e
custom_metadata:
maxLength: 2048
minLength: 1
type: string
description: Custom metadata that will be attached to the transaction resulting from this transfer. It will not be transmitted nor visible in your Memo Bank workspace and can only be retrieved via API.
example: This is some metadata
TransferV2:
required:
- amount
- beneficiary_iban
- currency
- id
- local_iban
- reference
- status
- type_strategy
type: object
properties:
id:
type: string
description: ID of the transfer
format: uuid
example: 61b05c4f-3f72-4951-8c30-a2a9faaa5184
reference:
type: string
description: Unique reference, can be used to correlate with the resulting Transaction.
format: uuid
example: ab004cfc-99fb-4ba9-bc9c-70982f853cb1
amount:
type: integer
description: Amount of the transfer, in cents.
format: int64
example: 500
currency:
type: string
description: Currency of the amount, in ISO 4217 format.
example: EUR
local_iban:
type: string
description: IBAN used as a source of the transfer. It can be the main IBAN of an account or a virtual IBAN.
example: FR6430003000509825397888D64
account_id:
type: string
description: ID of the account this transfer belongs to, it can be missing while we process it according to the local IBAN.
format: uuid
example: 708683cb-60f6-464a-a62f-be2e339c34aa
beneficiary_iban:
type: string
description: IBAN of the beneficiary.
example: FR2512739000308553756377J95
transfer_type:
type: string
description: Type of the transfer. If the type strategy is `instant_if_available`, it can be missing while we determine the appropriate type.
enum:
- standard
- instant
type_strategy:
type: string
description: Strategy used when creating the transfer.
enum:
- standard_only
- instant_only
- instant_if_available
- rtgs_only
status:
type: string
description: Current status of the transfer.
example: failed
enum:
- pending
- scheduled
- authorized
- confirmed
- returned
- canceled
- failed
failure_code:
type: string
description: "Code that represents the failure reason when the transfer has failed:\n- `beneficiary_bank_account_closed`: The beneficiary's bank account is closed.\n- `beneficiary_bank_error`: The beneficiary's bank sent us an error.\n- `beneficiary_bank_invalid_bank_details`: The beneficiary's bank account does not exist or no longer exists.\n- `beneficiary_bank_refusal`: The beneficiary's bank has refused the transfer.\n- `intermediary_system_error`: The interbank network sent us an error.\n- `memo_error`: Something went wrong on our side.\n- `memo_refusal`: We had to reject the transfer.\n- `execution_failure`: Other or undefined pre-settlement execution failures.\n\nThe following codes can only be present on transfers initiated as part of a bulk. \nWhen initiating a single transfer, those codes will be returned as an error response \nand the transfer won’t be created at all:\n- `current_account_not_found`: The provided local IBAN does not exist.\n- `instant_transfer_not_available`: The beneficiary can not receive instant transfers.\n- `insufficient_funds`: Not enough funds on your account to execute the transfer.\n- `invalid_beneficiary_iban`: The beneficiary's IBAN is invalid.\n- `maximum_amount_exceeded`: The transfer amount exceeds the limit.\n- `missing_new_beneficiary_name`: The beneficiary does not exist and the name was not provided.\n- `new_beneficiary_is_owned_iban`: The beneficiary does not exist and is one of your IBAN.\n- `transfer_to_same_account`: The transfer cannot credit the debtor account.\n- `transfer_to_owned_account_with_virtual_iban`: A virtual IBAN cannot be used to transfer between your accounts.\n- `transfer_from_saving_account_to_external_beneficiary`: You cannot transfer money to external beneficiaries from \nthe Booster account.\n- `unreachable_beneficiary_iban`: The beneficiary is unreachable for the given transfer type.\n"
enum:
- insufficient_funds
- execution_failure
- instant_transfer_not_available
- invalid_currency_for_account
- account_does_not_support_network
- invalid_beneficiary_iban
- unreachable_beneficiary_iban
- maximum_amount_exceeded
- current_account_not_found
- transfer_to_same_account
- transfer_to_owned_account_with_virtual_iban
- transfer_from_saving_account_to_external_beneficiary
- missing_new_beneficiary_name
- missing_beneficiary_address
- new_beneficiary_is_owned_iban
- beneficiary_bank_account_closed
- beneficiary_bank_error
- beneficiary_bank_invalid_bank_details
- beneficiary_bank_refusal
- intermediary_system_error
- memo_error
- memo_refusal
scheduled_date:
type: string
description: Date on which the transfer was scheduled, if any.
format: date
message:
type: string
description: Message attached to this transfer, visible to all involved parties.
example: invoice no12345
end_to_end_id:
type: string
description: Unique identification to unambiguously identify the transaction. This identification is passed on, unchanged, throughout the entire end-to-end chain. It can be used for reconciliation or to link tasks relating to the transaction.
example: b0bfb42baa2642c2af0ca3e880fcd590
internal_note:
type: string
description: Internal note attached to this transfer, visible only in your Memo Bank workspace.
example: phone bill
custom_id:
type: string
description: Custom identifier attached to the transaction resulting from this transfer. It is not transmitted nor visible in your Memo Bank workspace. It can only be retrieved or used to search for transactions via Memo Bank API.
example: 637406efda8534de8c0e
custom_metadata:
type: string
description: Custom metadata attached to the transaction resulting from this transfer. It is not transmitted nor visible in your Memo Bank workspace and can only be retrieved via API.
example: This is some metadata
return_transaction_id:
type: string
description: If the transfer is returned, ID of the corresponding credit transaction..
format: uuid
example: c285420d-ab85-400c-8d03-c8fab5ca37d2
x-topics:
- title: Getting started
content: 'To get started with our Premium Bank API, talk to your banker first. He or she needs to activate the API feature on your Memo Bank workspace.
Once your banker has granted you API access, you can then set up your authentication using our web interface. To do so, navigate to the [`API`](https://client.memo.bank/api) section of your Memo Bank workspace.
Owners and administrators can create applications and manage their permissions. They can also invite collaborators to an application, allowing them to manage certificates, IP allow-lists, and webhooks.
Once an application and a certificate have been created, you will have three pieces of information allowing you to authenticate requests on the API:
1. a **certificate** and its SHA256 thumbprint;
2. a **secret code**;
3. a cryptographic **private key**.
'
- title: Authentication
content: "Our authentication is based on JSON Web Token ([JWT](https://datatracker.ietf.org/doc/html/rfc7519)) and JSON Web Signature ([JWS](https://datatracker.ietf.org/doc/html/rfc7515)).\n\nRegardless of which programming language you are using, there should be [a library](https://jwt.io/libraries) to handle the cryptographic part for you. All you need is to provide the correct header and payload claims. \n\n**In the JWT header:**\n- `alg` must be `RS256`, as we require an RSA-SHA256 signature. \n- `typ` must be `JWT`.\n- `x5t#S256` is the SHA256 thumbprint of the certificate, which you can find in the user interface.\n\n**In the JWT payload:**\n- `sub` must be the request method, followed by a space and the full path, including query parameters.\n- `aud` must be the domain to which you are making the request, e.g., `api.memo.bank`.\n- `iat` must be the timestamp at which you created the token. Note that we accept only a 5-second difference from the server time to mitigate clock skew.\n- `jti` must be a unique identifier for the token. It must be different for each request and follow the UUID format.\n- `sec` must be the secret information you obtained during the setup process in the user interface. This is a custom claim not covered by the JWT specification.\n- `dig#S256` must contain the base64url-encoded SHA-256 hash of the body (`base64url(sha256(body))`, see [`base64url`](https://datatracker.ietf.org/doc/html/rfc7515#appendix-C)). It must be provided only if the request has a body; for example, it is not necessary for `GET` requests. This is a custom claim not covered by the JWT specification.\n\nThe JWT must then be **signed with the private key** you generated during the setup (see [Getting started](#topic-getting-started)), and included in the HTTP headers of the request, as a standard bearer token `Authorization: Bearer <token>`.\n"
example: "_Example JWT header and payload_\n```json\n{\n \"alg\": \"RS256\",\n \"typ\": \"JWT\",\n \"x5t#S256\": \"3A14ZcxIaasp4RHaYReL7wevm3oDzn7ZqmgqScCMY74\"\n}\n{\n \"sub\": \"POST /v1/transfers\",\n \"aud\": \"api.memo.bank\",\n \"iat\": 1657055009,\n \"jti\": \"5525620b-9dcd-4562-8c6c-60984f46cb48\",\n \"sec\": \"a2029d646c94406d2945b7a2b31e4fb3ff09a6d0ae29144380775b5471c4e846\",\n \"dig#S256\": \"lW6N_kO2gPMsMkzXyn028gWwrnaN0kJaiy7FMJcR0Ek\"\n}\n```\n"
- title: Idempotent requests
content: "Our Premium Bank API supports **idempotency** to safely retry requests without accidentally performing the same operation twice. This is useful when an API call is disrupted in transit and you do not receive a response. For example, if a request to create a transfer does not go through due to a network connection error, you can retry the request with the same idempotency key to guarantee that only the single transfer originally attempted is created.\n\nTo perform an idempotent request, provide an additional `Idempotency-Key` **request header**. We recommend using a **V4 UUID**. If the API call fails with a network error or responds with a `5XX`, `409`, or `429` status code, we expect the caller to perform retries with the same `Idempotency-Key` header until it responds differently. For any other response code, especially other `4XX` errors, there is no point in attempting retries, as we will always return the same result. \n\nWhen a previous response is replayed, the response includes an additional HTTP header: `Idempotent-Replayed: true`.\n\nIf an original request is still being processed when an idempotency key is reused, the API will return a `409 Conflict` error (which is safe to retry).\n\nSubsequent requests must be identical to the original request, or the API will return a `422 Unprocessable Entity` error. We do not support setting an idempotency key on `GET` and `DELETE` requests, as these requests are inherently idempotent.\n"
example: "```\ncurl --request POST \\\n --url https://api.memo.bank/v1/transfers \\\n --header 'Authorization: Bearer ***' \\\n --header 'Idempotency-Key: 19b390d1-e7d4-4e27-abe2-49cac9b41ba1' \\\n --header 'Content-Type: application/json' \\\n --data '{...}'\n```\n"
- title: Errors
content: 'Our Premium Bank API uses standard HTTP response codes to indicate the success or failure of requests. Codes in the `2xx` range indicate success; codes in the `4xx` and `5xx` ranges indicate errors. The format of error messages is unified and can be distinguished by their `code` key. The `message` provides a plain English explanation of the problem.
'
example: "```json\n{\n \"code\": \"error_code\",\n \"message\": \"Example error message.\",\n}\n```\n"
- title: Versioning and backwards compatibility
content: 'Our Premium Bank API is versioned by path (`/v1/...`). When we introduce breaking changes, we will increase this version number. We will, of course, continually make backward-compatible changes without increasing the version number.
Examples of changes we do **not** consider breaking include:
* Adding new API resources.
* Adding new optional request parameters to existing API methods.
* Adding new properties to existing API responses. We will occasionally move response fields in the API and will continue to return the existing field in its previous location while removing it from this documentation.
* Changing the order of properties in existing API responses.
* Changing the length or format of opaque strings, such as object IDs, error messages, and other human-readable strings. Strings that are marked as const or enum in this documentation will not change.
* Adding new `EventType` or `ResourceType` enum values for webhooks.
* Adding new `TransactionSource` enum values for transactions.
'
- title: Rate limiting
content: "We enforce a rate limit on the number of HTTP requests that can be made in a given period. When the limit is reached, our Premium Bank API will return a `429 Too Many Requests` error.\n\nTo allow you to handle this rate limiting programmatically, the following headers are sent with every response: \n- `RateLimit-Limit`: total number of available requests between two quota resets;\n- `RateLimit-Remaining`: number of available requests until the quota is reset;\n- `RateLimit-Reset`: time remaining (in seconds) until the quota is reset.\n"
- title: API recipes
content: 'While our OpenAPI specification provides a comprehensive reference for the Memo Bank API, we''ve created API recipes to give you practical, hands-on guides for common use cases. These recipes offer step-by-step examples to help you quickly integrate and leverage our API. You can find them here: [API Premium - Memo Bank](https://aide.memo.bank/category/349-api)
'
- title: FAQ
content: '### How do transactions differ from transfers and collections?
Transfers and collections are types of transactions that you can initiate through the API. They have dedicated endpoint resources to help you follow their detailed lifecycle. On the other hand, transactions allow you to follow the lifecycle of all transactions, including those not initiated through the API (incoming transactions, card transactions, etc). Since transfers and collections are a subset of transactions, some webhook events will be triggered simultaneously (for instance, `transfer_confirmed` and `transaction_confirmed`), and you can use either.
### Is creating a beneficiary or mandate mandatory before initiating transactions?
Creating a beneficiary for transfers or a mandate for collections is not mandatory. When initiating a new transfer or collection, you will provide the counterpart data directly in the initiating endpoint, We will auto-create it, and you will be able to see it in the interface. For subsequent transfers/collections, you will continue to provide the counterpart data, and we will match it with any existing beneficiary/mandate in the interface.
### How can I reconcile a return with its original transfer or collection?
The events `transfer_returned` and `collection_returned` received via webhook will inform you if a return occurred on either a transfer or a collection. The `resource_id` in those events refers to the ID of the original transfer/collection. The `return_transaction_id` field on those resources will reference the return transaction, which is a new transaction typically with the same amount and opposite direction compared to the original transaction. This new transaction will itself trigger a `transaction_confirmed` webhook event. For such transactions, if you call [get the transaction](https://docs.api.memo.bank/operation/operation-gettransaction) and check the [source type](https://docs.api.memo.bank/operation/operation-gettransaction#operation-gettransaction-200-body-application-json-source-type), it will either be `transfer_outgoing_return` or `collection_outgoing_return`. The `returned_collection_id`/`returned_transfer_id` field will contain the ID of your original collection/transfer that has been returned.
### How can I differentiate transaction types?
To differentiate transaction types, you can use the [type](https://docs.api.memo.bank/operation/operation-gettransaction#operation-gettransaction-200-body-application-json-source-type) contained in the [source](https://docs.api.memo.bank/operation/operation-gettransaction#operation-gettransaction-200-body-application-json-source) object.
### How do I express amounts for different currencies?
Amounts are always integers expressed in the smallest unit of their currency. When you [create a wire t
# --- truncated at 32 KB (35 KB total) ---
# Full source: https://raw.githubusercontent.com/api-evangelist/memo-bank/refs/heads/main/openapi/memo-bank-transfers-api-openapi.yml