> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wegive.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Data Mapping Overview

> How WeGive donors, transactions, and funds map to Bloomerang CRM objects

# 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

| WeGive Object | Bloomerang Object | Push (WeGive → Bloomerang) | Pull (Bloomerang → WeGive) |
| - | - | - | - |
| Donor (individual) | Constituent (Individual) | Create/update | Create/update |
| Donor (company) | Constituent (Organization) | Create/update | Create/update |
| Transaction | Transaction | Create/update (successful only) | Create/update |
| Fund | Fund | Create/update | Create/update |

Detailed field-level mappings live on the per-object pages:

* [Constituent Mapping](./constituent)
* [Transaction Mapping](./transaction)
* [Fund Mapping](./fund)

<Note>
  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.
</Note>

## Correlation Fields

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

| WeGive Record | Column | References |
| - | - | - |
| Donor | `bloomerang_id` | The Bloomerang `Constituent` |
| Donor | `bloomerang_account_id` | The Constituent's `AccountNumber` |
| Transaction | `bloomerang_id` | The Bloomerang `Transaction` |
| Transaction | `bloomerang_number` | The Transaction's `TransactionNumber` |
| Fund | `bloomerang_id` | The Bloomerang `Fund` |

## 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](/external/onboarding/bloomerang/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

* **WeGive Support**: [support@wegive.com](mailto:support@wegive.com)
* **Bloomerang API Documentation**: [bloomerang.co/features/api](https://bloomerang.co/features/api/)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.