Skip to main content

​
Data Mapping Overview

This page describes how the WeGive Bloomerang integration synchronizes donors, transactions, and funds — the three object types this integration supports.

​
Object Mapping Summary

Detailed field-level mappings live on the per-object pages:
Campaigns are not currently synced — that code path exists but is fully commented out. There’s no separate Address/Phone/Email object; those are fields embedded in the Constituent payload.

​
Correlation Fields

WeGive tracks the corresponding Bloomerang record using a single column per object:

​
Matching Logic

All matching is by bloomerang_id — there’s no email, organization-name, or address-based matching anywhere in this integration. Transactions have one additional path: if a pulled transaction doesn’t match an existing bloomerang_id, the integration checks the transaction’s Note field for a round-trip marker WeGive itself wrote on push ([wg-rt:<id>], or the legacy WeGive ID: <id> format) — this links a transaction Bloomerang has already stored back to the original WeGive record instead of creating a duplicate. See Integration Nuances for details.

​
API Endpoints Used

All requests use base URL https://api.bloomerang.co/v2 with an X-API-KEY header. Every write is a single-record call — there’s no batch/bulk endpoint usage in this integration.

​
Pull (query) endpoints

Pulls page through Bloomerang’s list endpoints (50 records per page), filtered by lastModified:
  • GET constituents
  • GET funds
  • GET transactions (queried once per type: Donation, PledgePayment, RecurringDonationPayment)

​
Push endpoints

  • POST constituent, PUT constituent/{id}
  • POST fund, PUT fund/{id}
  • POST transaction, PUT transaction/{id}

​
Reliability

  • Retries: Automatic retry with exponential backoff on failure (shared HttpClientWithRetry mechanism), including 429 rate-limit responses.
  • Timeout: 120 seconds per request.

​
Amount Handling

WeGive stores monetary amounts in cents; Bloomerang uses dollars. Amounts are divided by 100 on push and multiplied by 100 on pull.

​
Data Precedence

  • Push: WeGive data wins — an update overwrites the Bloomerang record with current WeGive values.
  • Pull: A transaction WeGive itself originated (has a correlation_id) is never overwritten by a pull — amount, date, and description stay whatever WeGive set. Other records fill in from Bloomerang’s data.

​
Getting Help