Skip to main content

​
Constituent Data Mapping

This page details the field-level mapping between WeGive donor/company records and Blackbaud Raiser’s Edge NXT constituent records.

​
Object Overview

​
WeGive Donor Object

  • Purpose: Represents individual donors and organizations in the WeGive platform
  • Types: individual and company
  • Unique Identifier: WeGive donor ID, correlated to Blackbaud via the raisers_edge_id column

​
Blackbaud Constituent Object

  • Purpose: Represents individuals and organizations in Raiser’s Edge NXT
  • API Endpoint: constituent/v1/constituents
  • Unique Identifier: Blackbaud constituent ID
Household constituents aren’t part of this integration — see Configuration Options.

​
Individual Constituent Mapping

​
Email

WeGive donors have three email fields (email_1, email_2, email_3) and a preferred_email selector (personal/work/alternate). On push, exactly one email is sent — the one matching preferred_email (defaulting to email_1/“Email Primary” if unset). On pull, only one email comes back from Blackbaud and is written to email_1, with preferred_email set based on the returned email’s type (work if the type contains “Business”, otherwise personal).

​
Phone

Similarly, WeGive has mobile_phone, home_phone, and office_phone. On push, one phone is sent, prioritized mobile → home → office. On pull, one phone comes back and is routed to the matching field based on its Blackbaud type (Cell/Mobile → mobile_phone, Business/Work → office_phone, otherwise → home_phone).
Only US/Canada-format phone numbers (10 digits, or 11 digits starting with 1) are pushed to Blackbaud — an international-format number is skipped with a logged warning, not sent.

​
Address

WeGive’s mailing address is pushed as a single Blackbaud address object (type Home for individuals, Business for companies). State values in the form "SK - Saskatchewan" are parsed down to just the code (SK) before sending.

​
Organization (Company) Constituent Mapping

Companies use the same single email/phone/address handling described above, with company-specific defaults (office_phone → “Phone Business”, address type Business).
Fields like organization type, tax ID, website, industry, and SIC/NAICS codes aren’t part of this mapping — there’s no corresponding code path for them.

​
What Isn’t Mapped

The following aren’t synced by this integration in either direction — there’s no corresponding field mapping or transformation logic for them:
  • Custom fields, tags, or notes — no Attribute Category / Constituent Code / Notes handling exists
  • Communication preferences (email/SMS/mail opt-in) — no do_not_email/do_not_call/do_not_mail sync
  • Household relationships — see Configuration Options
  • Job title, employer, or occupation
  • Suffix, title (Mr./Mrs./Dr.), or nickname

​
Duplicate Handling

Because matching is strictly by raisers_edge_id, a constituent created directly in Blackbaud (outside this integration) has no way to be recognized as the same person on a later WeGive push — it will be created as a new constituent rather than matched or merged. A Redis-backed lock prevents the integration itself from creating duplicate constituents when two pushes for the same new donor race each other.

​
Create vs. Update Payloads

  • Create (no raisers_edge_id yet): sends the full compiled payload — name, email, phone, address, birthdate, gender.
  • Update (raisers_edge_id already set): sends only email and phone, via PATCH — name, address, birthdate, and gender aren’t re-sent on update.

​
Error Handling

A failed constituent push raises an exception, which is logged to the integration’s sync log and surfaces as a failed sync entry — there’s no separate manual-review queue or automated conflict-resolution step beyond that.

​
Getting Help