Fundraise Up to iPaaS.com Supporter Mapping Documentation
Fundraise Up Supporter (donor) records can be transferred to iPaaS.com as Customer records (Add or Update) as a prerequisite to each Donation transfer or via Manual Sync. Each transfer dispatches the Supporter record plus the supporter's single address through the Add/Update Fundraise Up Supporter Address TO iPaaS.com child collection. The Supporter is the canonical source of donor identity for the Fundraise Up integration; the iPaaS.com Customer record it creates is what subsequent Donations link to.
ID Format
Manual Sync ID Format
Enter the Fundraise Up Supporter ID — the system record ID for the supporter. The integration retrieves the full Supporter record (with the nested address) from the Fundraise Up API and dispatches it to iPaaS.com.
External ID Format (saved after sync)
After a successful transfer, iPaaS.com records the Fundraise Up Supporter ID as the external-id link on the iPaaS.com Customer record. This is the link used to match subsequent inbound updates to the same iPaaS.com Customer instead of creating duplicates. The child Customer Address is linked to the parent Customer in iPaaS.com using the parent Supporter's ID — Fundraise Up addresses do not have an independent identifier on the source side.
In addition to the external-id link, the iPaaS.com Customer's email_address field acts as a fallback collision-detection key (and is enforced as unique across Customers in the company by the iPaaS.com API). Two Supporters with the same email cannot both create new Customer records — the second will update the existing Customer rather than create a new one.
Deleted Record Support
Inbound Delete is not supported. Fundraise Up is the system of record for Supporter identity and the integration only flows data into iPaaS.com. Supporters cannot be deleted via this integration.
Custom Field Support
The Fundraise Up Supporter object does not currently expose configurable custom fields directly. Custom fields on the donor record are sourced from the related Donation object — see the Donation TO iPaaS.com Mapping Documentation for the custom-field configuration pattern. Subscribers wishing to surface donor-level custom data on the iPaaS.com Customer (rather than the Transaction) should configure those fields on each Fundraise Up campaign and add Customer-side custom-field mappings via Dynamic Formula in this collection once the formula access pattern is available.
Mapping Collection Status
Status: Enabled
Trigger Events: Donation Prerequisite (automatic) or Manual Sync.
Supporter transfers run in two situations:
Trigger | Behavior |
Donation Prerequisite | Every Donation transfer first transfers the donation's Supporter so the iPaaS.com Customer record exists before the Transaction is finalized. Subscribers do not configure this — it is part of the normal Donation flow. |
Manual Sync | Subscribers can transfer a single Supporter from the iPaaS.com Manual Sync page at any time using the Fundraise Up Supporter ID. Useful for re-syncing a donor whose profile changed in Fundraise Up between donations. |
There is no scheduled Supporter sync. Fundraise Up does not expose a "modified supporters since" endpoint, so iPaaS.com cannot poll for Supporter changes independent of donations. Donor profile updates flow into iPaaS.com only as a side effect of the next donation by that supporter, or via the Manual Sync option above.
Duplicate or Conflicting Mappings
This mapping transfers Supporters from Fundraise Up to iPaaS.com. Fundraise Up is the system of record for donor identity and the integration is To iPaaS.com only — there is no outbound Supporter mapping collection that writes back to Fundraise Up.
Warning — Unmapped Field Overwrite Risk: The iPaaS.com API uses PUT (full record replace) when updating Customer and Customer Address records. The following fields are not mapped in the default template mappings for Add/Update Fundraise Up Supporter TO iPaaS.com and its child Add/Update Fundraise Up Supporter Address TO iPaaS.com. Any existing values in these fields on the iPaaS.com Customer or Customer Address record will be overwritten with empty/null values each time an inbound transfer runs unless additional mappings are added to preserve them:
Customer fields:
Company
Comment
Customer Address fields:
FirstName (on the Address record itself, distinct from the parent Customer's FirstName)
LastName (on the Address record)
Company (on the Address record)
Address3
IsPrimaryBilling
IsPrimaryShipping
Type (Customer Address type)
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 an existing Comment during an update, add a Dynamic Formula mapping with the source formula DestinationValue.Comment mapped to the iPaaS.com Comment field. Repeat for each field that needs to be preserved.
Supported Child Collections
Add/Update Fundraise Up Supporter Address TO iPaaS.com (Child of Supporter): Transfers the supporter's single address as an iPaaS.com Customer Address record. Fundraise Up exposes one address per supporter (no multi-address support on the donor side), so each Supporter transfer produces at most one Customer Address record. Address transfers via this child collection always accompany a parent Supporter transfer — they are not invoked independently.
System Caveats
Fundraise Up Caveats
No supporter-modified endpoint. Fundraise Up does not provide a way to query supporters that have changed since a given timestamp. Profile changes propagate to iPaaS.com only through subsequent donations or manual re-syncs.
Anonymous donations have no supporter. If a donor anonymizes a donation, 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.comfrom the Donation EmailAddress mapping. See the Donation TO iPaaS.com Mapping Documentation for the anonymous-donation flow.Single address per supporter. Fundraise Up does not support multiple addresses per donor. Re-sending a Supporter with a different address overwrites the previous address on the iPaaS.com Customer (subject to the
PreventDuplicatesemantics on the Address mapping).Address fields can all be empty. A donor who skips the address entirely produces an address sub-object with all fields blank. The transfer still succeeds; the iPaaS.com Customer Address row is created with empty values.
Country codes arrive lowercase. Fundraise Up emits the
countryvalue as a lowercase ISO 3166-1 alpha-2 code (us,ca,gb). Downstream systems expecting uppercase codes or full country names should normalize the value via a Lookup Translation on the Country mapping. See Known Limitations.
iPaaS.com Caveats
Required API fields. The iPaaS.com Customer API requires customer_number (populated from the Fundraise Up supporter id, always present) and email_address (populated from the supporter's primary email; supporters without an email will fail to transfer). The CustomerNumber mapping is the integration's primary collision-detection key for re-linking to the same Customer across transfers.
Email uniqueness. The iPaaS.com Customer API enforces uniqueness on
email_addresswithin a company. Two Supporters with the same email cannot both create new Customer records; the second produces an update to the existing iPaaS.com Customer.PreventDuplicate is content-based. When the address mapping's
PreventDuplicateflag istrue(the default), iPaaS.com matches addresses on content (city / region / postal code / address lines), not on an external id. A match suppresses creation of a second Address row on the same Customer.Customer record may be shared with other integrations. When the iPaaS.com Customer is also written by another integration (a CRM, an accounting system, another donation platform), the most recent write wins on any field both integrations map. Plan the
customer_numberownership specifically — last-writer-wins on the matching key can break record-linking on subsequent Fundraise Up transfers because the integration would no longer recognize the customer as the same Supporter. Choose one integration to owncustomer_numberas the Field mapping; configure the others to leave it unset, use a different matching field, or write a static value.
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
Supporter transfers run as a prerequisite step of every Donation transfer; the integration also supports running a Supporter transfer on its own via Manual Sync. The processing order is:
Trigger. Either the Donation transfer pipeline reaches the prerequisite step for a donation whose
supporter.idis non-null, or a subscriber initiates a Manual Sync with a Supporter ID.Determine action type. Classify the transfer as Add (no prior Customer exists for this Supporter ID) or Update (Customer exists). Delete is not supported.
Retrieve the Supporter record. The integration calls
GET /v1/supporters/{id}against the Fundraise Up API to fetch the full Supporter (including the nested address sub-object).Map Supporter fields. Apply each mapping in this parent collection to translate the Supporter record into the iPaaS.com Customer shape.
Process the child Address. The nested address sub-object on the Supporter is processed through the Add/Update Fundraise Up Supporter Address TO iPaaS.com child collection. If the donor did not provide an address, no Customer Address record is created (no error is raised).
Dispatch to iPaaS.com. The translated Customer (with the optional Customer Address child) is dispatched to iPaaS.com with the Add or Update action type. If this was a Donation prerequisite, the Donation transfer pipeline resumes with the now-linked Customer.
Mappings
Add/Update Fundraise Up Supporter TO iPaaS.com
Description: Transfers Supporter (donor) records from Fundraise Up to iPaaS.com via the Donation prerequisite flow or via Manual Sync. Maps core identity fields (id, email, first name, last name).
Mapping Filter: None — all Supporter records reached via Donation prerequisite or Manual Sync are processed without additional filtering conditions.
Field Mapping Table
Mapping Type | Source Field (Fundraise Up) | Destination Field (iPaaS.com) | Description |
Field | Id | CustomerNumber | Required. Maps the Fundraise Up immutable system record ID to the iPaaS.com Customer |
Field | EmailAddress | Required. Maps the supporter's primary email address to the iPaaS.com Customer | |
Field | First_name | FirstName | Recommended. Maps the supporter's first name. Recommended so downstream systems can address the donor by name. |
Field | Last_name | LastName | Recommended. Maps the supporter's last name. Same rationale. |
Add/Update Fundraise Up Supporter Address TO iPaaS.com (Child)
Description: Transfers the Supporter Address sub-object from Fundraise Up to iPaaS.com as a child of the parent Supporter transfer. Addresses are not transferred independently through this collection — they always accompany the parent. Fundraise Up exposes one address per supporter.
Mapping Filter: None — all addresses arriving on the parent Supporter are processed.
Field Mapping Table
Mapping Type | Source Field (Fundraise Up) | Destination Field (iPaaS.com) | Description |
Field | Line1 | Address1 | Recommended. Maps the first address line ( |
Field | Line2 | Address2 | Optional. Maps the second address line. Frequently empty — many donors enter the entire street address on line 1. |
Field | City | City | Recommended. Maps the address city. |
Field | Region | Region | Recommended. For US addresses Fundraise Up emits the two-letter state code (e.g., |
Field | Postal_code | PostalCode | Recommended. Maps the postal / ZIP code. |
Field | Country | Country | Recommended. Maps the country. Fundraise Up emits lowercase ISO 3166-1 alpha-2 codes ( |
Field | Phone (supporter.phone) | PhoneNumber | Optional. Fundraise Up does not associate a phone with each address — the supporter's single phone is written here. Empty when the donor did not provide a phone. |
Static |
| PreventDuplicate | Required. Enables iPaaS.com's address deduplication so repeated Supporter transfers do not accumulate duplicate Customer Address rows on the same Customer. Addresses are matched on content (city / region / postal code / address lines); a match suppresses creation of a second row. Leave set to |
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 supporter-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
Submit a new donation via Fundraise Up using a donor email that does not yet exist on the iPaaS.com side. Verify the next poll triggers a Supporter prerequisite that creates a new iPaaS.com Customer with the correct CustomerNumber, EmailAddress, FirstName, and LastName, plus a child Customer Address (if the donor provided one).
Submit a second donation from the same donor (same email). Verify no second Customer is created; instead, the existing Customer is updated and the Donation links to it.
Submit a donation from a donor with no postal address. Verify the Supporter transfer succeeds and no Customer Address record is created (no error logged).
Manually sync a Supporter using the Supporter ID via the iPaaS.com Manual Sync page. Verify the Customer record is refreshed end-to-end (including the address).
Submit a donation from a donor whose previous donation produced a Customer Address, but this time with a different street address. Verify the new address is added to the Customer (without removing the previous one) — PreventDuplicate semantics should detect the new address as different.
Submit a donation from a non-US donor (e.g., a UK donor). Verify the Country field on the Customer Address arrives as the lowercase alpha-2 code (
gb), confirming the Fundraise Up Known Limitations entry on country-code casing.
Validation Checklist
The Fundraise Up API key supplied in subscription settings has not been revoked and matches the Livemode setting.
For multi-integration subscriptions:
customer_numberownership has been explicitly assigned to one integration (Fundraise Up or another), with documented rationale for the choice.Downstream consumers of the iPaaS.com Customer Address have a strategy for the lowercase ISO 3166-1 alpha-2 country codes (normalize via Lookup Translation, normalize at the destination, or accept lowercase).
The unmapped fields flagged in Duplicate or Conflicting Mappings above have been reviewed; any that must be preserved have DestinationValue preserve-mappings added in a follow-up Update-only collection.
Additional Notes
Operational Notes
API unavailability: If the Fundraise Up API is temporarily unavailable when a Supporter transfer runs (as a Donation prerequisite or Manual Sync), the transfer fails. The error appears in Dashboard / Integration Monitoring / Error Logs. The record can be retried by re-triggering the parent Donation transfer or by using Manual Sync.
Profile changes are donation-driven. Subscribers expecting near-real-time donor profile updates in iPaaS.com should plan around the donation cadence — a supporter whose profile changes in Fundraise Up but who has not made a new donation since the change will not be re-synced automatically. Use Manual Sync for ad-hoc refreshes.
Related Documents
Fundraise Up Donation Mapping Documentation — companion article in the same Mapping Collections sub-collection.