---
title: "List operational payments"
method: GET
path: "/operational_payments"
tags: ["Operational Payments"]
---

# List operational payments

`GET /operational_payments`

Returns a list of operational payments. Operational payments are payments that you expect to occur in your bank account that were executed through Shinkansen Network via Payouts or Payin Notification.

## Response `200`

List of operational payments

- OperationalPayments — List of operational payments
  - `operational_payments` OperationalPayment[], required — A list of operational payments
    - `operation_id` string, required — UUID Unique identifier for the operational payment.
    - `source_id` string, required — UUID Unique identifier of the source from Shinkansen Network that generated the expected payment. Combined with the source type, it must be unique.
    - `source_type` 'shinkansen_payout' | 'shinkansen_payin_notification', required — The type of source. Can be one of: - `payout`: The expected payment was generated by a payout transaction over Shinkansen network. - `payin_notification`: The expected payment was generated by a payin notification. Either payin or payin_reversal types.
    - `currency` string, required — Currency ISO 4217 code (e.g: `"CLP"`)
    - `amount` string, required — Amount, ISO20022-compatible: Up to 18 integer digits, optional decimal separator ".", up to 5 fraction digits (also optional). By using a string we avoid issues with floating-point arithmetic as well as integer type limits on some JSON implementations.
    - `timestamp` string, date-time, required — The execution time of the operation on Shinkansen Network.
    - `status` 'unreconciled' | 'reconciled' | 'partially_reconciled' | 'archived', required — The status of the operation payment. Can be one of: - `unreconciled`: We don't have information from bank institutions about this operation. - `reconciled`: This payment operation is associated with one or more movements from the bank. - `partially_reconciled`: This payment operation is associated with one or more movements from the bank but has not fulfill Bot criteria. There are cases that might end up like this: 2 pending payouts for $N amount on the same batch and then a -2*$N entry followed by a +N entry. We can't decide which of the 2 payouts correspond to the reversal so both would be partially reconciled and manual action would be needed to reconcile and fix up the status of both payouts. - `archived`: This payment operation was rejected by bank and did not appear in any statement.
    - `reconciliation_method` 'manual' | 'automatic' | 'none', required — The reconciliation method used for this operational payment. Can be one of: - `manual`: This payment operation was reconciled manually by the user through the UI. - `automatic`: This payment operation was reconciled automatically by Shinkansen Treasury Bot. - `none`: This payment operation has not been reconciled.
    - `entries` string[], required — List of entries ids for all entries related to this operational payment. Can be empty or not present if no entries were created/matched for this operational payment.

## Other responses

- `403` — Forbidden (e.g: wrong API Key)
- `404` — Account not found.

---

[API](https://skmtc.net/shinkansen/apis/payouts-shinkansen-endpoints.md) · [All operations](https://skmtc.net/shinkansen/apis/payouts-shinkansen-endpoints/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/shinkansen/payouts-shinkansen-endpoints/versions/1e4a6760b7e8/schema)