How to Check if a Nonprofit Appears on the IRS Automatic Revocation List

Recommended verification flow

1. Normalize the EIN.
2. Send the EIN to the Nonprofit Check Plus API.
3. Confirm the organization.
4. Read revocation_code.
5. Read revocation_date.
6. Review reinstatement_date.
7. Keep BMF presence separate. Review bmf_status.
8. Keep Pub. 78 presence separate. Review pub78_verified.
9. Check freshness. Review most_recent_bmf, most_recent_pub78 and organization_info_last_modified.
10. Apply your screening rule. Distinguish historical revocation from current status.

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 revocation-list screening layer might:

• confirm the EIN and organization identity;
• inspect revocation_code;
• inspect revocation_date;
• inspect reinstatement_date;
• preserve BMF and Pub. 78 signals separately; and
• route any populated revocation data through your application's status policy.

The supplied current examples have null revocation_code, revocation_date and reinstatement_date, so they demonstrate the schema but not a positive Automatic Revocation match.

Important: The current API does not expose a separate automatic-revocation Boolean. Use the actual revocation fields returned by Pactman.

Why use a consolidated nonprofit verification API?

Automatic Revocation screening is more useful when revocation history can be reviewed together with reinstatement, BMF, Pub. 78 and freshness signals.

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

One normalized response

Evaluate revocation code, revocation date, reinstatement and supporting IRS signals together.

Separate source signals

Preserve Automatic Revocation, BMF and Pub. 78 signals independently.

Reusable compliance rules

Apply the same revocation-screening rule across donations, grants, onboarding and recurring checks.

Developer-friendly automation

Screen EINs programmatically instead of requiring manual Automatic Revocation list searches.

Frequently asked questions

Which fields should I check for IRS Automatic Revocation data?

Start with revocation_code and revocation_date.

Does a populated revocation_code automatically tell me the nonprofit is currently revoked?

Not by itself. Also review revocation_date and reinstatement_date, then apply your current-status rule.

What if all three revocation fields are null?

The response contains no values in those revocation/reinstatement fields. Do not convert that fact into a universal guarantee of current tax-exempt status.

Is there a separate automatic-revocation Boolean in the current API?

No. Use revocation_code, revocation_date and reinstatement_date.

Related Pactman artifacts

• How to Check if a Nonprofit Has Lost Its Tax-Exempt Status
• How to Verify Whether a Revoked Nonprofit Has Been Reinstated
• How to Check Whether a 501(c)(3) Was Automatically Revoked for Failure to File

Next step

Use revocation_code and revocation_date as the Automatic Revocation data signals, then review reinstatement_date before making a current-status decision.