When a donation arrives from ActBlue, two separate deduplication checks run in sequence: one to prevent recording the same webhook twice, and one to match the donor to an existing contact rather than creating a duplicate person record.
Preventing duplicate webhooks
Every incoming ActBlue webhook is stored before any processing begins. The storage step uses the full webhook body as a unique key, so if ActBlue retries a delivery and sends the exact same payload a second time, the insert fails with a duplicate constraint and the webhook is silently dropped. No duplicate donation is created, and ActBlue receives a normal 200 response so it stops retrying. This handles the most common replay scenario where ActBlue's delivery system fires the same event more than once.
Matching the donor to an existing contact
Once the webhook is accepted, the donor information inside it (name, email, phone, address) goes through the same contact-matching logic used for CSV imports. The system loads all existing contacts for your organization into memory and looks for a match using these checks, in priority order:
Email address. If the donor has an email and it matches an existing contact's email exactly, that contact is used.
Full name plus address, for contacts without a matching email. If the donor has a first and last name and an address zip code, and there is an existing contact with the same name and zip who has no email on file, that contact is used.
Full name plus address, for any contact. Same name-and-zip match, but against contacts regardless of whether they have an email.
Phone number and name. If the donor's phone number matches an existing contact and the first and last name also match (normalized for spacing and capitalization), that contact is used.
Name only. If the donor has no email, no valid phone, and no zip code, a name-only match is attempted as a last resort.
If none of these find a match, a new contact record is created.
Preventing duplicate donations
After the contact is identified (or created), the system checks whether this specific donation already exists before inserting it. The primary key for a donation is the ActBlue line item ID, which is ActBlue's own unique identifier for each transaction. If a donation with that line item ID already exists for your organization, the incoming donation is skipped.
If the incoming donation has a line item ID but an existing donation record (typically one imported from a CSV before the ActBlue integration was set up) matches on amount, date, and contact but has no line item ID of its own, the system links them by writing the line item ID onto the existing record. This prevents a duplicate and ensures future replays from ActBlue are also recognized.
Refunds are handled as updates to the original donation row rather than as new records, using the line item ID to find the right donation.
What this means in practice
A donor who gave previously and is now in your contact list will have new ActBlue donations attached to their existing profile. A donor who is completely new will get a new contact record created automatically. If ActBlue sends the same webhook event multiple times (which happens during their retry logic), only one donation record is ever created.