The API layer for Auth57 Core.
Auth57 Core is the prior authorization rules layer: state, program, category, payer context, source evidence, freshness, and confidence. Meridian adds the intelligence layer on top: denial-rate tracking, gap assessment, and validator workflows.
Rules lookup
Answer whether a state/program/service or drug class requires prior authorization, and return the source trail behind that answer.
Compare logic
Show cross-state divergence so a product or compliance team can see where rule logic changes by market.
Evidence-first data
Every production answer should carry provenance, last-verified date, and confidence instead of a naked boolean.
Quickstart
Use an API key in the x-api-key header. Keep keys server-side. Browser calls should go through your backend so keys are never exposed to users.
curl "https://api.auth57.io/v1/pa-lookup?state=CA&program=medicaid_mco&category=behavioral_health" \ -H "x-api-key: auth57_live_your_key"
Endpoints
Endpoint maturity is explicit. Auth57 Core endpoints are live behind API-key authentication and entitlement checks; Meridian endpoints expose the surrounding transparency and readiness intelligence.
| Parameter | Type | Notes |
|---|---|---|
state | string | Two-letter state code. Example: TX, CA, NJ. |
program | string | Program family such as medicaid_mco, medicaid_ffs, dual, or ma. |
category | string | Service or policy category. Example: home_health, behavioral_health, dme. |
drug_class | string | Drug-class lookup when pharmacy coverage is included in the customer plan. |
Response model
The response should feel credible to engineers and compliance buyers: deterministic fields, explicit confidence, and source evidence that can be logged.
{
"ok": true,
"query": {
"state": "TX",
"program": "medicaid_mco",
"category": "home_health"
},
"result": {
"requires_prior_auth": true,
"rule_status": "active",
"confidence": "high",
"last_verified": "2026-04-09",
"freshness_sla_days": 7
},
"evidence": [
{
"source_type": "state_policy",
"title": "Texas Medicaid prior authorization guidance",
"url": "https://www.tmhp.com/topics/prior-authorization",
"confidence": "high"
}
]
}
React components for product teams
Auth57 should not make every customer rebuild the same PA result card, confidence treatment, and compare workflow. The React kit gives developers drop-in components that keep Auth57-powered experiences clear and consistent inside their own products.
Lookup widget
Auth57PALookup renders state, program, service/drug selection, calls a customer proxy endpoint, and displays the rule result.
Compare panel
Auth57ComparePanel compares one service across multiple states and summarizes divergence.
Result card
Auth57RuleCard turns any Core API rule object into a polished evidence card with source, confidence, and verification date.
import { Auth57PALookup } from '@auth57/react';
import '@auth57/react/styles.css';
export function PriorAuthLookup() {
return (
<Auth57PALookup
endpoint="/api/auth57/pa-lookup"
defaultState="TX"
defaultProgram="medicaid_mco"
/>
);
}
x-api-key before forwarding to Auth57.
| Asset | Path | Purpose |
|---|---|---|
| Package | @auth57/react | Package metadata and exports for customer installation. |
| React kit | /developer-kit/react/Auth57Core.jsx | Lookup, compare, card, badge, and confidence components. |
| Styles | /developer-kit/react/auth57-core.css | Reusable Auth57 visual language for embedded product surfaces. |
| Next.js proxy | /developer-kit/react/examples/nextjs | Server-side proxy routes that keep Auth57 API keys out of browser code. |
| Download | /developer-kit/auth57-react-kit.zip | Copy-ready zip for teams before npm publication. |
Errors and rate limits
Authentication
401 means the key is missing or invalid. 403 means the key is valid but the plan does not include that state, program, or add-on.
Data availability
404 means no matching rule was found. 409 should be used when a rule exists but requires human review before production use.
Rate limits
Return 429 with reset headers. API-plan customers should see usage in the dashboard before they hit a hard stop.
Versioning
Use stable URLs and version response schemas with schema_version. Do not break downstream compliance logs silently.
What developers build with it
Provider workflow
Tell a care team whether PA is likely required before a request is submitted.
Payer compliance ops
Compare internal rule logic against verified state requirements and monitored source changes.
Vendor integrations
Embed state-aware PA intelligence into clearinghouse, EHR, care-management, or analytics products.
Access checklist
A developer page should convert serious technical buyers into a clean next step. The next version should connect this directly to key provisioning and usage telemetry.
| Step | Owner | Output |
|---|---|---|
| Confirm covered states and programs | Auth57 + customer | Entitlement scope |
| Issue API key | Auth57 | auth57_live_... |
| Run sample lookups | Developer team | Logged evidence and response snapshots |
| Agree update workflow | Auth57 + customer | Change-review and data freshness expectations |