An OSHA recordable API should not return a confident yes or no from a sentence-sized incident summary. Recordability is a sequence of factual decisions under Part 1904. A useful API accepts the facts that change that result, returns the regulatory basis for each conclusion and says plainly when the evidence is insufficient. If it cannot expose its reasoning, it is an incident-label generator, not a compliance tool.
The minimum useful inputs
The core regulation requires work-relatedness, new-case status and an applicable recording criterion. An API therefore needs more than “injury type” and “treatment”. At minimum, it needs a structured answer about the work environment, prior same-condition history, treatment, days away, restriction or transfer, loss of consciousness and significant diagnosis. Special-case fields may be needed for hearing loss, needlesticks, tuberculosis, medical removal and musculoskeletal disorders.
| Input group | Why an API needs it | Example of a bad shortcut |
|---|---|---|
| Causation and location | Tests work-relatedness and exceptions | Assuming every condition reported at work is work-related |
| Recovery history | Separates a new case from continuation | Treating every flare-up as a new injury |
| Treatment details | Distinguishes first aid from medical treatment | Treating every clinic visit as recordable |
| Work-status detail | Detects days away, restriction and transfer | Reading “light duty” as a legal conclusion |
| Missing/uncertain facts | Lets the system request review | Returning “not recordable” when data is absent |
The regulatory sequence comes from 29 CFR Part 1904, not from an injury-name lookup.
What a good response looks like
At a minimum, return a verdict, the decisive facts, citations and unresolved questions. A recordable response should identify whether the trigger was restricted work, medical treatment beyond first aid, significant diagnosis or another criterion. A non-recordable response should say which gate failed. A needs-review response should name the exact fact required—whether a clinician restricted a routine job function, for example—not merely say “more information needed”.
This matters in an audit. “Recordable: true” cannot show why a record was entered. “Recordable because the reported work-related new case received sutures; 1904.7(b)(5)” gives a coordinator something they can check against the actual treatment record. It also makes later correction possible when the input was wrong.
Test an API with edge cases, not easy ones
Every service can classify a clearly work-related fracture with days away. Test the boundaries: an over-the-counter medication used at prescription strength; a worker who performs a temporary task but cannot do a routine function; symptoms that arise at work after an off-duty event; a recurrence after complete recovery; a diagnosed concussion without lost time. These cases reveal whether the API is applying a rule or matching a pattern.
One useful test case is a picker who receives an elastic wrap and a restriction from lifting over 10 pounds for five days. A shallow system sees “first aid” and says no. A sound system asks whether lifting is routine work, then recognises that restriction can make the case recordable. Our decision-tree guide maps the same logic for people.
Cite the rule, not a marketing claim
The underlying source should be current federal text and linked at the point of decision. The eCFR is continuously updated; it identifies the version date and the rule sections. An API provider should be clear about the jurisdiction too. Federal Part 1904 is not a promise to cover state-plan variation, employment law, workers’ compensation eligibility or medical advice.
Job13’s public API documentation exposes a structured federal recordability determination and exact regulation text, with a sandbox key for first evaluation. It is deliberately designed to return a review state when a required fact cannot be known. That is a feature worth looking for in any tool you evaluate, including ours.
Security and operational questions
Ask where incident facts go, how long they are retained, what authentication scopes exist, whether inputs and outputs are logged safely, and how policy changes are versioned. Safety reports can contain sensitive personal and medical information. A technically correct endpoint with a sloppy data trail can create a separate problem.
Also ask how downstream systems use the answer. A recordability API should support human review and an auditable log-entry workflow; it should not silently submit a filing or overwrite a record without confirmation. The API is the classification step, not the full compliance programme.
A short evaluation checklist
- Does it require facts for work-relatedness, new-case status and outcomes?
- Does every verdict include a specific Part 1904 citation?
- Can it return “needs review” with a useful missing-fact prompt?
- Are special recordkeeping rules handled or explicitly out of scope?
- Can you test it with a sandbox and preserve an audit trail?
If the answer to several of these is no, keep the API away from automatic log entry. Use it as a research aid until the workflow can support a real determination.
Version the rule set and the result
For a production integration, retain the input, output, tool version and source version used for each determination. A regulation-backed answer should be reproducible: a reviewer ought to be able to see what facts the caller supplied and which cited rule text the service applied at that time. If a policy or parser changes later, rerun historical cases deliberately rather than silently rewriting their history. This is the difference between an auditable decision aid and a black box with a compliance-shaped label.
Frequently asked questions
Can an API decide whether an injury is OSHA recordable?
An API can apply structured Part 1904 rules to supplied facts, but it cannot create missing evidence or replace medical and management judgement. A safe design should expose citations and return a review state where the answer depends on an unresolved fact.
What should an OSHA recordable API cite?
It should cite the applicable Part 1904 section at the decisive step—such as work-relatedness under 1904.5, new-case status under 1904.6 or the relevant 1904.7 criterion—rather than citing a general blog post.
Is a recordability API the same as OSHA electronic reporting?
No. Recordability determines whether a case belongs on the employer’s records. Electronic submission and severe-event reporting are separate workflows with their own thresholds and deadlines.
Does Job13’s API cover state-plan rules?
No. Job13’s determination engine covers federal 29 CFR Part 1904. State-plan variations need separate verification and should not be implied by a federal result.
