​

DonorPerfect Data Mapping Overview

The WeGive DonorPerfect integration maps a fixed, hardcoded set of fields between the two systems — there is no customer-configurable field mapping and no custom-field support.

​

Integration Architecture

​

Data Synchronization Types

Pull Operations (DonorPerfect → WeGive):

• Import donor profiles (email-required)
• Import gift/transaction records
• Runs once daily, incrementally by created_date then modified_date

Push Operations (WeGive → DonorPerfect):

• Create/update donor profiles
• Create/update gift records
• Create/update recurring-gift pledges (push-only, no pull-back)
• Create GL codes for funds (push-only, no pull-back)
• Push happens as each WeGive record is created or updated — this part is genuinely real-time

​

Core Data Entities

The integration handles four object types:

​

Donors (Individuals & Organizations)

DonorPerfect table: dp Maps a fixed set of contact fields (name, email, phone, address) — see Donor Mapping for the exact list. No custom fields, donor classification/preference data, or communication-preference fields are mapped.

​

Transactions (Gifts)

DonorPerfect table: dpgift Synchronizes gift amount, date, fund/GL code, and a fixed set of tribute/narrative fields. See Transaction Mapping.

​

Recurring Donations (Pledges)

DonorPerfect table: dpgift (record type Pledge, via dp_savepledge) — push-only See Recurring Donation Mapping.

​

Funds (GL Codes)

DonorPerfect table: dpcode — push-only See Fund Mapping.

​

Data Transformation Rules

​

Format Conversions

​

Field Validation Rules

Donor pull (importDonor()):

• A DonorPerfect row missing an email key, with an empty email, or one that fails filter_var(..., FILTER_VALIDATE_EMAIL) is skipped entirely — this is the only real validation gate
• Matching to an existing WeGive User is by exact email string match

Gift pull (importGift()):

• A gift with amount of 0/'0' is skipped
• A gift already recognized as WeGive-originated (user_id = 'WeGive' or a WG:txn: reference prefix) is skipped
• A gift matching an already-known dp_id for that donor is skipped

​

Identity Management

• Donors: dp_id is the only correlation key. There is no email or name matching used to link an existing DonorPerfect donor on push — a donor without a stored dp_id will always create a new DonorPerfect person.
• Gifts: dp_id correlation, plus a WG:txn:<transaction id> reference token stamped on every WeGive-originated gift. This reference token is used for a specific recovery mechanism: if a gift push returns a 2xx response with no id field (DonorPerfect may still have created the record), the integration looks up the gift by this reference token before retrying, to avoid creating duplicate gift records.
• Funds: dp_id correlation (set to the WeGive fund’s own numeric id, not a value returned by DonorPerfect).

​

Data Enrichment

The only “enrichment” this integration performs:

• A fixed gift narrative: "Online gift through WeGive", with " (Anonymous)" appended for anonymous transactions
• Every pushed record stamped user_id = "WeGive" — this doubles as both an audit marker and the mechanism that prevents re-importing WeGive’s own pushes as new pull records

​

Synchronization Timing

Push (real-time): Donor, gift, pledge, and fund pushes happen as the corresponding WeGive record is created or updated. Pull (once daily): Donors and gifts are pulled once per day, via two incremental passes (created_date then modified_date), paging forward by donor/gift id.

​

Error Handling and Recovery

​

Monitoring

​

Best Practices

​

Before Integration

1. Clean duplicate donor records in DonorPerfect — WeGive’s own dedup is dp_id-only, so pre-existing DonorPerfect-side duplicates aren’t resolved by this integration
2. Ensure donor emails are present and valid in DonorPerfect — an invalid/missing email means that donor never imports
3. Set up GL codes in DonorPerfect before enabling push, since a fund without a dp_id doesn’t attribute a gift’s GL code cleanly

​

Ongoing Maintenance

• Check Sentry (not the WeGive dashboard) for sync failures
• Review the field-mapping pages below for the exact, fixed set of fields synced — there’s no way to add more without an engineering change

​

Detailed Mapping Documentation

​

Support

For questions about data mapping, contact our support team at [email protected]. Custom field mappings are not currently supported for this integration.