Sintropix Bank Feeds API: Feed Bank Accounts from an Integration

A bank feed reads the movements of one account at a Provider and lands them on a Bank Account. The feed reads through an Integration: the grant your Organization connected for that Provider. An Integration can discover one or more accounts at its Provider, and you map each one to an existing Bank Account or use it to create a new one, in any Entity of the Organization. One bank login can feed a Bank Account in each of several Entities. These Integration kinds can feed a Bank Account:

Kind	Provider	What it discovers
`fintoc`	A bank, through the Fintoc widget	Every account the bank login reaches
`plaid`	A US bank, through Plaid Link	The bank login’s depository and credit accounts. See Plaid
`global66`	Global66	Every active wallet of the Global66 client. See Global66
`cardda`	Cardda	The company’s one CLP wallet
`dlocal`	dLocal Go	The merchant’s one balance
`mercadopago`	Mercado Pago	The account’s available money
`polar`	Polar	The USD balance of each organization the Polar user can read. See Polar
`stripe`	Stripe	One account per currency of the Stripe account’s balance, such as `Stripe USD`. See Stripe

To connect, reconnect, or disconnect one of these Integrations, see Integrations. Any other Integration kind answers every route on this page with 422 and INTEGRATION_BANK_FEED_NOT_SUPPORTED_ERROR. The route that reads the Integration’s accounts lives under the Organization, at /api/organizations/:organizationId/integrations/:integrationId/discovered-accounts. The routes that feed a Bank Account live under the Entity the Bank Account belongs to, at /api/entities/:entityId/integrations/:integrationId, and take an Integration of that Entity’s Organization. An Integration of another Organization answers 404 with INTEGRATION_NOT_FOUND_ERROR. Path parameters are UUIDs.

Open in the app. This resource has a page in the Sintropix web app at https://app.sintropix.com/organizations/{organizationId}/settings/integrations, where each id in braces is the same UUID as in the API route or response. When you mention a record to a user, include that link. See Link to the App for the full URL grammar.

Authentication

Use a session cookie or an API key via the x-api-key header. Mutations with an API key also require x-audit-actor. See Get an API Key.

Get discovered accounts

GET /api/organizations/:organizationId/integrations/:integrationId/discovered-accounts Read the live account panel for one Integration. This fetches the Provider’s current status, the discovered accounts, and, for each Entity of the Organization, the local Bank Accounts and Ledger Accounts you can map to. An API key confined to one Entity gets its own Entity as the one entry of entities, and doesn’t see an account that already feeds a Bank Account of another Entity.

Response

Field	Type	Description
`status`	`active`, `inactive`, or `login_required`	Provider’s judgment of the grant. `login_required` means the institution rejected the stored grant and you must reconnect
`accounts`	`array`	Accounts the Provider discovered (see below)
`entities`	`array`	Every Entity of the Organization a discovered account can feed, in name order (see below)
`refreshing`	`boolean \| null`	`true` while the Provider is still refreshing the grant, `false` when every refresh has finished, `null` when the refresh state could not be read

Each element of accounts carries:

Field	Type	Description
`providerAccountId`	`string`	Provider’s opaque handle for the account
`name`	`string`	Account name as the institution reports it
`number`	`string`	Account number as the institution reports it
`type`	`string`	Provider-defined account type, display only
`currency`	`string`	ISO 4217 code
`balance.current`	`integer`	Current balance in minor units of `currency`
`balance.available`	`integer \| null`	Available balance in minor units; null when the institution does not report it
`balance.limit`	`integer \| null`	Credit limit in minor units; null when the institution does not report it
`refreshedAt`	`ISO datetime \| null`	When the Provider last refreshed this account
`fedBankAccount`	`object \| null`	The Bank Account this account already feeds, as `{ id, name, entityId }`, or null

Each element of entities carries:

Field	Type	Description
`id`	`uuid`	The Entity
`name`	`string`	The Entity’s name
`mappableBankAccounts`	`array`	The Entity’s Bank Accounts that can still take a feed. Each carries `id` (`uuid`), `name` (`string`), and `currency` (`string`)
`ledgerAccounts`	`array`	The Entity’s Cash Accounts, the asset Ledger Accounts with the Cash sub-type, eligible for mapped creation. Each carries `id` (`uuid`), `code` (`string`), and `name` (`string`)

{
  "status": "active",
  "accounts": [
    {
      "providerAccountId": "acc_123",
      "name": "Cuenta Corriente",
      "number": "000123456789",
      "type": "checking_account",
      "currency": "CLP",
      "balance": { "available": 1250000, "current": 1250000, "limit": null },
      "refreshedAt": "2026-02-01T12:00:00.000Z",
      "fedBankAccount": null
    }
  ],
  "entities": [
    {
      "id": "8b0a7d5e-6a3c-4f2b-9e1d-2c4b6a8f0e21",
      "name": "Acme SpA",
      "mappableBankAccounts": [
        { "id": "0192a8b4-0000-7000-8000-000000000002", "name": "Primary Checking", "currency": "CLP" }
      ],
      "ledgerAccounts": [
        { "id": "0192a8b4-0000-7000-8000-000000000004", "code": "1102", "name": "Banco" }
      ]
    }
  ],
  "refreshing": false
}

curl https://api.sintropix.com/api/organizations/$ORGANIZATION_ID/integrations/$INTEGRATION_ID/discovered-accounts \
  -H "x-api-key: $SINTROPIX_API_KEY"

Map a discovered account to an existing Bank Account

POST /api/entities/:entityId/integrations/:integrationId/bank-account-feeds Create a feed that attaches a discovered account to an existing Bank Account of the Entity in the path. The server derives the currency from the Provider and rejects a mismatch. The first sync runs before the server answers, so the request can take a while. For Mercado Pago it usually takes about a minute.

Request body

Field	Type	Required	Description
`bankAccountId`	`uuid`	Yes	Local Bank Account to feed
`providerAccountId`	`string`	Yes	Provider’s opaque handle for the account
`feedStartDate`	`ISO date`	Yes	Day the feed begins, for every Provider. Any past day or today, on the calendar of Santiago (Chile). A future day is refused. The Bank Account must already hold every row before this day, and the sync loads Provider movements from this day on

Response

The Bank Account that now carries the feed, with feed populated. The shape is the one documented on the Bank Accounts page, without the balance and unreconciledCount summary fields.

curl -X POST https://api.sintropix.com/api/entities/$ENTITY_ID/integrations/$INTEGRATION_ID/bank-account-feeds \
  -H "Content-Type: application/json" \
  -H "x-api-key: $SINTROPIX_API_KEY" \
  -H "x-audit-actor: my-agent" \
  -d '{
    "bankAccountId": "0192a8b4-0000-7000-8000-000000000002",
    "providerAccountId": "acc_123",
    "feedStartDate": "2026-09-01"
  }'

Refusals

The endpoint returns 400 Bad Request with a body of { "code": "<code>", "params": { ... } } in these cases:

Code	When it happens
`BANK_FEED_START_DATE_IN_FUTURE_ERROR`	`feedStartDate` is after today on the calendar of Santiago (Chile). `params` carries `feedStartDate` and `today`. Retry with a `feedStartDate` on or before `today`
`BANK_FEED_START_DATE_AFTER_PENDING_MOVEMENT_ERROR`	`feedStartDate` is after the oldest pending hold at the Provider, such as an open Cardda hold. A feed that starts later would never land the hold once the Provider approves it. `params` carries `feedStartDate` and `earliestPendingDate`. Retry with a `feedStartDate` on or before `earliestPendingDate`

The map also refuses these cases, each with the same coded body:

Status	Code	When it happens
`404`	`DISCOVERED_ACCOUNT_NOT_FOUND_ERROR`	`providerAccountId` isn’t one of the Integration’s discovered accounts
`409`	`BANK_FEED_PROVIDER_REFRESHING_ERROR`	The Provider is still refreshing the account. Retry when `refreshing` is `false`
`409`	`BANK_FEED_PROVIDER_HAS_NO_DATA_ERROR`	The Provider hasn’t read the account yet
`409`	`BANK_FEED_CURRENCY_MISMATCH_ERROR`	The Bank Account’s currency differs from the discovered account’s
`409`	`BANK_FEED_OPENING_BALANCE_MISMATCH_ERROR`	The Bank Account’s balance doesn’t equal the Provider’s balance at the start of `feedStartDate`. The Bank Account must hold every row before that day
`409`	`BANK_ACCOUNT_ALREADY_FED_ERROR`	The Bank Account already has a feed
`409`	`DISCOVERED_ACCOUNT_ALREADY_FED_ERROR`	The discovered account already feeds a Bank Account
`409`	`BANK_FEED_MAP_RACED_ERROR`	The Provider’s account changed while the map read it. Retry
`422`	`BANK_ACCOUNT_IS_CARD_ERROR`	The Bank Account is a `card`. Only a `bank` account takes a feed
`422`	`DISCOVERED_ACCOUNT_IS_CARD_ERROR`	The discovered account is a card account

Create a Bank Account from a discovered account

POST /api/entities/:entityId/integrations/:integrationId/bank-accounts Create a new Bank Account in the Entity in the path, and feed it from a discovered account, in one operation. The creation is always kind bank, so only a Cash Account (an asset Ledger Account with the Cash sub-type) is accepted. Like the map, the first sync runs before the server answers.

Request body

Field	Type	Required	Description
`id`	`uuid`	Yes	Client-supplied id for idempotency
`name`	`string`	Yes	Display name
`ledgerAccountId`	`uuid`	Yes	Cash Account to map
`providerAccountId`	`string`	Yes	Provider’s opaque handle
`feedStartDate`	`ISO date`	Yes	Day the feed begins. Any past day or today, on the calendar of Santiago (Chile). A future day is refused

Response

The created Bank Account with its balance and unreconciledCount summary, in the same shape as the list response on the Bank Accounts page, plus one field:

Field	Type	Description
`shortHistory`	`object \| null`	Set when the Bank Account has a short history. `null` otherwise
`shortHistory.oldestServedDate`	`ISO date \| null`	The oldest day on or after `feedStartDate` with a movement the Provider served. `null` when the Provider served no movement since `feedStartDate`

curl -X POST https://api.sintropix.com/api/entities/$ENTITY_ID/integrations/$INTEGRATION_ID/bank-accounts \
  -H "Content-Type: application/json" \
  -H "x-api-key: $SINTROPIX_API_KEY" \
  -H "x-audit-actor: my-agent" \
  -d '{
    "id": "0192a8b4-0000-7000-8000-000000000003",
    "name": "Banco Principal",
    "ledgerAccountId": "0192a8b4-0000-7000-8000-000000000004",
    "providerAccountId": "acc_123",
    "feedStartDate": "2026-09-01"
  }'

Short history

The feed lands the account’s balance on feedStartDate as an opening balance, and loads the Provider’s movements from that day on. Some Providers don’t keep a long history. When the Provider can’t show that its history reaches feedStartDate, any movement between feedStartDate and the oldest movement it served is missing, and its amount sits inside the opening balance. Sintropix still creates the Bank Account, and tells you once in shortHistory. Nothing stores it, so a later read of the Bank Account doesn’t carry it. shortHistory stays null when:

The Provider holds a movement before feedStartDate, or states the balance on that day. A quiet period after the start doesn’t count as a short history.
The opening balance is 0, such as for an account opened after feedStartDate.

{
  "id": "0192a8b4-0000-7000-8000-000000000003",
  "name": "Banco Principal",
  "shortHistory": { "oldestServedDate": "2026-09-18" }
}

In this example, the Provider served movements only from September 18. Any movement from September 1 to that day is inside the opening balance. Mapping a discovered account to an existing Bank Account never answers shortHistory: that Bank Account already holds every row before feedStartDate.

Refusals

The endpoint refuses the same feedStartDate cases as the map: 400 with BANK_FEED_START_DATE_IN_FUTURE_ERROR or BANK_FEED_START_DATE_AFTER_PENDING_MOVEMENT_ERROR. It also refuses the map’s cases about the discovered account (DISCOVERED_ACCOUNT_NOT_FOUND_ERROR, BANK_FEED_PROVIDER_REFRESHING_ERROR, BANK_FEED_PROVIDER_HAS_NO_DATA_ERROR, DISCOVERED_ACCOUNT_ALREADY_FED_ERROR, BANK_FEED_MAP_RACED_ERROR, and DISCOVERED_ACCOUNT_IS_CARD_ERROR), and the cases of creating a Bank Account, such as an id that already exists. To stop a feed or sync it on demand, use the feed routes on the Bank Accounts page. To check whether a feed’s Movements add up to the Provider’s balance, read its tie-out. To stop every feed of an Integration at once, disconnect the Integration.

What each Provider lands

Cardda

Cardda is a prepaid wallet and card provider. The company holds one CLP wallet, and every card movement lands on that wallet.

Only approved rows that affect the balance land as Movements. Pending rows, declined rows, and rows that do not affect the balance stay out of the books.
The reported balance is the wallet amount minus the pending holds that affect the balance.
The Movement date is the transaction’s authorized_at, or created_at when authorized_at is absent. Sintropix reads that timestamp as the calendar day in Santiago (Chile).
A Movement that landed stays when Cardda later declines its transaction. It isn’t a restatement: the sync still lands, and the account goes out of tie-out by its amount.

dLocal Go

dLocal Go is a payment processor that reports payments and settlements. The feed lands those as inflows and outflows on the mapped Bank Account.

A paid payment lands as an inflow. It joins the feed by the day dLocal Go created it: a payment created on or after the feed start date lands, and one created before it belongs in the opening balance, even when dLocal Go paid it later.
The payment’s Movement date is the day dLocal Go approved it. If dLocal Go later changes that date, the Movement keeps the day it first landed on, and the payment never lands a second time.
A completed settlement lands as an outflow, dated and joined by the day dLocal Go paid it.
A payment that landed stays when dLocal Go later rejects it. It isn’t a restatement: the sync still lands, and the account goes out of tie-out by its amount.
The feed start date must be on or before the creation day of the oldest payment that is still open. A later date is refused with BANK_FEED_START_DATE_AFTER_PENDING_MOVEMENT_ERROR, and earliestPendingDate is that creation day.

Fintoc

A Fintoc feed reads a bank account through the bank login you connected with the Fintoc widget.

Only posted movements land. A movement the bank still shows as pending, such as a deposited check that hasn’t cleared, lands on the first sync after Fintoc serves it as posted. If it never posts, for example a check that bounces, it never lands.
The bank’s balance already counts a pending movement. Each sync leaves pending movements out of the balance it checks against, so a pending check doesn’t put the account out of tie-out.
When you create a Bank Account from a Fintoc account, the opening balance leaves out the movements pending on that day too. Each lands once, when it posts.
The discovered account’s balance.current is the bank’s balance as Fintoc reports it, pending movements included.
Some banks complete a movement’s text after it lands. For example, BCI first serves Pago Recibido and, a day later, Pago Recibido PRV <RUT> <bank> for the same movement. The next sync writes the newer text into the Movement’s description, even when the Movement is already booked. See Sync a bank account feed.
Some banks serve a movement’s text percent-encoded, such as Traspaso Internet a T. Cr%C3%A9dito or Impuesto Sobregiro %2F Uso LCA. Sintropix decodes it, so the description reads Traspaso Internet a T. Crédito and Impuesto Sobregiro / Uso LCA. A % that doesn’t start a valid encoded character, as in 100% cubierto, stays as the bank sent it.

Global66

A Global66 Integration reads the wallets of the Global66 client you connected. Each wallet holds one currency, and a client can hold more than one wallet in the same currency. Map the wallets your books need. You don’t have to map every wallet. Discovered accounts

The Integration discovers every active wallet of the client.
name is the wallet’s alias at Global66, or Global66 followed by the currency, such as Global66 USD, when the wallet has no alias.
providerAccountId and number are both the Global66 wallet id.
A wallet in a currency Sintropix doesn’t know is left out. The other wallets of the client are still listed.
balance.current and balance.available are both the available balance Global66 states for the wallet.

Each sync checks the landed Movements against that same balance, so a wallet’s tie-out compares the Bank Account with the balance Global66 lists.

Mercado Pago

A Mercado Pago feed mirrors the account’s available money. Each sync reads Mercado Pago’s release report, which lists every movement of that money: payments net of fees, purchases paid from the balance, payouts, refunds, credit repayments, and holds.

Each sync covers the days from the feed start date to the end of yesterday, so the feed runs about a day behind.
Each sync can leave a release report in the account’s list of reports in Mercado Pago, marked as manual.
Every row of the report lands as a Movement.
Sintropix refuses a report whose running balance does not chain from one row to the next, and checks the landed Movements against the report’s closing balance.
Before you map the account, the discovered account shows the closing balance of the newest release report. It shows 0 when the account has no release report yet.

The Mercado Pago Integration renews its authorization on its own before a sync reads.

Plaid

A Plaid Integration reads a US bank login through Plaid. Connect it with Plaid Link, then map the accounts you want in your books. You don’t have to map every account: leave out the ones you don’t need, such as a cash sweep account. Discovered accounts

Only depository accounts (such as checking, savings, and money market) and credit accounts are listed. Loan, investment, and other accounts are left out, because Plaid gives them no movements.
An account is also left out when Plaid states no ISO currency for it, when Sintropix doesn’t know its currency, or when its current balance has more decimals than its currency allows. The other accounts of the bank login are still listed.
number is the last four digits of the account number, and type is depository or credit.
A credit account is a card account. Mapping it to a Bank Account is refused with DISCOVERED_ACCOUNT_IS_CARD_ERROR.

Wait for the full history. After you connect, Plaid reads up to 730 days of the bank’s history, which can take a moment. Until it finishes, the discovered accounts answer refreshing: true and a map or Bank Account creation is refused with 409 and BANK_FEED_PROVIDER_REFRESHING_ERROR. Retry when refreshing is false. What lands

Only posted transactions land. A pending transaction never lands. When it posts, it lands as a new Movement on the next sync.
The Movement date is the day the transaction posted, and the description is the transaction name the bank reports. Plaid’s categories are not used.
Money that leaves the account lands as a negative amount, and money that comes in lands as a positive amount.
Each sync checks the landed Movements against the account’s current balance at Plaid, less the pending transactions that balance counts. A pending transaction doesn’t put the account out of tie-out, and feed.tieOut.reportedBalance is the balance after that subtraction.
When you create a Bank Account from a Plaid account, the opening balance leaves out the pending transactions in the same way. Each one lands once, when it posts.

Some banks count pending transactions in the current balance, and others don’t. Sintropix treats the current balance as counting them when Plaid reports the same current and available balance for the account, and then subtracts the sum of every pending transaction, whatever its date. Otherwise it reads the current balance as posted transactions only and subtracts nothing. At a bank that counts pending transactions, a hold that no transaction explains makes the two balances differ. While the hold lasts, the pending transactions aren’t subtracted, and the account can show out of tie-out by their sum. US banks write a wire’s reference numbers into the transaction name. Sintropix shortens the description of a wire to its direction and its counterparty: the sender of a wire in, or the beneficiary of a wire out. The references and the wire’s note (OBI) move to the Movement’s Additional Information. A name that isn’t a wire, or a wire Sintropix can’t read field by field, lands whole, so no text is lost.

Transaction name at the bank	Description	Additional Information
`WIRE IN 260922NWND0047;ORG ACME CAPITAL LP;OBI INV 1001`	`WIRE IN ACME CAPITAL LP`	Referencia de transferencia: `260922NWND0047` Detalle de la transferencia (OBI): `INV 1001`
`WIRE OUT 20262740100;BNF CONTOSO SPA`	`WIRE OUT CONTOSO SPA`	Referencia de transferencia: `20262740100`
`ACH DEBIT GUSTO PAYROLL`	`ACH DEBIT GUSTO PAYROLL`	None

The Additional Information holds these lines, in this order, each only when Plaid states it:

Label	Value
`Referencia de transferencia`	A wire’s reference numbers
`Detalle de la transferencia (OBI)`	A wire’s note
`Fecha de autorización`	The day the transaction was authorized
`Comercio`	The merchant name
`Número de cheque`	The check number
`ID transacción pendiente Plaid`	Plaid’s id for the pending transaction this one replaced

A sync updates the description and these lines on every Movement it landed, booked or not. See Sync a bank account feed.

Feed dates follow the calendar of Santiago (Chile), not US time. A transaction can post late on a US day that is already the next day in Santiago, or post after you map with a date before the feed start date. Such a transaction never lands, but the account’s balance at Plaid counts it, so every later sync leaves the Bank Account out of tie-out by its amount. To fix it, remove the feed and map the account again with a feed start date on or before that transaction.

Errors. When the bank login expires at the bank, a sync answers 424 with BANK_FEED_PROVIDER_UNAUTHORIZED_ERROR. When the bank login was removed at Plaid, it answers 410 with INTEGRATION_GRANT_GONE_ERROR. In both cases, disconnect the Integration and connect it again. Plaid Integrations don’t reconnect.

Polar

Polar is a Merchant of Record: it charges your buyers, holds the money in a USD balance, and pays it out to your bank. A Polar feed mirrors that USD balance, row by row. Who can connect. Polar shows an organization’s money only to its owner, admin, and finance roles. Connect Polar with a user who has one of those roles. When the connected user has another role, such as member, the discovered accounts and every sync answer 424 with BANK_FEED_PROVIDER_ROLE_REFUSED_ERROR and params.integrationKind set to polar. Sintropix never feeds an empty account in that case. Connect Polar again from Configuración → Integraciones with an owner, admin, or finance user.

{
  "code": "BANK_FEED_PROVIDER_ROLE_REFUSED_ERROR",
  "params": { "integrationKind": "polar" }
}

Discovered accounts

The Integration discovers one account per Polar organization the user can read.
name is Polar followed by the organization name, and number is the organization’s slug.
currency is USD, and balance.current and balance.available are both the organization’s Polar balance.

What lands Every row of Polar’s ledger lands as its own Movement: each sale, each refund, each fee, and each payout. A fee doesn’t net against the sale it came from, so you can book it to an expense account.

The Movement date is the day Polar created the row, read in the calendar of Santiago (Chile).
Money that comes into the Polar balance lands as a positive amount, and money that leaves it lands as a negative amount.
A payout lands in USD. The amount your bank received, in its own currency, lands on that bank’s Bank Account through its own feed. Reconcile the two Movements as a transfer.

Row	Description
Sale	The product name, or `Orden` and the order id when Polar no longer names the product
Refund	`Reembolso` and the product name
Fee	The fee type, such as `Comisión de pago`, `Comisión de pago internacional`, `Comisión de suscripción`, `Comisión de transferencia internacional`, `Comisión de payout`, or `Comisión de cuenta`
Payout	`Payout`

The Additional Information holds these lines, in this order, each only when Polar states it:

Label	Value
`Fuente`	Where Sintropix read the row
`ID transacción Polar`	Polar’s id for the row
`Tipo Polar`	The row type at Polar: `balance` or `payout`
`Tipo comisión Polar`	The fee type at Polar, on a fee
`ID orden Polar`	The order of a sale, refund, or fee
`Producto Polar`	The product of that order
`Transacción origen Polar`	The row a fee came from
`Payout Polar`	The payout that paid the row out
`Monto recibido Polar`	On a payout, the amount your bank received, in minor units of its currency
`Moneda recibida Polar`	On a payout, the currency your bank received, such as `CLP`

Balance check. Each sync reads the whole Polar ledger and checks it against the organization’s Polar balance. When the ledger doesn’t add up to the balance, the map, the Bank Account creation, and every sync answer 424 with BANK_FEED_PROVIDER_FAILURE_ERROR, so no made-up opening balance absorbs the gap. A row type, fee type, or currency that Sintropix doesn’t know refuses the sync with the same code. When the landed Movements don’t reach the balance, the sync still lands and leaves the Bank Account out of tie-out. The Polar Integration renews its authorization on its own before a sync reads.

Stripe

Stripe holds the money it collects for you in a balance, one per currency, until it pays it out to your bank. A Stripe feed mirrors one currency of that balance, row by row, from Stripe’s balance transactions. Discovered accounts

The Integration discovers one account per currency of the Stripe balance.
name is Stripe followed by the currency, such as Stripe USD, and number is the Stripe account id (acct_…).
balance.current and balance.available both hold the available and pending funds of that currency together.

What lands Every balance transaction of that currency lands as its own Movement: each charge, refund, payout, fee, and adjustment. Stripe’s own fees (stripe_fee) land as their own Movements, so you can book them to an expense account.

A Movement lands at the transaction’s net amount: the gross minus the fee Stripe took. The gross and the fee stay in its Additional Information.
A transaction lands as soon as Stripe creates it, while its funds are still pending. The Movement date is the day Stripe created it, read in the calendar of Santiago (Chile).
Money that comes into the balance lands as a positive amount, and money that leaves it lands as a negative amount.
A payout lands in the balance currency. The amount your bank received lands on that bank’s Bank Account through its own feed. Reconcile the two Movements as a transfer.
Only the transactions of Stripe’s payments balance land. Transactions of any other Stripe balance, such as Stripe Issuing, never land, and each sync records them as skipped.

The description is Stripe, the transaction type in Spanish, and Stripe’s own description of the transaction when it has one, such as Stripe Cobro: Payment for Invoice:

Type at Stripe	Description
`charge`	`Stripe Cobro`
`payment`	`Stripe Pago`
`refund`, `payment_refund`	`Stripe Reembolso`
`refund_failure`, `payment_failure_refund`	`Stripe Reembolso fallido`
`payout`	`Stripe Retiro`
`payout_cancel`	`Stripe Retiro cancelado`
`payout_failure`	`Stripe Retiro fallido`
`stripe_fee`	`Stripe Comisión`
`stripe_fx_fee`	`Stripe Comisión por conversión`
`tax_fee`	`Stripe Impuesto sobre comisión`
`application_fee`	`Stripe Comisión de aplicación`
`adjustment`	`Stripe Ajuste`
`transfer`	`Stripe Transferencia`
`topup`	`Stripe Recarga`

Any other type keeps Stripe’s own name, such as Stripe dispute. The Additional Information holds these lines, in this order, each only when Stripe states it. The lines of the charge and of the invoice let you match a Movement to its sale and its tax document without opening Stripe.

Label	Value
`Fuente`	Where Sintropix read the transaction
`ID transacción Stripe`	Stripe’s id for the transaction (`txn_…`)
`Tipo Stripe`	The transaction type at Stripe, such as `charge` or `payout`
`Categoría Stripe`	Stripe’s reporting category, such as `charge` or `fee`
`Monto bruto Stripe`	The gross amount, in the balance currency
`Comisión Stripe`	The fee Stripe took, in the balance currency
`Origen Stripe`	The id of the object behind the transaction, such as a charge (`ch_…`), a refund (`re_…`), or a payout (`po_…`)
`Monto original Stripe`	On a charge Stripe converted from another currency, its original amount and currency, such as `CLP 11900`
`Tipo de cambio Stripe`	On a converted transaction, the exchange rate per whole unit of the original currency. The rate times the original amount gives the gross
`Factura Stripe`	The number of the Stripe invoice the charge paid
`Cliente Stripe`	The customer name on that invoice
`ID tributario cliente Stripe`	The customer’s tax ids on that invoice, separated by commas
`Impuesto factura Stripe`	The total tax of that invoice, with its currency, such as `USD 3.19`
`País de facturación Stripe`	The billing country of the charge, such as `CL`
`Titular tarjeta Stripe`	The cardholder’s name on the charge
`Tarjeta Stripe`	The card brand and its last four digits, such as `visa •••• 4242`

The customer on the invoice can differ from the cardholder, for example when a person’s card pays a company’s invoice. A charge of the feed’s first days can land without its invoice lines, because Stripe can record the invoice payment before the feed start date. Each sync rewrites these lines on every Movement it landed, booked Movements included, so a Movement always shows what Stripe states now. Balance check. Each sync reads the balance transactions from the feed start date and checks the landed Movements against the available and pending funds of the currency. When they don’t add up, the sync still lands and leaves the Bank Account out of tie-out. Stripe keeps the account’s whole history, so any feed start date works.

Provider time

Every Movement a feed lands carries a providerTime: the time the Provider states for the row, or null when the Provider gives no time Sintropix can trust. It orders the Movements of one day, and so the running balance within that day. A Movement without one comes before every Movement of its day that has one. See Order of movements.

Provider	`providerTime`
Global66	The time of every row
Stripe	The time Stripe created the balance transaction
Polar	The time Polar created the row
Mercado Pago	The time of every row of the release report
Fintoc	The time of the operation, when the bank states one. A row with no time, or with midnight, gets `null`. The operation can fall days before the Movement date
Plaid	The time of the transaction, when Plaid states one
dLocal Go	The time of the date that gives the Movement its day: the approval or creation time of a payment, and the payment time of a settlement. dLocal Go states it without a time zone, so Sintropix reads it as UTC
Cardda	Bank transfers only, from `authorized_at`, or `created_at` when `authorized_at` is absent. Card, commission, and payment rows get `null`

The time is written once. A sync can give a time to a landed Movement that has none, booked or not, but only while the Provider still dates the row on the Movement’s day. It never changes a time a Movement already holds, so a dLocal Go payment whose approval date changes keeps its first time. Movements that landed before Provider time existed have null until a sync fills it.

Get Started

Ledger

Banking

Documents

Reports & Audit

Sources & Integrations

Platform

Sintropix Bank Feeds API: Feed Bank Accounts from an Integration

Authentication

Get discovered accounts

Response

Map a discovered account to an existing Bank Account

Request body

Response

Refusals

Create a Bank Account from a discovered account

Request body

Response

Short history

Refusals

What each Provider lands

Cardda

dLocal Go

Fintoc

Global66

Mercado Pago

Plaid

Polar

Stripe

Provider time

​Authentication

​Get discovered accounts

​Response

​Map a discovered account to an existing Bank Account

​Request body

​Response

​Refusals

​Create a Bank Account from a discovered account

​Request body

​Response

​Short history

​Refusals

​What each Provider lands

​Cardda

​dLocal Go

​Fintoc

​Global66

​Mercado Pago

​Plaid

​Polar

​Stripe

​Provider time

Authentication

Get discovered accounts

Response

Map a discovered account to an existing Bank Account

Request body

Response

Refusals

Create a Bank Account from a discovered account

Request body

Response

Short history

Refusals

What each Provider lands

Cardda

dLocal Go

Fintoc

Global66

Mercado Pago

Plaid

Polar

Stripe

Provider time