How to Verify Whether a Revoked Nonprofit Has Been Reinstated

Recommended verification flow

1. Normalize the EIN.
2. Send the EIN to the Nonprofit Check Plus API.
3. Confirm the organization.
4. Confirm revocation history. Review revocation_code and revocation_date.
5. Check for reinstatement. Review reinstatement_date.
6. Compare event dates. Preserve chronology instead of overwriting the revocation event.
7. Review BMF presence. Check bmf_status.
8. Review Pub. 78 presence. Check pub78_verified.
9. Check freshness. Review most_recent_bmf, most_recent_pub78 and organization_info_last_modified.
10. Apply your current-status policy. Distinguish historical revocation from later reinstatement.

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 bulk-EIN Nonprofit Check endpoint used in Pactman's Production/Customer Environment. You can have at most 50 EINs in a bulk-EIN Nonprofit Check endpoint request.

What your application should evaluate

Example decision logic

A reinstatement workflow might:

• require a populated revocation_date before treating the record as having known revocation history;
• check reinstatement_date;
• if both dates are present, preserve both and compare their order;
• retain revocation_code;
• review BMF and Pub. 78 separately; and
• use source freshness before making the final current-status decision.

The supplied current examples have null revocation_date and reinstatement_date, so they do not provide a positive reinstatement example. This article therefore does not invent a sample reinstatement date.

Important: A reinstatement date should not erase the earlier revocation event in your stored data. Preserve both fields for audit and policy logic.

Why use a consolidated nonprofit verification API?

Reinstatement verification can require revocation history, reinstatement date, BMF presence, Pub. 78 presence and freshness context.

Pactman Nonprofit Check Plus returns those signals in one normalized response.

One normalized response

Evaluate revocation and reinstatement history together with supporting IRS signals.

Separate source signals

Keep revocation history, reinstatement, BMF and Pub. 78 data distinct.

Reusable compliance rules

Apply one reinstatement policy across donations, grants, onboarding and recurring reviews.

Developer-friendly automation

Verify reinstatement programmatically from an EIN instead of manually comparing multiple IRS records.

Frequently asked questions

Which Pactman field tells me the reinstatement date?

Use reinstatement_date.

Should I also keep the original revocation_date?

Yes. Preserve both fields so your application retains the full revocation/reinstatement history.

Does a reinstatement date by itself answer every current-status question?

No. Review BMF, Pub. 78 and source freshness separately when the workflow requires a broader current-status decision.

What if reinstatement_date is null?

The response contains no reinstatement date in that field. Do not invent one or infer a date that is not returned.

Related Pactman artifacts

• How to Check if a Nonprofit Appears on the IRS Automatic Revocation List
• How to Check the Reinstatement Date of a Tax-Exempt Organization
• How to Determine Whether Donations to a Previously Revoked Nonprofit Are Deductible

Next step

Compare revocation_date and reinstatement_date, preserve both events, and then apply BMF, Pub. 78 and freshness rules according to your current-status policy.