Charity reference data in a donor CRM
Connect meaning before connecting systems: preserve identity, units, source context, and the distinction between charity records and donor information.
A reference model, not a live CRM
DonorAPI.com is a static charity research publication. It does not store donor contacts, manage gifts, or synchronize with a CRM. This page explains how a team could think about charity reference data when designing its own system, while keeping the historical source observations distinct from operational decisions.
Keep the entities distinct
An organization record identifies a charity. A supporter record identifies a person or organization in your own system. A gift record describes an event. An internal review record describes work your team has performed. The uploaded file provides charity fields, not the other three entities. A sound design does not manufacture those missing relationships.
A proposed mapping structure
For the charity-reference record, preserve source name, EIN, recorded state, source category, source subcategory, source size label, the three historical scores, source financial fields, and collection context. Treat the EIN as text. Use a separate internal key if your application requires one.
Keep your own review status outside the source fields. “Reviewed internally,” “current status checked,” and “historical record imported” describe different actions and should not share an ambiguous verification flag. Record what source supports a check and when it was performed.
Make transformations inspectable
Expense shares are stored as fractions and displayed as percentages. Financial totals are rendered in US dollars. The readable size name Mid-sized corresponds to the original value mid. Missing values remain distinguishable from zeroes. Preserve these mappings explicitly rather than allowing an interface convention to become undocumented source data.
Do not infer a donor from a charity
The presence of a charity in a cause category says nothing about an individual donor’s preferences, consent, contact information, or giving history. The historical leader field is not a prospect list. Keep public organizational reference data separate from private relationships that your team may manage under its own policies and obligations.
Use the collection for the questions it supports
The directory can help people identify an organization, read its supplied mission, and understand its historical record. It cannot supply a current payment destination, verify present eligibility, or explain the allocation of a future gift. Put those requirements into separate workflows rather than deriving them from a source score.
Read further
The full mapping guide develops these design choices with examples. The data dictionary preserves every field definition, while the Donor API page explains the static publication’s resource model. Review source provenance and reuse notes before treating any technically accessible data as licensed for a new distribution.