Use Fundraise Up's native UI or campaign forms to create donations.

If you need to update a donation amount or status in iPaaS.com (e.g., to mark a refund), do it on the Fundraise Up side; the change will flow through to iPaaS.com on the next poll.

Two-way sync requires a different integration topology.

New donations appear in iPaaS.com on the next scheduled poll, not in real time. End-to-end latency from "donor clicks Donate" to "iPaaS.com Transaction created" is bounded by the poll interval, not network round-trip time.

Tune the poll interval based on your acceptable latency / API-call budget. The default is per the iPaaS.com scheduler defaults; consult your iPaaS.com administrator.

There is no Webhook subscription page on the iPaaS.com side for this integration and no "test webhook" workflow.

The cursor advances forward only — once a donation has been processed, the next scheduled poll will not retrieve it again. The scheduled donation poll and Initialize Data are separate operations with different purposes: the scheduled poll runs on the configured cadence (and also on demand when triggered) and advances the watermark forward; Initialize (not supported here) paginates through historical donations (bounded by Donation Poll Days on the first run) and seeds the watermark with the newest record. Both are subscriber-controllable from the iPaaS.com Dashboard / Integration Monitoring / Events page — schedule the poll cadence, trigger an on-demand poll, or re-run initialization. Be aware that re-running initialization on a subscription that has already imported donations re-processes the available history (with the corresponding duplicate-handling cost). For a targeted historical refresh that does not re-process the entire history, the bulk sync using Postman pattern is the supported workflow.

See Connections and Settings — Donation Poll Days for the full preset description and the recommended values for different historical-import sizes.

Editing a supporter's email or name in Fundraise Up does not propagate to iPaaS.com until that supporter makes another donation. There is no "manual supporter refresh" path.

A donation from a brand-new email creates an iPaaS.com Customer; two donations from the same email link to the same Customer (deduplication is by email).

If your downstream workflow needs near-real-time donor profile updates, schedule a more frequent Donation poll — every Donation poll cascade-refreshes the supporters it touches.

Supporter Address's primary id is the parent Supporter id; addresses have no independent identifier on the Fundraise Up side. A supporter has at most one address.

Donation Payment's primary id is the payment object's id within the donation (typically the Stripe charge id for credit-card donations). A donation has at most one payment record.

If a Supporter has no address, no Customer Address record is produced (no error). If a Donation has no payment, no Transaction Payment is produced (no error).

To group installments by plan, filter iPaaS.com Transactions by the recurring_plan_id field.

To distinguish recurring from one-time donations, check recurring_plan_id is non-null (recurring) versus null (one-time).

The recurring_plan_next_payment_at field updates on every installment, so the most recent Transaction for a given recurring_plan_id has the freshest value.

The external-id records linking iPaaS Transactions to Fundraise Up donation ids remain in place, but the integration starts polling a different namespace where those ids may not exist or may refer to entirely different records.

The integration's record of the last donation it processed still points at the previous environment's most recent donation id, leading to duplicate Transaction creation, updates against the wrong Transactions, or silent stalls.

In the worst case, new donations from the swapped environment land as Updates against existing iPaaS Transactions that were originally created from the other environment, silently corrupting historical data.

Set Livemode correctly at install (true for production, false for staging) and leave it alone for the life of the subscription.

Use separate iPaaS.com subscriptions per environment. Create one subscription with Livemode=true for production donations and a separate subscription with Livemode=false for staging or UAT donations. iPaaS.com has no built-in staging-to-production-and-back cleanup on an existing subscription, so isolating environments at the subscription level is the cleanest path.

Flag records so downstream live destination integrations can filter test transactions out by content. A Static field mapping or a tag applied to each Transaction (e.g., setting a custom field to Test on the staging subscription's Donation mapping, or appending a recognizable suffix to a free-text field) lets the destination side identify and exclude test records by content rather than relying on subscription-level state — useful when both environments share downstream consumers or when records have already been imported and a clean cutover is not feasible.

If you are unsure whether your situation calls for a Livemode change, treat this as a destructive setting and do not change it. Consult your MiSP (Managed Integration Service Provider) or implementation partner before proceeding. The recovery cost if the flip is wrong significantly outweighs the cost of a short consultation.

Downstream systems that interpret Status = Refunded on the original Transaction as the offsetting event work out of the box — no additional action required.

If your accounting workflow specifically requires a separate offsetting Transaction record (a "-R" copy alongside the original), you have two paths:

Detect the status flip on the iPaaS.com side and create the offsetting Transaction yourself via a downstream workflow or integration step that fires when a Transaction's status changes to Refunded.

Submit a feature request to your iPaaS.com partner channel describing your accounting system's specific requirement — input like this informs future enhancement releases of the Fundraise Up integration.

Downstream systems that read the donation amount, currency, and status directly from the Transaction work out of the box, with the payment detail (Stripe charge id, payment method) available on the child Transaction Payment.

If your accounting or ERP workflow specifically needs to see one Transaction Line per Transaction (a common shape in classic ERP order tables), you have two paths:

Synthesize a single line from the Transaction's total on the consuming side via a downstream workflow or integration step.

Submit a feature request to your iPaaS.com partner channel describing the requirement — input like this informs future enhancement releases of the Fundraise Up integration.

If your downstream system (CRM, accounting, donor database) expects uppercase ISO codes or full country names, normalize the value before it leaves iPaaS.com. The easiest path is to replace the Country mapping in the Supporter Address collection with a Lookup Translation that maps lowercase codes to the form your downstream system wants.

Alternatively, normalize at the destination side if that system supports inbound transformation rules.

If you do nothing, expect downstream reports to show us / ca / gb rather than the more familiar uppercase or full-name forms.

Add/Update Fundraise Up Donation TO iPaaS.com

Donation Type (Static)

Donation EmailAddress (Dynamic Formula — anonymous-donation fallback)

Donation Total (Field)

Donation TestName1 (Custom Field, Field-type) — sample

Donation Livemode (Custom Field, Dynamic Formula) — sample

Add/Update Fundraise Up Payment TO iPaaS.com (child of the Donation collection)

Payment Amount (Dynamic Formula)

Payment Method (Lookup Translation)

Payment Status (Static)

Collection: Add/Update Fundraise Up Donation TO iPaaS.com

Shipped default: Order

Why it's a placeholder: Treats every donation as an iPaaS Transaction Type of Order. Subscribers reporting in iPaaS.com may prefer Donation, Gift, or a Lookup Translation against a Fundraise Up field.

Suggested action: Confirm the value matches the desired Transaction Type for downstream reporting; change inline if needed.

Collection: Add/Update Fundraise Up Donation TO iPaaS.com

Shipped default: email@email.com for anonymous donations

Why it's a placeholder: iPaaS.com Transactions require at least one of customer_id, company_id, or email_address. When a Fundraise Up donation has no Supporter (anonymous), the integration substitutes a placeholder email so the Transaction can be created. The placeholder is not a real address.

Suggested action: Decide whether to keep the fallback (route anonymous donations to a downstream "no-donor" bucket) or remove it (let anonymous donations fail visibly so the operator handles them manually).

Collection: Add/Update Fundraise Up Donation TO iPaaS.com

Shipped default: Source field Amount_in_default_currency

Why it's a placeholder: Maps the donation amount converted to the Fundraise Up account's default currency, so every iPaaS.com Transaction lands in a uniform currency basis. Multi-currency organizations that want the donor's submitted currency on the Transaction need to swap the source.

Suggested action: Decide whether default-currency uniformity or donor-currency fidelity matters more for your reporting; change the source to Amount if donor-currency fidelity is required.

Collection: Add/Update Fundraise Up Donation TO iPaaS.com

Shipped default: Sample mapping demonstrating the Pattern 1 (Direct 1:1) custom-field transfer shape

Why it's a placeholder: Exists only as a worked example of the Field-type custom-field mapping pattern. Has no production purpose on a real subscription.

Suggested action: Delete the row, or repurpose it to point at a real Fundraise Up custom field used by your organization.

Collection: Add/Update Fundraise Up Donation TO iPaaS.com

Shipped default: Sample formula return GetValueFromCustomField(AdditionalProperties, "livemode"); demonstrating the Pattern 2 (Dynamic Formula) custom-field transfer shape

Why it's a placeholder: Worked example of the Dynamic Formula pattern for surfacing a Fundraise Up donation custom field via the GetValueFromCustomField helper. The shipped formula reads a custom field named livemode from Fundraise Up and writes its value to an iPaaS.com Transaction custom field named Livemode. Companion to the TestName1 (Pattern 1) example.

Suggested action: Delete the row, or repurpose it by changing the formula's field-name argument to one of your own Fundraise Up custom fields (the argument is case-sensitive and must match the Name entered in the Fundraise Up dashboard verbatim).

Collection: Add/Update Fundraise Up Payment TO iPaaS.com (child of the Donation collection)

Shipped default: Amount_in_default_currency from the parent Donation

Why it's a placeholder: Same multi-currency consideration as the Donation Total mapping above. The default-currency value provides a uniform reporting basis.

Suggested action: Decide whether default-currency uniformity or donor-currency fidelity matters more for your reporting; change the source to Amount if donor-currency fidelity is required (apply consistently to both Donation Total and Payment Amount).

Collection: Add/Update Fundraise Up Payment TO iPaaS.com (child of the Donation collection)

Shipped default: Every Fundraise Up payment method → iPaaS.com Other

Why it's a placeholder: The shipped translation collection currently maps every Fundraise Up method (credit_card, paypal, apple_pay, all 16 values) to the catch-all iPaaS.com Other Method. The actual payment method is lost on the iPaaS.com Transaction Payment unless subscribers update the translation.

Suggested action: Walk the translation table and remap each Fundraise Up value to the specific iPaaS.com Method value that matches the subscription's reporting needs (typical pattern: credit_card → Credit Card, paypal → PayPal, leave rare methods at Other).

Collection: Add/Update Fundraise Up Payment TO iPaaS.com (child of the Donation collection)

Shipped default: Completed

Why it's a placeholder: Hard-coded literal that does not reflect the actual outcome of any specific payment. Subscribers who want the Payment status to follow the Donation outcome (Completed / Failed / Refunded) need to swap to a Lookup Translation against the Donation status.

Suggested action: Replace the Static with a Lookup Translation against the Donation status field (succeeded → Completed, failed → Failed, refunded → Refunded, etc.).

The integration must be kept single-threaded or near-single-threaded to comply with Fundraise Up's published guidance. In the subscription's Connections and Settings, the Concurrent Connections preset must be set to 1 (recommended, the default) or 2 (still safe), and never above 2.

The API Throttle Limit and API Throttle Seconds presets enforce a per-second request rate and cannot defend against a concurrency limit — leave them at their defaults (Unlimited / Unlimited).

If multiple iPaaS.com subscriptions target the same Fundraise Up account (e.g., staging and production using test-mode and live-mode keys), the sum of their Concurrent Connections values must stay at or below 3. Subscriptions targeting distinct Fundraise Up subaccounts each have their own 3-parallel allowance.

When the limit is hit, the integration receives HTTP 429, raises a quota exception, and the iPaaS.com scheduler reschedules the affected transfer for the next poll cycle. The subscriber sees no direct error; the transfer simply reappears on the next run. With Concurrent Connections at 1 or 2 and the integration as the only consumer of the account, this scenario does not arise in normal operation.

For authoritative platform details, see Fundraise Up: Rate limits in Fundraise Up's API documentation.

Workflow-style outbound automation requires manual setup of mappings on each subscription.

Custom-field mappings created via the iPaaS.com Subscription UI are not portable between subscriptions without re-creation or export.

The integration's "Concurrent Connections" setting controls outgoing HTTP concurrency only; it does not parallelize per-record processing.

Fundraise Up Installation Instructions

Fundraise Up Connections and Settings

Fundraise Up API Endpoints

Fundraise Up Error Messages

Fundraise Up to iPaaS.com Donation Mapping Documentation

Fundraise Up to iPaaS.com Supporter Mapping Documentation