FlowRunner
PricingContact
Theme
Start Free

Darujme.cz

Payments

Darujme.cz is the Czech donation platform non-profits collect through. Agents read pledges and transactions, update pledge custom fields, pull project statistics, and read peer-to-peer fundraising promotions.

Verified 13 actions API key available
Darujme.cz website Platform Documentation Capability data verified 2026-08-25
A scheduled run asks what has changed since the last sync
List Transactions returns everything modified since the last watermark
Agent keeps only the states that actually mean money arrived
Get Pledge resolves each transaction to the donor and their intent behind it
The gift is written to the donor record and the finance ledger
The development team gets the day's arrivals with the recurring failures separated
A person approves the acknowledgment batch before any pledge is stamped as thanked

What This Integration Enables

Darujme.cz is where Czech non-profits collect, and its API rests on a distinction that quietly decides whether your fundraising reporting is true. A pledge is a donor's intention, one record carrying a payment method and a recurrence state. A transaction is one attempt to move money against that pledge. A recurring pledge produces a transaction a month and only some of them succeed. Eleven transaction states exist and only three of them mean the money is real, with refunds counting against you. Sum everything and you have overstated what you raised, to your board, in writing.

FlowRunner agents work with that grain. They pull pledges and transactions incrementally rather than re-exporting a growing donor base every night, resolve a bank statement's variable symbol back to the pledge behind it, read project and promotion statistics that Darujme has already computed with the right states counted, and write a small number of things back. There are only two writes in the whole surface, and one of them is the record that a donor was thanked. That is precisely where human-in-the-loop earns its place.

Without FlowRunner

Intent and income conflated Pledged totals and received totals get reported as one number, and the number is too high
Bank lines matched by hand A Czech bank statement gives a variable symbol and somebody looks up each one
Lapsed recurring donors found late A donor whose standing order stopped is noticed at the annual review

With FlowRunner

Two questions, two sources Pledges answer what donors intended, transactions answer what arrived, and reports say which
Symbols resolved automatically The variable symbol from the statement resolves to the pledge and the donor behind it
Lapses surfaced while they are fixable Failed recurring attempts are listed by date, so the conversation happens while there is still time

Use Case Scenarios

  • An incremental sync instead of a nightly full export

    Both listing operations accept a last-modified timestamp, which turns a full nightly export into a sync that grows with activity rather than with the size of the donor base. On a schedule, the agent calls List Transactions with the watermark from the previous run, keeps only the states that mean income, and calls Get Pledge on each result to reach the donor and their intent. New and changed gifts flow into the donor record in HubSpot and the ledger in Xero. The watermark takes a full timestamp with an offset while every other date filter here takes a plain date, so the agent formats it correctly once and nobody debugs a silent empty result later.

  • Bank reconciliation from the variable symbol

    A Czech bank statement offers a variable symbol and very little else. The agent takes each unmatched line and calls Get Pledges By Variable Symbol, which returns the pledge and the donor behind it. Matched lines reconcile automatically into the sheet in Google Sheets that finance works from. Lines that resolve to nothing are collected as a short exception list rather than being guessed at, because a gift attributed to the wrong donor produces a thank-you letter to somebody who did not give and no letter to somebody who did.

  • A dunning list for recurring donors, in time to matter

    The failed-date filters on the transaction listing produce exactly the list a development team wants: recurring donors whose card or standing order stopped working. The agent runs it weekly, resolves each to the pledge and the donor, and separates a first failure from a third. First failures get an automatic message through SendGrid with a link to update the method. Repeated failures become a call task, because a donor of five years is worth a conversation rather than a fourth email. Project totals come from Get Project Stats rather than from summing transactions, because Darujme already knows which states count.

Human-in-Loop Highlight

Update Pledge Custom Fields is one of only two writes in this entire connector, and it is the one that carries the acknowledgment record. It writes into the fields defined on the project's donation form, which is how a CRM identifier or a thank-you-sent flag gets stamped onto a gift from a workflow. That flag is usually the only record anywhere that a donor was acknowledged, and it is also the dedup key: once a pledge is stamped, no later run picks it up. So a stamp written against the wrong pledge is not a data error that a resync corrects, it is a donor who is never thanked, discovered when they mention it. The exposure is real because eleven transaction states exist and only three mean the money arrived, so a run that filters loosely stamps donors whose payment is still pending or has already been refunded. The agent therefore assembles the batch and stops. It posts: "Acknowledgment batch for the Autumn Appeal: 412 pledges, filtered to the success, money-on-account, and sent-to-organization states. 37 pledges were excluded as pending and 4 as refunded. Stamping marks these as thanked permanently, and excluded pledges will be picked up next run. Approve the batch, or review the 37 pending first?" The development lead answers once. Pulling, matching, and filtering are the agent's work. The decision that a donor has been thanked stays with the person who has to face them if it was wrong.

Agent processes routinely
Detects exception requiring judgment
Clear match Continues automatically
Ambiguous Routes to human via preferred channel
Human decides
Agent resumes with decision

Agent Capabilities

13 actions

Pledges

4
  • List Pledges Lists donor pledges, filtered by project, state, and date. The last-modified filter is what turns a nightly full export into an incremental sync, and it takes a full timestamp with an offset rather than a plain date.
  • Get Pledge Reads one pledge in full: the donor, the payment method, the recurrence state, and the custom fields the project's form defines.
  • Get Pledges By Variable Symbol Resolves a Czech bank statement's variable symbol back to the pledge and donor behind it. The reconciliation lookup this platform is built for.
  • Update Pledge Custom Fields Writes into the fields defined on the project's donation form, which is how a CRM identifier or an acknowledgment flag is stamped onto a gift. The field names come from the project. This page's human gate sits here.

Transactions

2
  • List Transactions Lists attempts to move money, with filters for date, state, and the failure dates that produce a lapsed-recurring-donor list. Only three of the eleven states mean income, and refunds count against it, so the filter is the whole difference between a true total and a flattering one.
  • Get Transaction Reads one payment attempt with its state and amount. Amounts arrive as an object carrying cents and a currency rather than as a bare number.

Projects

3
  • List Projects Lists the organization's fundraising projects with their states.
  • Get Project Reads one project, including the custom field names its donation form defines. This is where the field keys for a pledge write come from.
  • Get Project Stats Returns totals Darujme has already computed for a project, with the right transaction states counted. Prefer this over adding transactions up yourself.

Promotions

4
  • List Project Promotions Lists the peer-to-peer fundraising promotions running under a project. There is no cross-project listing, so this always starts from a project.
  • Get Promotion Reads one promotion with its target, dates, and per-language text.
  • Get Promotion Stats Returns a promotion's computed totals, again with the states already handled correctly.
  • Create Promotion Creates a peer-to-peer fundraising promotion with its target, images, and per-language text. The vendor restricts this route to OAuth-authorized clients and refuses an identifier and secret pair with a bare status code, so expect to need an OAuth connection for it.

Frequently Asked Questions

What can FlowRunner do with Darujme.cz?

FlowRunner agents can run Get Pledge, List Pledges, and Get Pledges By Variable Symbol in Darujme.cz, plus 10 more actions.

Does connecting Darujme.cz to FlowRunner require OAuth?

No. Darujme.cz connects to FlowRunner with an API key, no OAuth flow required.

Can Darujme.cz trigger a FlowRunner workflow automatically?

Darujme.cz doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Darujme.cz

Free plan, no card required. Connect in minutes.