How to Verify a U.S. Charity Programmatically

Q: What identifier should I use to verify a U.S. charity programmatically?

Use the organization's EIN. Send the EIN to the single-EIN `nonprofitcheck` endpoint, then confirm the returned `ein` and `organization_name` before applying downstream verification logic.

Q: Is `bmf_status: true` enough to mark a charity as verified?

Not by itself. `bmf_status` indicates BMF presence. Your application may also need BMF classification, Pub. 78, foundation type, revocation, OFAC and source-freshness signals depending on the workflow.

Q: What should I do if IRS BMF and Pub. 78 disagree?

Review `irs_bmf_pub78_conflict` together with the relevant BMF and Pub. 78 fields and their source dates. Preserve the conflict in application logic rather than silently collapsing the records into one status.

Direct answer

To verify a U.S. charity programmatically, send its EIN to Pactman Nonprofit Check Plus API and evaluate the returned IRS, revocation and sanctions signals in your application.

Start by matching ein and organization_name, then review bmf_status, bmf_subsection, subsection_description and exempt_status_code. Evaluate pub78_verified and organization_types when contribution eligibility matters, review foundation classification, check revocation and reinstatement fields, evaluate ofac_status, and account for irs_bmf_pub78_conflict and source freshness before applying your application's final verification rule.

Recommended verification flow

Normalize the EIN. Remove spaces or dashes so 12-3456789 becomes 123456789.
Call the single-EIN API. Use the nonprofitcheck endpoint when verifying one charity.
Match the returned charity. Confirm ein and organization_name correspond to the organization your application intended to check.
Evaluate IRS BMF status. Review bmf_ein, bmf_status, bmf_subsection, subsection_description and exempt_status_code.
Evaluate Pub. 78 when relevant. Review pub78_ein, pub78_verified, most_recent_pub78 and the organization_types array.
Preserve foundation classification. Review foundation_code, foundation_code_description, foundation_509a_status, foundation_type_code and foundation_type_description.
Check revocation and reinstatement. Review revocation_code, revocation_date and reinstatement_date.
Review sanctions screening. Evaluate ofac_status independently from IRS tax status.
Handle conflicts and freshness. Review irs_bmf_pub78_conflict, most_recent_bmf, most_recent_pub78 and organization_info_last_modified.
Handle special cases explicitly. Review group_exemption, pub78_church_message and bmf_church_message when group-exempt or religious organizations require additional context.

Example request(s)

curl --request GET \
  --url https://entities.pactman.org/api/entities/nonprofitcheck/v1/us/ein/YOUR_EIN \
  --header 'Authorization: Bearer YOUR_API_KEY'

Implementation note: The endpoint name above reflects the Pactman single-EIN Nonprofit Check endpoint used in Pactman's Production/Customer Environment.

curl --request POST \
  --url https://entities.pactman.org/api/entities/nonprofitcheckbulk/v1/us/eins \
  --header 'accept: application/json' \
  --header 'Authorization: Bearer YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '[
    "YOUR_EIN_1",
    "YOUR_EIN_2",
    "YOUR_EIN_3",
    "YOUR_EIN_4",
    "YOUR_EIN_5"
  ]'

Implementation note: The endpoint name above reflects the Pactman single-EIN Nonprofit Check endpoint used in Pactman's Production/Customer Environment.

What your application should evaluate

Signal	Why it matters	Typical application decision
`ein` / `organization_name`	Confirms the API response belongs to the charity your application intended to verify.	Continue only when the returned identity matches the requested charity.
`bmf_status` and BMF classification	`bmf_status` indicates whether the organization appears in the IRS Business Master File data used by Pactman, while `bmf_subsection`, `subsection_description` and `exempt_status_code` describe exemption and classification.	Use as core IRS-status inputs to your verification rule.
`pub78_verified`	Indicates whether the organization is included in the most recent Publication 78 data used by Pactman.	Use when Publication 78 inclusion or contribution eligibility matters to the workflow.
`organization_types`	Contains Pub. 78 contribution information, including `organization_type`, `deductibility_limitation` and `deductibility_status_description`.	Preserve the returned contribution classification instead of reducing Pub. 78 to only a boolean.
Foundation classification	`foundation_code`, `foundation_code_description`, `foundation_509a_status`, `foundation_type_code` and `foundation_type_description` distinguish public-charity and private-foundation context.	Apply business rules appropriate to the returned foundation classification.
Revocation fields	`revocation_code`, `revocation_date` and `reinstatement_date` expose revocation-related history.	Review reinstatement before treating historical revocation information as current disqualification.
`ofac_status`	Returns the organization's OFAC SDN screening result in the Pactman response.	Apply the application's sanctions policy separately from IRS eligibility logic.
`irs_bmf_pub78_conflict`	Indicates whether BMF and Pub. 78 differ on private-foundation classification.	Route conflicts through source-aware logic instead of silently selecting one source.
Source freshness	`most_recent_bmf`, `most_recent_pub78` and `organization_info_last_modified` provide timing context for the returned data.	Use them to determine whether the verification result is current enough for the workflow.

Example decision logic

A practical programmatic verification rule might mark a charity as ready for the next workflow step only after the application has:

matched ein and organization_name to the intended organization;
evaluated the required BMF status and classification signals;
evaluated pub78_verified and organization_types when Pub. 78 or contribution eligibility matters;
preserved the returned foundation classification;
reviewed revocation and reinstatement information;
evaluated ofac_status;
handled any irs_bmf_pub78_conflict; and
considered source freshness before treating the result as current.

The supplied bulk sample provides a concrete example. For EIN "680343125", Pactman returns bmf_status: true, bmf_subsection: "03", subsection_description: "501(c)(3) Public Charity", pub78_verified: true, foundation_type_code: "pc" and foundation_type_description: "Public charity described in section 509(a)(1) or (2)". The same record has revocation_code, revocation_date and reinstatement_date as null, while ofac_status states that the organization was not included in the OFAC SDN list.

Important: Do not hard-code one universal definition of "verified charity." A donation platform, grantmaking system, fintech product, payroll-giving application or compliance workflow may require different combinations of the same underlying signals.

Why use a consolidated nonprofit verification API?

Programmatic charity verification otherwise requires an application to ingest, normalize and compare multiple nonprofit-compliance sources. The application must also preserve differences between tax-exempt classification, Pub. 78 contribution information, revocation history, foundation type and sanctions screening.

Pactman Nonprofit Check Plus returns those signals in one normalized response. The supplied single-EIN and bulk samples use the same current 43 organization-level fields, so the same verification logic can be reused for individual checks and higher-volume workflows.

One normalized response

Evaluate organization identity, IRS BMF, Pub. 78, foundation classification, revocation and OFAC screening from one response model.

Separate source signals

Keep bmf_status, pub78_verified, foundation fields, revocation fields, ofac_status and irs_bmf_pub78_conflict distinct so your application retains the meaning of each source.

Reusable compliance rules

Build one verification layer that can support onboarding, donations, grantmaking, donor-advised funds and recurring nonprofit reviews while allowing each workflow to apply different acceptance criteria.

Developer-friendly automation

Move charity verification into application code so checks can run at the point of onboarding or transaction instead of requiring a person to manually compare IRS and sanctions information.

Frequently asked questions

What identifier should I use to verify a U.S. charity programmatically?

Use the organization's EIN. Send the EIN to the single-EIN nonprofitcheck endpoint, then confirm the returned ein and organization_name before applying downstream verification logic.

Is `bmf_status: true` enough to mark a charity as verified?

Not by itself. bmf_status indicates BMF presence. Your application may also need BMF classification, Pub. 78, foundation type, revocation, OFAC and source-freshness signals depending on the workflow.

Can I verify more than one charity programmatically?

Yes. Pactman's bulk workflow is designed for multiple EINs. The same organization-level response fields used by the single-EIN workflow are also present in the supplied bulk response, allowing the same evaluation logic to be reused across batch checks.

What should I do if IRS BMF and Pub. 78 disagree?

Review irs_bmf_pub78_conflict together with the relevant BMF and Pub. 78 fields and their source dates. Preserve the conflict in application logic rather than silently collapsing the records into one status.

Next step

Use the Pactman API response as a normalized verification object in your application, then map its BMF, Pub. 78, foundation, revocation, OFAC, conflict and freshness signals to the business rules required by your product.

Ready to automate charity verification?

Use Pactman Nonprofit Check Plus API to connect U.S. charity verification directly to your application.

Get an API Key →