Yapily
Keep Yapily in step with your orders, invoices and payments without re-keying, with the right person approving what changes.
15 ways to read.
Quality checks
Built and tested with example responses.
- Ready to connect: doneEvery listed action is built in.
- Built and tested with example responses: doneEach action is built from the provider’s published API and tested against example responses, errors, rate limits and paging.
Connected, approved, proven.
The things teams do most with Yapily, an example flow with a person in the loop, and what Nexra keeps as proof.
Top actions
- Get account balances
account_balances.getRead
Example flow
- Yapily · Get account balances
account_balances.getDone - Nexra · Record the decision and result in the evidence chainProven
Example workflow. Routine runs go through on their own. Only a change your rules flag, such as one over a limit you set, waits for the right person, who sees the exact change and the rule before it reaches Yapily.
What gets logged
- Whether it ran on its own or who approved it, and under which rule
- A fingerprint of the exact request sent to Yapily
- Yapily's reply: what it created or changed
- One entry in the evidence chain, linked to the one before
Try this in the sandbox
Run the whole flow with test data in your sandbox, then connect a Yapily test account before you go live.
For developers
Technical detail
Yapily: institutions, consents, consented accounts, balances, transactions, beneficiaries, direct debits, periodic and scheduled payments, statements and payment status.
Yapily API docs- Source actions
- 15
- Data types
- 11
What you can map
Reads are always available. Writes are off until you switch them on for a connection, and governed writes follow your policies.
account balances1
- Get account balancesSource
Read the main balance and every balance type the bank reports for one account.
accounts2
- Get consented accountSource
Read one account with its balances.
- List consented accountsSource
Read account type, currency and balances; omit account numbers and account-holder names.
beneficiaries1
- List account beneficiariesSource
Read saved payees of one account; payee account numbers and addresses are omitted.
consents2
- Get consentSource
Read one consent's status, scope and expiry; the consent token is never returned.
- List consentsSourceIncremental
Read consents in your application, optionally for one user, institution or status. Consent tokens are never returned.
direct debits1
- List direct debitsSource
Read direct debits set up on one account.
institutions2
- Get institutionSource
Read one institution's countries, credentials type and features.
- List institutionsSource
Read the banks enabled for your Yapily application with their features.
payments1
- Get payment statusSource
Read the status of a payment initiated elsewhere under this consent.
periodic payments1
- List periodic paymentsSource
Read standing orders (periodic payments) on one account.
scheduled payments1
- List scheduled paymentsSource
Read future-dated one-off payments on one account.
statements2
- Get account statementSource
Read one statement's period; the PDF file is not downloaded.
- List account statementsSource
Read statement periods available for one account.
transactions1
- List account transactionsSource
Read consented account transactions with offset pagination.
Access and limits
- Authentication
- Application ID/secret plus authorised consent token
- Plans and access
- A Yapily application (ID and secret) with the institutions you use enabled, and an authorised account consent token per connection. Each read needs the matching institution feature (for example ACCOUNT_TRANSACTIONS, ACCOUNT_DIRECT_DEBITS, ACCOUNT_STATEMENTS). UK consents need reconfirming every 90 days.
- Test environment
- Use sandbox institutions such as Modelo Sandbox in your Yapily application.
- Rate limits
- Yapily and the banks apply limits (banks often allow four unattended reads per day under PSD2); HTTP 429 and Retry-After are honoured with bounded retries.
- Pagination
- Transactions, statements and consents use offset and limit (max 1000) with meta.pagination.totalCount; other reads return one page.
- Provider events
- Yapily sends consent and payment status webhooks configured in the Console. Flows run on demand, on a schedule, or when a scheduled check finds new or changed records.
Before you build a flow
- Intentional exclusions: payment creation and authorisation, bulk payments, VRP consents and payments, funds confirmation, beneficiary creation, consent creation, extension, re-authorisation and deletion, user deletion, Data Plus categorisation and the identity endpoint.
- Account numbers, IBANs, payer and payee account identifiers, addresses and consent tokens are never mapped.
- Consent acquisition and reconfirmation happen in your app through Yapily's authorisation flow; each connection uses one consent token.
- Statement files (PDF) are not downloaded.
Developer reference
- Create the Yapily credentials described above with the narrowest permissions your flows need.
- In Nexra, open Connect, then Connections, then New connection, choose Yapily, enter its settings and credentials, and tick only the write actions you need. Connection guide
- Test the connection, then use its actions as flow sources and destinations. Flow guide
Machine-readable detail: GET /api/public/connect/connectors/yapily and the Connections API.