Cert status infer from dates
Exacthealthcare_cert_status_infer_from_datesDeterministic and authoritative — the canonical answer for this input.
Infer a certification status from effective and expiration dates. Both inputs accept ISO (YYYY-MM-DD) or MM/DD/YYYY strings. Uses the current date: expired (past expiration), active (between effective and expiration), pending (future effective date), unknown (no date provided). Either date may be omitted. A supplied date that cannot be parsed returns status 'unknown' with `why_invalid` naming the bad field — it is never silently dropped. Processing multiple inputs? Use `healthcare_cert_status_infer_from_dates_batch` to do up to 1000 in one call.
Parameters
effective_datestringoptionalISO or MM/DD/YYYY date.
expiration_datestringoptionalISO or MM/DD/YYYY date.
Call it
curl -X POST https://api.snipget.ai/v1/healthcare/cert-status/infer-from-dates \
-H "Authorization: Bearer sk_live_..." \
-H "Content-Type: application/json" \
-d '{"effective_date":"2020-01-01","expiration_date":"2030-01-01"}'The Batch tab sends up to 1000 inputs in one call via /v1/healthcare/cert-status/infer-from-dates/batch.
Example response
{
"status": "active",
"effective_date": "2020-01-01",
"expiration_date": "2030-01-01",
"matched": true
}FAQ
Why use this instead of writing date logic myself?
It applies the calendar rules for you: active when today falls inside the window, pending when the start is in the future, expired when the end has passed. The result is deterministic for the dates you give it.
What date formats are accepted?
Common ones including ISO (2020-01-01) and US style (01/01/2020). You can pass just an effective date, just an expiration date, or both, and it adjusts the rule accordingly.
What does it not account for?
It only reasons about the dates against today. It cannot know about a revocation or suspension that happened inside the window. If you have an explicit status word, normalize that instead.
What if I provide no dates?
It returns status 'unknown' with confidence 0, not an error, so a missing-data row is easy to detect and handle.
What happens if a date is garbled or unparseable?
A supplied date that cannot be parsed is treated as bad data, not a missing date: the call answers status 'unknown' at confidence 0 with a why_invalid message naming the bad field. It never silently ignores the garbled date and infers a status from the other one.