Fundraise Up to iPaaS.com Donation Mapping Documentation

Fundraise Up Donation records can be transferred to iPaaS.com as Transaction records (Add or Update) on a configurable polling schedule or via Manual Sync. Each Donation transfer also produces a child Transaction Payment record from the donation's nested payment data, and triggers a prerequisite Supporter transfer so the iPaaS.com Customer record exists before the Transaction is finalized. The integration supports transferring Fundraise Up donation custom fields as iPaaS.com custom fields on the Transaction record.

ID Format

Manual Sync ID Format

Enter the Fundraise Up Donation ID — the system record ID for the donation (example: DFQLCFEP). The integration retrieves the full Donation record (with its nested payment data) from the Fundraise Up API and dispatches it to iPaaS.com along with the child Transaction Payment.

External ID Format (saved after sync)

After a successful transfer, iPaaS.com records the Fundraise Up Donation ID as the external id link on the iPaaS.com Transaction record. This is the link used to match subsequent inbound updates to the same iPaaS.com Transaction instead of creating duplicates. The child Transaction Payment is saved with the Fundraise Up payment identifier (the Stripe charge ID for credit-card payments) as the external-id link on the iPaaS.com Transaction Payment record.

Deleted Record Support

Inbound Delete is not supported. Fundraise Up is the system of record for Donations and the integration only flows data into iPaaS.com. Donations cannot be deleted via this integration. When a Fundraise Up donation is refunded, the donation's status flips to refunded and the integration updates the existing iPaaS.com Transaction's status to Refunded via the Status mapping — no separate offsetting Transaction record is produced (see Fundraise Up Known Limitations for details).

Custom Field Support

This mapping collection supports reading Fundraise Up donation custom field values for use in the iPaaS.com Transaction transfer. Fundraise Up custom fields are defined per campaign in the Fundraise Up dashboard and surface on every donation made through that campaign.

Configuring custom fields in Fundraise Up

In the Fundraise Up dashboard, navigate to Campaigns and click into the campaign that will collect donations.
Click the Settings tab.
Click Custom Fields in the left settings menu.
Click + Add field for each custom field you want to capture. Enter a Name (the identifier used by Fundraise Up and by the iPaaS.com mapping — e.g., TestName1) and an optional Default value (applied to the donation when the donor leaves the field blank).
Click Save changes.

Custom Fields configuration screen in the Fundraise Up dashboard, showing the Name and Default value columns with two example rows (TestName1 / TestValue1 and TestName2 / TestValue2), the + Add field button, and the Save changes button.

Pattern 1: Direct 1:1 Mapping (Field Type)

Typically the simpler choice when the iPaaS.com destination is a Transaction custom field that can share the same name as the Fundraise Up custom field. Steps:

In iPaaS.com, create a custom field on the Transaction collection to map to (or use an existing custom field). The iPaaS.com custom field name does not need to match the Fundraise Up Name, though using the same name simplifies operations.
In this mapping collection, add a mapping of type Field.
Set the Source table to Custom, the Source field to the Name value entered in Fundraise Up (e.g., TestName1), and the Destination to the iPaaS.com custom field from step 1. If the source field does not yet exist in the picker, click + Add Custom Field to add it.

At transfer time, the integration locates the Fundraise Up custom field by its Name and transfers the donor-entered value (or the configured Default value if the donor left the field blank). The TestName1 mapping in this collection is shipped as a working example of this pattern — delete or repurpose it before going live.

Pattern 2: Dynamic Formula Mapping

Choose this pattern when a direct 1:1 mapping does not fit — for example, when you need to transform the value (case-normalize, format-strip, prefix/suffix), combine multiple Fundraise Up source fields into one iPaaS.com destination, or apply conditional logic before writing.

The integration exposes a helper function GetValueFromCustomField that retrieves a Fundraise Up custom field's value from the donation record's AdditionalProperties collection. The simplest Pattern 2 mapping wraps this helper to surface one custom field as a transformed value on iPaaS.com:

return GetValueFromCustomField(AdditionalProperties, "your-fundraise-up-field-name");

The argument is the Name you entered when defining the custom field in the Fundraise Up dashboard, case-sensitive and matched verbatim.

Steps to configure:

Create (or identify) an iPaaS.com Transaction custom field to receive the value. Click + Add Custom Field in the destination picker if you need to create one inline.
On this mapping collection, add a mapping of type Dynamic Formula.
Set the Destination to the iPaaS.com Transaction custom field from step 1.
In the Source editor, enter the formula. The bare helper call (above) returns the raw value. To transform before writing, wrap the helper output in standard C# expressions:
- Case-normalize: return GetValueFromCustomField(AdditionalProperties, "campaign_code").ToUpper();
- Substitute a default when blank: var v = GetValueFromCustomField(AdditionalProperties, "donor_type"); return string.IsNullOrEmpty(v) ? "Individual" : v;
- Combine fields: return GetValueFromCustomField(AdditionalProperties, "first_initial") + "." + GetValueFromCustomField(AdditionalProperties, "last_name");

Behavior at transfer time:

If the donor entered a value (or Fundraise Up's Default value applied), the helper returns that string.
If the custom field is not defined on the originating campaign, or the donor left it blank and no default was configured, the helper returns an empty value and the destination iPaaS.com field is set to empty.
Boolean values arrive as "True" / "False" (capital first letter), not "true" / "false". Helper return values are serialized through the .NET ToString() representation rather than the JSON wire form. The shipped Livemode example produces this shape because Fundraise Up's livemode field is a boolean. If your downstream consumer requires the lowercase JSON-form string, coerce explicitly in the formula:

return GetValueFromCustomField(AdditionalProperties, "livemode").ToString().ToLower();

Subscribers reusing this formula shape for other boolean-typed Fundraise Up custom fields should plan for the same capital-first-letter behavior and coerce in the formula if a specific case is required downstream.

Shipped worked example. This mapping collection ships a Pattern 2 example named Livemode that uses the bare helper call:

return GetValueFromCustomField(AdditionalProperties, "livemode");

It reads the Fundraise Up custom field livemode and writes its value to an iPaaS.com Transaction custom field named Livemode. This is a placeholder for demonstration purposes — delete it or repurpose it to one of your own custom field names before going live.

Shared Behavior and Limitations

Custom fields are scoped per campaign. A custom field defined on Campaign A is not automatically available on Campaign B. If your subscription receives donations from multiple campaigns and you want a custom field surfaced on every donation, define that field with the same Name on each campaign.
Custom field values are normalized at intake. Fundraise Up emits custom fields as an array of objects on the donation response; the integration normalizes them into the iPaaS.com key-value shape automatically. Subscribers do not need to handle the source-side array form.
First match wins on duplicates. If a campaign somehow ends up with two custom fields sharing the same Name (rare — the Fundraise Up UI does not encourage this), only the first entry's value transfers.

Mapping Collection Status

Status: Enabled
Trigger Events: Scheduled Poll (default) or Manual Sync. There are no webhooks — Fundraise Up does not deliver webhooks to external URLs, so this integration polls the Fundraise Up API on a configurable schedule.

Configure the polling cadence under iPaaS.com Dashboard / Integration Monitoring / Events. Manual Sync is available from the iPaaS.com Manual Sync page at any time using the Fundraise Up Donation ID.

Duplicate or Conflicting Mappings

This mapping transfers Donations from Fundraise Up to iPaaS.com. Fundraise Up is the system of record for Donations and the integration is To iPaaS.com only — there is no outbound Donation mapping collection that writes back to Fundraise Up.

Warning — Unmapped Field Overwrite Risk: The iPaaS.com API uses PUT (full record replace) when updating Transaction records. The following Transaction fields are not mapped in the default template mappings for Add/Update Fundraise Up Donation TO iPaaS.com. Any existing values on the iPaaS.com Transaction record will be overwritten with empty/null values each time an inbound transfer runs unless additional mappings are added to preserve them:

DiscountAmount
TaxAmount
ShippingAmount
Subtotal
TotalQty
TransactionUpdatedDateTime

If your integration uses any of these fields on the iPaaS.com side, you must take action to preserve their values during inbound updates. The recommended approach is to split this mapping collection into separate Add and Update collections, then use the DestinationValue function in the Update collection's mapping formulas to carry forward the existing iPaaS.com value for each unmapped field. For example, to preserve the existing TaxAmount during an update, add a Dynamic Formula mapping with the source formula DestinationValue.TaxAmount mapped to the iPaaS.com TaxAmount field. This retrieves the current value from the iPaaS.com record and writes it back, preventing the PUT from overwriting it with null. Repeat for each field that needs to be preserved.

Supported Child Collections

Add/Update Fundraise Up Payment TO iPaaS.com (Child of Donation): Transfers the single payment that produced the donation as an iPaaS.com Transaction Payment record. Each Payment is saved with the Fundraise Up payment identifier (Stripe charge ID for credit-card payments) as the external-id link. Payment transfers via this child collection always accompany a parent Donation transfer — they are not invoked independently.

System Caveats

Fundraise Up Caveats

Cursor-based polling. Fundraise Up does not support filtering its donation list by date, so the integration uses an id-cursor watermark (Poll_Donations_LastId) and the ending_before query parameter to retrieve only donations newer than the last one processed. The cursor advances forward only — once a donation has been processed, the next scheduled poll will not retrieve it again. The scheduled Poll and the InitializeData backfill are separate operations with different purposes: Poll advances the watermark forward each run; InitializeData paginates through all available Donations and seeds the watermark to the newest record. Subscribers configure the scheduled cadence, trigger ad-hoc polls, or re-run initialization from the iPaaS.com Dashboard / Integration Monitoring / Events page. Re-running initialization on a subscription that has already imported donations re-processes the full available history; for a targeted historical refresh without re-processing what was already imported, the bulk sync using Postman pattern is the supported workflow.
Recurring donations produce separate records. Each recurring installment produces its own Fundraise Up Donation record and its own iPaaS.com Transaction. There is no separate Recurring Plan record in iPaaS.com. Recurring plan metadata (frequency, status, next payment date, plan amount, plan currency) is exposed as readable fields on each Donation, so subscribers can filter or group installments by recurring_plan_id in downstream systems.
Anonymous donations have no supporter. When a donor anonymizes their submission, the donation arrives in Fundraise Up with no supporter id. No Supporter prerequisite runs for that donation; the Transaction is created using the placeholder value email@email.com from the EmailAddress mapping (so the iPaaS.com Customer-or-email-or-company requirement is satisfied). The placeholder is not a real address — see Fundraise Up Known Limitations for the keep-or-remove decision.
Livemode and API key must match. A live-mode API key cannot read test-mode donations and vice versa. The Livemode subscription setting must agree with the kind of API key supplied at install time.

iPaaS.com Caveats

Required API field group. iPaaS.com Transactions require at least one of customer_id, company_id, or email_address. When a Supporter prerequisite runs, the Transaction is linked via customer_id and the email_address mapping becomes optional. When no Supporter is available (anonymous donations), the EmailAddress mapping's email@email.com fallback satisfies the requirement.
PUT semantics. Every transfer fully replaces the Transaction record. Subscribers running both this integration and another writer to the same Transaction must coordinate which side owns which field, and use DestinationValue preserve-mappings (see Unmapped Field Overwrite Risk above) where appropriate.
Custom field destination prerequisites. Custom fields mapped in this collection write to iPaaS.com custom fields on the Transaction. Use the + Add Custom Field affordance in the mapping editor to add a new destination custom field inline if one does not already exist.

Setup Requirements

For full setup steps see the Installation Instructions and Connections and Settings. The integration-wide setup (Fundraise Up API key acquisition, Livemode toggle, subscription preset configuration) is documented there and not repeated here.

Integration Flow

When the scheduled poll runs (or a Manual Sync is initiated), the integration processes each Donation transfer in the following order:

Poll or fetch. For scheduled-poll transfers, the integration issues GET /v1/donations?limit=100&ending_before={last seen id} and receives a page of donations newer than the watermark. For Manual Sync, the integration retrieves the single Donation directly using the supplied Donation ID via GET /v1/donations/{id}.
Determine action type. Each Donation is classified as Add (no prior Transaction exists for this Donation ID) or Update (Transaction exists). Delete is not supported.
Resolve the Supporter prerequisite. For each Donation with a supporter.id, the integration runs the Supporter mapping collection first so the iPaaS.com Customer record exists before the Transaction is finalized. Anonymous donations skip this step.
Map Donation fields. Apply each mapping in this parent collection to translate the Donation record into the iPaaS.com Transaction shape, including any configured custom-field mappings.
Process the child Payment. The payment data nested on the Donation record is processed through the Add/Update Fundraise Up Payment TO iPaaS.com child collection and saved as a Transaction Payment with the Fundraise Up payment identifier as the external-id link.
Dispatch to iPaaS.com. The translated Transaction (with the linked Customer from the Supporter prerequisite and the child Payment) is dispatched to iPaaS.com with the Add or Update action type, and the watermark is advanced to the newest Donation ID processed.

Mappings

Add/Update Fundraise Up Donation TO iPaaS.com

Description: Transfers Donation records from Fundraise Up to iPaaS.com via scheduled poll or Manual Sync. Maps core transaction fields (id, total, status, created date), supporter contact (email), and donation-level custom fields.

Mapping Filter: None — all Donation records returned by the Fundraise Up poll are processed without additional filtering conditions.

Field Mapping Table

Mapping Type	Source Field (Fundraise Up)	Destination Field (iPaaS.com)	Description
Field	Id	TransactionNumber	Required. Maps the Fundraise Up donation id (e.g. `DFQLCFEP`) to the iPaaS.com Transaction `transaction_number`. This id is what the integration uses to detect updates to the same Donation across polls and what subscribers should match against Fundraise Up records when investigating individual transactions.
Dynamic Formula	(platform-managed)	SystemId	Required. iPaaS.com platform field that links the Transaction back to the originating subscription. Required by default on every Donation mapping.
Static	`"Order"`	Type	Required. Sets the iPaaS.com Transaction `type` to `Order`. Placeholder default — review before going live and change if your iPaaS Transaction Type taxonomy uses a different label (e.g., `Donation`, `Gift`).
Lookup Translation	FundraiseUp Donation Status → iPaaS Order Status	Status	Required. Translates the Fundraise Up donation status into the iPaaS.com Transaction status. Allowed Fundraise Up values: succeeded → Complete, failed → Cancelled, refunded → Refunded, pending / retrying / scheduled → Pending.
Dynamic Formula	(supporter email with fallback)	EmailAddress	Suggested. Maps the supporter email from Fundraise Up to the Transaction's `email_address`. The default formula falls back to the placeholder value email@email.com when the donation has no Supporter reference (e.g., anonymous donations). Placeholder default — review before going live; see Known Limitations for the keep-or-remove decision.
Field	Amount_in_default_currency	Total	Recommended. Maps the donation amount converted to the Fundraise Up account's default currency. Placeholder default — review before going live if your reporting requires donor-currency fidelity rather than default-currency uniformity.
Field	Created_at	TransactionCreatedDateTime	Recommended. Maps the donation's `created_at` timestamp to the iPaaS.com Transaction's `transaction_created_date_time`. Preserves the donor-facing donation time on the Transaction for reporting.
Field	Custom.TestName1	TestName1 (Custom Field)	Sample — delete or repurpose before going live. Worked example of the custom-field 1:1 mapping pattern. Map a real Fundraise Up custom field by referencing its Name here.

Add/Update Fundraise Up Payment TO iPaaS.com (Child)

Description: Transfers the payment that produced each Donation as an iPaaS.com Transaction Payment record. Runs only as a child of the parent Donation transfer; not invoked independently.

Mapping Filter: None — the single payment from every transferred Donation is processed.

Field Mapping Table

Mapping Type	Source Field (Fundraise Up)	Destination Field (iPaaS.com)	Description
Lookup Translation	FundraiseUp Payment Method → iPaaS Method	Method	Required. Translates the Fundraise Up payment method into the iPaaS.com Transaction Payment method. Placeholder default — must be reviewed before going live. Every Fundraise Up payment method currently maps to iPaaS.com Other as a catch-all; subscribers or their MiSP should remap each Fundraise Up value to the specific iPaaS.com Method value that matches their reporting needs (e.g., `credit_card` → `Credit Card`, `paypal` → `PayPal`).
Dynamic Formula	(parent Donation's Amount_in_default_currency)	Amount	Required. Maps the donation's `amount_in_default_currency` from the parent Donation record. Placeholder default — review before going live in the same multi-currency analysis as the parent Donation `Total` mapping.
Field	Method	Description	Optional. Writes the Fundraise Up payment method (e.g., `credit_card`, `paypal`) into the Transaction Payment description for diagnostic clarity. Unaffected by the Method Lookup Translation above, so it preserves the original method value even before the translation is reconfigured.
Static	`"Completed"`	Status	Optional. Sets the Transaction Payment `status` to `Completed`. Placeholder default — review before going live. Subscribers wanting the Payment status to follow the underlying donation outcome should swap to a Lookup Translation against the Donation status.
Field	Id	checkout_transaction_id (Custom Field)	Recommended. Captures the Fundraise Up payment identifier — for credit-card payments, the Stripe charge ID — into a custom field on the iPaaS.com Transaction Payment so subscribers can reconcile iPaaS.com records against Stripe / PayPal / processor reports.

Lookup Translation Tables

FundraiseUp Donation Status → iPaaS Order Status — Translates the Fundraise Up donation status to the iPaaS.com Transaction status.

Source Value (Fundraise Up)	Destination Value (iPaaS.com)	Notes
`succeeded`	Complete	Donor's payment cleared.
`failed`	Cancelled	Payment processor declined the donation.
`refunded`	Refunded	Donation was refunded after a successful payment.
`pending`	Pending	Donation is awaiting processor confirmation.
`retrying`	Pending	A failed payment is being retried by Fundraise Up.
`scheduled`	Pending	A recurring installment is queued for a future date.

These are the complete set of status values Fundraise Up returns today. If Fundraise Up adds new status values in the future, extend the translation collection accordingly.

FundraiseUp Payment Method → iPaaS Method — Translates the Fundraise Up payment method to the iPaaS.com Transaction Payment method.

The shipped translation collection maps every Fundraise Up method to the catch-all iPaaS.com value Other. This is a placeholder default so transfers do not fail before the iPaaS.com Method catalog has been customized — but it loses the actual method on the Transaction Payment until subscribers walk the translation and remap each Fundraise Up value to the specific iPaaS.com Method value that matches their reporting needs. See Known Limitations for the full list of allowed Fundraise Up values and the recommended remapping pattern.

Error Handling

Errors from this mapping collection appear in iPaaS.com Dashboard / Integration Monitoring / Error Logs. General activity (successful transfers, manual sync events) appears in Activity Tracker. Every error log entry includes the Request-Id response header from the Fundraise Up API — supply this id to Fundraise Up Support if you need to escalate a transaction-level issue.

For the full catalog of error messages, descriptions, and resolution steps, see the Error Messages article for this integration (forthcoming).

Testing & Validation

Test Scenarios

Create a new donation via the Fundraise Up checkout (Individual donor, valid email) and verify that the next scheduled poll picks it up and creates an iPaaS.com Transaction with the correct TransactionNumber, Status, Total, EmailAddress, and TransactionCreatedDateTime — plus a linked Customer (from the Supporter prerequisite) and a child Transaction Payment with the Stripe charge ID captured in checkout_transaction_id.
Anonymize a donation in Fundraise Up and verify the resulting iPaaS.com Transaction lands with email_address = email@email.com and no Customer link, confirming the placeholder fallback in the EmailAddress mapping is functioning as designed.
Update a donation's status in Fundraise Up (for example, refund a previously-succeeded donation) and verify the next poll updates the existing iPaaS.com Transaction's status to Refunded without creating a duplicate Transaction.
Manually sync a donation using the Donation ID via the iPaaS.com Manual Sync page and verify the transfer succeeds end-to-end, including the child Payment.
Configure a Fundraise Up custom field with Name = donor_message and a non-empty Default value. Submit a donation that leaves the field blank and verify the iPaaS.com Transaction's mapped custom field receives the default value rather than null.
Walk the FundraiseUp Payment Method → iPaaS Method translation collection and remap at least one Fundraise Up method (e.g., credit_card → Credit Card) to a specific iPaaS.com Method value. Verify a new donation paid with that method lands in iPaaS.com with the remapped Method rather than the catch-all Other.

Validation Checklist

The Fundraise Up API key supplied in subscription settings has not been revoked and matches the Livemode setting (live key with Livemode=true, test key with Livemode=false).
The polling cadence is configured under Dashboard / Integration Monitoring / Events at a frequency appropriate for the subscriber's latency tolerance.
The FundraiseUp Payment Method → iPaaS Method translation has been walked and remapped from the shipped Other-catch-all to specific iPaaS.com Method values.
The placeholder defaults flagged in Known Limitations (Type Order, EmailAddress fallback, Total currency choice, TestName1 sample row, Livemode sample row, Payment Amount currency choice, Payment Method translation, Payment Status Completed) have each been reviewed and either confirmed or replaced.
For multi-campaign subscribers: every campaign that needs to surface a particular custom field has that field defined with the same Name in Fundraise Up.

Additional Notes

Operational Notes

API unavailability: If the Fundraise Up API is temporarily unavailable when a poll or manual sync runs, the transfer fails. The error appears in Dashboard / Integration Monitoring / Error Logs. The donation will be picked up on the next scheduled poll if its id is still ahead of the watermark, or via Manual Sync.
Rate limit and quota: Fundraise Up enforces a concurrency-based API rate limit — at most 3 parallel API requests per Fundraise Up account, across all endpoints and all API keys (live and test combined). Excess requests are rejected with HTTP 429 and the error code concurrent_requests_limit_exceeded. The integration's default Concurrent Connections preset of 1 keeps requests single-threaded so this limit is never reached in normal operation; subscribers running multiple iPaaS.com subscriptions against the same Fundraise Up account must keep the sum of their Concurrent Connections values at or below 3. The integration treats 429 as a transient error and reschedules the affected transfer for the next poll cycle; transient 5xx responses (500, 502, 503, 504) are also retried automatically. Permission / authentication errors are surfaced as permanent failures without being rescheduled. See Connections and Settings for the full rate-limit reference.
Refund handling deferred. Refunds in Fundraise Up flip the original donation's status to refunded, which propagates to iPaaS.com via the Status mapping (Transaction status → Refunded). The integration does not currently create a separate offsetting Transaction record (the convention some accounting systems expect); see Known Limitations for the full status.