How to Check Whether a 501(c)(3) Was Automatically Revoked for Failure to File

Recommended verification flow

1. Normalize the EIN.
2. Send the EIN to the Nonprofit Check Plus API.
3. Confirm the organization.
4. Confirm 501(c)(3) context. Review bmf_subsection and subsection_description.
5. Review Automatic Revocation data. Check revocation_code and revocation_date.
6. Review filing requirements. Check filing_req_code.
7. Check reinstatement. Review reinstatement_date.
8. Review BMF and Pub. 78 separately. Check bmf_status and pub78_verified.
9. Check freshness.
10. Do not infer the revocation cause. Require an explicit source if your workflow needs that fact.

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 conservative workflow might:

• confirm the nonprofit's returned subsection;
• detect Automatic Revocation data using the revocation fields;
• retain filing_req_code;
• check reinstatement;
• preserve BMF and Pub. 78 status separately; and
• label the revocation cause as unknown unless an explicit source provides that cause.

The supplied current examples contain null revocation fields, so they do not provide a positive automatically-revoked test case.

Important: filing_req_code describes required returns. It is not a missed-filing counter or revocation-cause field in the supplied schema.

Why use a consolidated nonprofit verification API?

A revocation workflow benefits from BMF subsection, filing requirements, revocation history and current-source context together.

Pactman Nonprofit Check Plus returns those signals while preserving separate meanings.

One normalized response

Bring filing-requirement and Automatic Revocation data together.

Separate source signals

Avoid treating a filing requirement as proof of a filing failure.

Reusable compliance rules

Apply conservative cause-handling across grantmaking, donations and onboarding.

Developer-friendly automation

Automate what the response supports while flagging what requires additional evidence.

Frequently asked questions

Can the current API prove that the revocation happened because the nonprofit failed to file?

Not from the supplied fields alone.

What does filing_req_code tell me?

It specifies the main tax return or returns the organization is obligated to file.

Which fields identify Automatic Revocation data?

Use revocation_code and revocation_date.

Should I also check reinstatement_date?

Yes. A later reinstatement can change how your workflow treats historical revocation.

Related Pactman artifacts

• How to Determine a Nonprofit’s Current Status When IRS Data Sources Disagree
• How to Add IRS Revocation Screening to a Grantmaking Application
• How to Handle a Nonprofit Verification API Response With Missing or Null IRS Data

Next step

Use the revocation fields to detect Automatic Revocation data and filing_req_code for filing obligations, but require explicit evidence before assigning a failure-to-file cause.