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

# Gift Mapping

> Field-level mapping between WeGive transactions and Blackbaud Raiser's Edge NXT gifts

# Gift Data Mapping

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

## Core Fields

| WeGive Field | Blackbaud Field | Direction | Notes |
| - | - | - | - |
| `raisers_edge_id` | Gift ID | Both | Correlation key |
| `amount` | `amount.value` | Both | Converted between cents (WeGive) and dollars (Blackbaud) |
| `created_at` | `date` | Push only | Not re-sent on update, not pulled back if WeGive originated the transaction (see below) |
| `owner` (donor) | `constituent_id` | Both | Matched by the donor's `raisers_edge_id` |

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

| WeGive Signal | Blackbaud `payment_method` | Notes |
| - | - | - |
| `payment_type = 'cash'` | `Cash` | |
| `payment_type = 'check'` | `PersonalCheck` | `check_number` also sent |
| card-sourced transaction | `CreditCard` | subtype: "Gift - Credit Card" |
| bank-sourced (ACH/PAD) transaction | `Cash` | subtype: "Gift - Direct Debit" — Blackbaud has no dedicated bank-transfer method here |
| organization-sourced | `Other` | |

<Note>
  There's no mapping for wire transfers, PayPal, or Venmo as distinct payment method types.
</Note>

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

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

## Custom Fields

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

| Blackbaud Custom Field Category | Source |
| - | - |
| `WeGive_TransactionID` | The WeGive transaction ID, always set |
| `Donor_Comments` | The donor's supporter-inputted note, if present (truncated to 255 characters) |

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

| Blackbaud Field | WeGive Field |
| - | - |
| `amount.value` | `amount` (converted to cents) |
| `date` | `created_at` / `initiated_at` |
| `gift_status` | `status` (Active/Completed → success, Held → pending, Cancelled/Terminated → failed, anything else → pending) |
| `type` | `is_tax_deductible` (false only if type is `Other`) |
| `is_anonymous` | `anonymous` |
| `gift_splits` (highest-amount split) | `fund` / `campaign` |

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

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

* **WeGive Support**: [support@wegive.com](mailto:support@wegive.com)
* **Blackbaud Sky API Gift Docs**: [Sky API Documentation](https://developer.blackbaud.com/skyapi/)


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