Skip to main content

​
Gift Data Mapping

This page details the field-level mapping between WeGive transaction records and Blackbaud Raiser’s Edge NXT gift records.

​
Core Fields

​
Gift Type

Determined automatically, not a direct field mapping:
  • RecurringGiftPayment — when the transaction’s parent scheduled donation already has a raisers_edge_id
  • PledgePayment — when the transaction’s parent pledge already has a raisers_edge_id
  • Other — when the transaction isn’t tax-deductible
  • Donation — default

​
Payment Method

There’s no mapping for wire transfers, PayPal, or Venmo as distinct payment method types.

​
Fund and Campaign Attribution

  • Sent as gift_splits, one entry per fund allocation (or a single split for the transaction’s primary fund if fund allocations aren’t in use)
  • Each split can carry an appeal_id — sourced from the transaction’s linked campaign fundraiser’s raisers_edge_id, or the integration’s configured default appeal if no fundraiser-specific one exists
  • A campaign ID is never sent on the gift split — campaign attribution on the Blackbaud side happens only via the appeal, not a direct campaign link
Creating a gift requires at least one fund with a linked raisers_edge_id — if none exists, the push fails outright rather than creating an un-designated gift.

​
Custom Fields

Two specific custom fields are written on gift creation — not a general-purpose custom-field mapping:

​
Soft Credits

Soft credits push to Blackbaud as part of the gift payload (one entry per soft credit, requiring the soft-credited donor to already have a raisers_edge_id). This is push-only — there’s no corresponding pull-side soft-credit handling.

​
Linked Gifts (Pledges and Recurring Gifts)

When a transaction is a pledge payment or recurring gift payment, the parent pledge’s or scheduled donation’s raisers_edge_id is sent as a linked_gifts reference — and read back the same way on pull to re-link an incoming gift to its WeGive pledge/recurring plan record.

​
Create vs. Update

  • Create: full payload — type, date, amount, constituent, fund splits, custom fields, linked gifts, soft credits.
  • Update (PATCH, gift already has a raisers_edge_id): only amount, date, and payment details are re-sent. Fund splits, custom fields, and soft credits aren’t re-sent on update.

​
Pull Behavior: WeGive-originated gifts are protected from being overwritten

If a WeGive transaction already has a correlation_id (meaning WeGive itself processed the payment) — or is a future-dated pending gift awaiting its scheduled charge — a pull from Blackbaud will not overwrite its amount, date, or status. Only the raisers_edge_id correlation link gets set if missing. This protects against a Raiser’s Edge-side edit accidentally reversing a real WeGive charge or amount. For gifts where Blackbaud genuinely is the source of truth (no correlation_id), pull maps:
Only the single highest-amount split determines the transaction’s fund/campaign on pull — a multi-fund gift doesn’t create multiple WeGive fund-allocation rows automatically unless Raiser’s Edge is genuinely the source of truth for that gift.

​
What Isn’t Mapped

No code path exists for: acknowledgment/thank-you status, tax receipt status or amount, tribute/memorial/honor gift information, bank routing/account number details, processing fees or net amount, or event/fundraiser ticket participation.

​
Error Handling

A failed gift push raises an exception, logged to the integration’s sync log. There’s no separate manual-review queue beyond that.

​
Getting Help