How to Handle a Nonprofit Verification API Response With Missing or Null IRS Data

Recommended verification flow

1. Confirm the top-level response succeeded.
2. Confirm ein and organization_name.
3. Evaluate BMF fields together.
4. Evaluate Pub. 78 fields together.
5. Review church and group-exemption context.
6. Treat revocation nulls as absence of returned event values, not a universal guarantee.
7. Keep foundation fields separate from BMF subsection.
8. Review irs_bmf_pub78_conflict.
9. Check most_recent_bmf, most_recent_pub78 and organization_info_last_modified.
10. Route incomplete records through explicit fallback or review logic.

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 robust null-handling layer might:

• classify fields by source;
• distinguish false from null;
• distinguish an empty exception field from a positive exception message;
• retain null revocation fields as null;
• avoid deriving missing source values from unrelated fields; and
• escalate only when required by the application's policy.

The supplied examples show null values even in otherwise successful responses, so null handling should be expected rather than treated as a transport error.

Important: Do not fabricate replacement values for null fields.

Why use a consolidated nonprofit verification API?

A normalized response makes it easier to apply source-aware null handling consistently.

Pactman preserves BMF, Pub. 78, revocation, OFAC and classification fields separately.

One normalized response

Handle source-specific absence in one application model.

Separate source signals

Avoid substituting one IRS source for another without an explicit rule.

Reusable compliance rules

Apply consistent null handling across donations, grants and onboarding.

Developer-friendly automation

Turn missing data into predictable review states instead of fragile one-off exceptions.

Frequently asked questions

Does null revocation_date prove the organization has never been revoked?

No. It means the response contains no value in that field.

Is false the same as null for pub78_verified?

No. The mapping explicitly defines false as not present in Pub. 78, while null is a different value state.

Can I fill a missing BMF field from Pub. 78?

Only if your application has an explicit source-aware rule. Do not silently substitute one source for another.

Should missing data always block the workflow?

The supplied files do not define a universal block rule. Handle missing data according to the field, source and business policy.

Related Pactman artifacts

• How to Verify a Nonprofit When Its EIN Is Not Found in IRS Pub. 78
• How to Verify a Nonprofit When IRS BMF and Pub. 78 Data Conflict
• How to Determine Which IRS Record Is Newer When Nonprofit Data Conflicts

Next step

Model null explicitly, preserve source boundaries, and route incomplete records according to documented workflow rules.