> ## 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.

# Integration Nuances

> Important behaviors and edge cases of the WeGive Bloomerang integration

# Integration Nuances

This page documents behaviors of the WeGive Bloomerang integration that aren't obvious from the configuration screen alone.

## Matching Is by bloomerang\_id Only

There's no email or organization-name matching anywhere in this integration. A donor, transaction, or fund is matched to its Bloomerang counterpart strictly by the stored `bloomerang_id` — nothing else. A record with no `bloomerang_id` yet is always created as new, even if a record with the same email or name already exists in Bloomerang.

## Round-Trip Detection for Transactions

When WeGive pushes a transaction to Bloomerang, it stamps a machine-readable marker on the transaction's `Note` field: `[wg-rt:<transaction_id>]`. On a later pull, if a transaction doesn't match any existing `bloomerang_id`, the integration checks this marker (or the legacy `WeGive ID: <id>` format, still recognized for records pushed before the marker changed) to link the pulled Bloomerang record back to the original WeGive transaction — without creating a duplicate.

<Note>
  Once this round-trip match happens, the integration only links the two records — it deliberately does not overwrite the transaction's amount, date, or fund from the Bloomerang side. WeGive is treated as the source of truth for a transaction it originated.
</Note>

## Source-of-Truth Guard on Pull

A transaction with a `correlation_id` (meaning it originated in WeGive) is never overwritten by a pull — its amount, date, and description stay exactly what WeGive set. Pull only fills in these fields for transactions WeGive doesn't already have full data for. There's also a defensive check for future-dated pending recurring installments: a Bloomerang pull will never rewrite the amount or pending status of a scheduled charge that hasn't fired yet.

## Payment Method Mapping Is 3 Values, Not 5

Pushed transactions map to exactly three Bloomerang `Method` values, derived from `source_type`:

| WeGive `source_type` | Bloomerang `Method` |
| - | - |
| `card` | `CreditCard` |
| `bank` | `Eft` |
| anything else | `None` |

There's no separate mapping for checks or cash — those fall into `None` along with every other payment type.

## Only One Fund Designation Per Transaction

Every pushed transaction sends exactly one `Designations` entry — split-fund/multi-fund gifts aren't supported by this integration. If a transaction's fund has no `bloomerang_id` yet, the configured Default Fund ID is used as a fallback designation instead.

## Name Handling

* If a WeGive individual donor has no first or last name, `FNU` (First Name Unknown) / `LNU` (Last Name Unknown) are sent instead — Bloomerang requires a name on every Constituent.
* Company donors send `FullName` and an `Organization` contact type.

## Address Handling

* Only a mailing address syncs (both directions) — there's no separate billing-address handling.
* Country defaults to `United States` on pull if Bloomerang doesn't supply one.
* A US state code that isn't valid for the donor's country is sent as an empty string rather than the (invalid) value, since Bloomerang rejects the request outright with a 400 if it receives one.

## 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.