Fundraise Up Connections and Settings

This document describes every subscription-level setting the Fundraise Up integration exposes, how to obtain the values, and how each setting affects runtime behavior. It is the reference companion to the Installation Instructions.

Item	Value
Mechanism	HTTP `Authorization: Bearer <key>`
OAuth flow	None
Token refresh	None — the key is static until revoked
Live vs test isolation	A live-mode API key cannot read test data and a test-mode key cannot read live data. The Livemode setting must match the kind of key supplied.

The integration does not write any PersistentData on authentication — there is no refresh token, no expiry timestamp, and no per-request signature. The single secret is the bearer token configured at install time.

Subscription Presets

The four subscription presets below are surfaced in the iPaaS.com Subscription page UI when the Fundraise Up integration is selected.

API Url

Item	Value
Required	Yes
Data type	String
Default	`https://api.fundraiseup.com/v1`

The base URL for all Fundraise Up API calls. Fundraise Up uses the same URL for live and test data; environment selection is controlled by the API key and the Livemode preset, not by the URL. Subscribers should normally leave this at the default — overriding it is only appropriate when Fundraise Up Support directs you to a different host for diagnostic reasons.

API Key

Item	Value
Required	Yes
Data type	String (secret)
Default	(empty)

The static bearer token issued from Fundraise Up's Settings > API keys screen. See the Installation Instructions for the step-by-step retrieval procedure.

Security notes:

The full API key value is only displayed once at creation time. Copy it to a password manager before closing the Fundraise Up dialog. To rotate, create a new key, paste it into this preset, save the subscription, then revoke the old key in Fundraise Up.
Each Fundraise Up API key is bound to a single environment (live OR test). Create separate keys for production and staging subscriptions.

Livemode

Item	Value
Required	Yes
Data type	Bool (string `"true"` / `"false"`)
Default	`true`

Indicates whether the subscription is paired with a live-mode key (true) or a test-mode key (false). The Fundraise Up list endpoints (e.g. /donations, /supporters) require the request's livemode filter to match the key's mode — a mismatch returns zero records or an authentication error.

Livemode setting	Pair with API key of type	Use for
`true`	Live	Production subscription
`false`	Test	Staging / UAT subscription

The Livemode preset is required; the integration defaults to true when the setting is missing or unparseable, which matches the preset default. Subscribers configuring a staging subscription must explicitly set this to false.

Donation Poll Days

Item	Value
Required	No
Data type	Numeric (whole days)
Default	`7`

Bounds how far back the first donation poll on a new subscription will look. When a subscription is first installed and Initialize Data (or the first scheduled donation poll) runs, the integration walks pages of Fundraise Up donations newest-first. When it reaches a donation older than the current UTC time minus this number of days, it stops paginating. After that first run establishes a watermark, every subsequent scheduled poll cursors forward from the watermark and Donation Poll Days no longer applies.

Adjust this value at install time based on how much historical donation data should land in iPaaS.com from this subscription:

Default 7 — only the last week of donations is imported. Suitable when subscribers only need ongoing transfers from install date forward.
Larger value (e.g., 365, 730, 1825) — pulls one, two, or five years of historical donations on first run. Set this before triggering Initialize Data; lowering it later will not reduce already-imported records.
0 or blank — disables the lookback bound; the first run will walk all available donations in the Fundraise Up account (longest possible historical import).

Changing this setting after the initial poll has completed has no further effect.

Platform Throttle / Concurrency Presets

These four presets are platform-standard iPaaS.com subscription controls. They appear on every iPaaS.com subscription, not just Fundraise Up. They affect how the iPaaS.com scheduler dispatches work; they do not override Fundraise Up's own server-side rate limits (described below).

Setting	Default	Notes
API Throttle Limit	`0` (Unlimited)	Per-second request rate cap. Leave at the default — this preset enforces a throughput rate, not parallelism, and Fundraise Up's rate limit is concurrency-based (see below). Tighten only if Fundraise Up Support specifically asks you to slow the request rate.
API Throttle Seconds	`0` (Unlimited)	The measurement window for API Throttle Limit.
Concurrent Connections	`1`	Controls how many requests this subscription dispatches in parallel. Set to `1` (recommended — single-threaded, matches Fundraise Up's published guidance) or `2`. Do not exceed `2`. See "Fundraise Up API rate limits" below for the 3-parallel account-wide cap that motivates this.
Concurrent Batch Executions	`10`	Reserved — batch execution is not currently exercised by this integration.

Fundraise Up API rate limits

Fundraise Up enforces a concurrency-based request limit, not a throughput limit.

3 parallel API requests per Fundraise Up account — across all endpoints and all API keys (live and test combined) tied to the same account.
Requests beyond the third in flight are rejected immediately with HTTP 429 Too Many Requests and the error code concurrent_requests_limit_exceeded. There is no per-second quota and no fixed reset window — a slot frees the moment a prior request completes.
Fundraise Up's published guidance is to keep your integration single-threaded: dispatch requests sequentially, one after the next, rather than in parallel. (Fundraise Up updated its rate-limit policy in June 2025 from per-second/per-minute thresholds to this concurrency-based model.)

How this maps to the iPaaS.com subscription:

Concurrent Connections is the correct preset for this constraint. Set it to 1 (the default — single-threaded, matches Fundraise Up's recommendation) or 2 (still safely below the 3-parallel cap with one slot of headroom). Do not exceed 2.
API Throttle Limit and API Throttle Seconds enforce a per-second request rate, not parallelism — they cannot defend against a concurrency limit. Leave them at their defaults (Unlimited / Unlimited) unless Fundraise Up Support specifically asks you to throttle the request rate.
The 3-parallel cap is account-wide across all keys. If two iPaaS.com subscriptions point at the same Fundraise Up account (e.g., staging + production using test-mode and live-mode keys), the sum of their Concurrent Connections values must stay at or below 3. Parent and subaccounts are counted separately by Fundraise Up, so subscriptions targeting distinct subaccounts each get 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.

For authoritative details, see Fundraise Up: Rate limits in the Fundraise Up API documentation.

PersistentData

The integration stores one Persistent Data key per subscription. Persistent Data is server-side state on the subscription record; it is not visible in the subscription UI and survives subscription edits.

Key	Written by	Purpose	Lifecycle
`Poll_Donations_LastId`	The scheduled donation poll after a successful run	The id of the most recently processed donation, used as the pagination cursor on the next poll	Persists across polls. The scheduled donation poll and Initialize Data are separate operations with different purposes: the scheduled poll runs on the configured cadence and advances the watermark forward; Initialize Data paginates through historical donations (bounded by the Donation Poll Days preset on the first run) and seeds the watermark. Both are subscriber-controllable from Dashboard / Integration Monitoring / Events — schedule the cadence, trigger an on-demand poll, or re-run initialization. For a targeted historical refresh that does not re-process the entire history, the bulk sync using Postman pattern is the supported workflow.

No other PersistentData is written. Authentication state (the API key) lives in subscription settings, not PersistentData.

Scopes Registered by the Integration

The integration registers the following iPaaS.com scopes against the Fundraise Up integration:

Scope name	Mapping Collection Type	Action
`transaction/poll`	TRANSACTION	POLL
`transaction/created`	TRANSACTION	CREATED
`transaction/updated`	TRANSACTION	UPDATED
`customer/created`	CUSTOMER	CREATED
`customer/updated`	CUSTOMER	UPDATED

These are the scope strings visible in the iPaaS.com platform's event and activity views when a Fundraise Up subscription triggers a donation or customer transfer.