Skip to main content

​
Configuration Options

​
Authentication Settings

​
Data Type Toggles

Unlike some other CRM integrations, Bloomerang genuinely has independent per-object toggles — these are real, functioning settings:
Only successful transactions push — a failed, refunded, or still-processing transaction is never sent to Bloomerang. Updates to an already-pushed transaction only happen for WeGive-originated transactions (transactions with a correlation_id); a transaction Bloomerang created and WeGive later pulled in isn’t pushed back on change.

​
Default Fund

This is a real fallback, not a hard requirement — if a transaction’s fund already has a bloomerang_id, that fund is pushed and used directly; the default only applies as a fallback.

​
Payment Method Mapping

Payment method on push is derived automatically from the transaction’s source, not separately configurable:

​
Matching and Duplicate Prevention

Constituent/transaction/fund creation is protected by a Redis lock per record — matching is by bloomerang_id only, not by email or name. On pull, a record already linked by its Bloomerang ID is updated rather than re-created.
If Bloomerang reports a transaction’s ID no longer exists (e.g. after a constituent merge in Bloomerang deleted it), WeGive clears the stale link and re-pushes it as new — but only when Bloomerang’s error message specifically confirms that transaction ID is gone. Any other 404 (a stale fund or donor ID embedded in the same request) is treated as a real failure rather than silently “healed,” to avoid creating a duplicate gift.

​
Getting Help