Skip to main content

FundraiseUp Connector (Technical Documentation)

Written by Philippe Trussart

Overview

The Fundraise Up connector provides read-only access to fundraising data through the Fundraise Up REST API.

It retrieves:

  • donations

  • recurring_plans

  • supporters

  • events

All records use id as the unique key. The connector only retrieves live production data during normal syncs; Fundraise Up test-mode records are excluded.

Authentication

The connector requires:

api_key

Requests are authenticated using a Bearer token:

Authorization: Bearer {api_key}

The API base URL is:

https://api.fundraiseup.com

The connection test performs:

GET /v1/donations?livemode=true

and succeeds when Fundraise Up returns HTTP 200.

API Requests

The connector uses GET requests only. It does not use POST, PUT, PATCH, or DELETE.

Data

Endpoint

Method

Donations

/v1/donations

GET

Recurring plans

/v1/recurring_plans

GET

Supporters

/v1/supporters

GET

Events

/v1/events

GET

Normal data requests also include:

limit=100 livemode=true

Pagination uses Fundraise Up's cursor-style starting_after parameter. The ID of the final record on the current page becomes the cursor for the next request, and paging continues while the API returns has_more=true.

Sync Behavior

The connector does not maintain an incremental bookmark or last-modified timestamp.

Every sync starts at the beginning of the selected endpoint and pages through the available live records:

GET /v1/{endpoint}?limit=100&livemode=true

followed by:

GET /v1/{endpoint}?limit=100&starting_after={last_id}&livemode=true

until has_more becomes false.

As a result:

  • Existing records can be returned again on every run.

  • Sync duration generally grows as the amount of Fundraise Up data increases.

  • Consumers should use id to identify the same source record across repeated syncs.

Live vs. Test Data

Normal syncs always add:

livemode=true

This intentionally excludes donations, supporters, recurring plans, and events created in Fundraise Up's test environment.

If a record is visible in Fundraise Up but not appearing through the connector, confirm that it is a live-mode record rather than test data.

Schema & Nested Data

The connector combines a predefined base schema with dynamic schema discovery.

Before syncing a table, it requests up to 10 records:

GET /v1/{endpoint}?limit=10

and examines the fields present in those records. Known fields retain their predefined types, while previously unknown fields have their type inferred from the sample data.

If schema discovery fails or no sample records exist, the connector falls back to its predefined schema.

Fundraise Up also returns substantial nested data. Fields such as the following may contain structured JSON:

  • account

  • campaign

  • consent

  • custom_fields

  • designation

  • device

  • payment

  • recurring_plan

  • supporter

  • tribute

  • utm

  • questions

Consumers may need to parse these fields for detailed reporting.

Deletes

The connector does not explicitly synchronize deletes.

There is:

  • No deleted-record endpoint used.

  • No DELETE request.

  • No delete-event processing.

  • No source-to-destination comparison to identify records that have disappeared.

If a Fundraise Up record is removed and stops being returned by the API, the connector does not explicitly communicate that deletion downstream.

Rate Limits & Retries

The connector deliberately slows API traffic by pausing periodically while paging through records.

When an API request returns a non-200 response, it retries the request up to:

3 times

before stopping the current sync operation.

This behavior is primarily intended to reduce the impact of Fundraise Up API rate limiting.

Known Limitations & Notable Behavior

  • Every run re-reads the available dataset. There is no incremental bookmark, so large Fundraise Up accounts will require progressively more API calls as data accumulates.

  • Only live-mode data is synchronized. Test donations and other test records are intentionally excluded with livemode=true.

  • Deletes are not propagated. Removing a record from Fundraise Up does not generate a downstream deletion.

  • Dynamic schema discovery is sample-based. Only the first 10 records are inspected when determining which fields currently exist. A rarely populated field that does not appear in those sample records may not be included in the discovered schema for that run.

  • Schema discovery and actual syncing use slightly different requests. Data syncs explicitly specify livemode=true, while the schema-discovery request does not. This can potentially cause the discovered schema to be influenced by records that differ from the live dataset being synchronized.

  • Empty values are normalized to NULL. The current data-cleaning logic treats any "empty" value as null. This includes values such as false, numeric 0, string "0", and empty collections. Consumers should therefore be cautious when distinguishing a true zero/false value from a missing value.

  • Unexpected API failures can result in a partial sync. If an exception occurs while paging, the connector stops fetching additional pages. Records already retrieved during that run remain processed, so an unexpectedly low record count should be investigated rather than assumed to represent the complete source dataset.

  • Nested objects are not fully relationalized. Significant fundraising, payment, supporter, campaign, consent, attribution, and custom-field information is contained in structured JSON fields and may require downstream parsing.

Did this answer your question?