What makes Verora different from a basic dental eligibility check?

Verora turns payer responses into structured benefit and denial-risk context. It can surface annual maximums, deductibles, frequency limits, missing-tooth or waiting-period signals, and other plan rules before the office needs them. Zesty presents that work as a practical front-office brief.

Can Zesty identify hygiene and procedure opportunities?

Zesty can surface covered, clinically appropriate hygiene and procedure opportunities for team review when the current benefits, required evidence, and office fee support them. The clinical team decides what belongs in the appointment.

How does Zesty handle uncertain insurance information?

Zesty distinguishes current verified information from work in progress. When it needs a current source response, a confirmed patient detail, or a human approval, it presents that boundary instead of guessing.

Quickstart

Get your first simulated eligibility result.

Use a sandbox credential to prove your integration before any real payer is contacted. The first response is deterministic, safe, and designed for automated tests.

Step 1 — Exchange your client credential

Client credentials are environment-bound. The resulting access token is short-lived and used only by your server.

Shell

curl --request POST https://dev.veroraai.com/api/oauth/token \
  --header "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "client_id=$VERORA_CLIENT_ID" \
  --data-urlencode "client_secret=$VERORA_CLIENT_SECRET"

Step 2 — Queue a deterministic sandbox verification

Every verification requires an Idempotency-Key. Reusing it for the same logical request safely returns the original job.

Shell

curl --request POST https://dev.veroraai.com/api/v1/verifications \
  --header "Authorization: Bearer $VERORA_ACCESS_TOKEN" \
  --header "Content-Type: application/json" \
  --header "Idempotency-Key: eligibility-example-001" \
  --data '{
    "customer_reference": "eligibility-example-001",
    "patient": {
      "first_name": "Taylor",
      "last_name": "Example",
      "date_of_birth": "1990-01-01",
      "member_id": "sandbox-member-001",
      "payer_id": "sandbox-payer"
    },
    "provider": { "npi": "1234567893" },
    "test": { "scenario": "verified" }
  }'

Step 3 — Read the normalized result

Use the verification ID from the accepted response. Store it alongside your own reference so operations can trace a single request without exposing raw payer responses.

Shell

curl --request GET "https://dev.veroraai.com/api/v1/verifications/$VERORA_VERIFICATION_ID" \
  --header "Authorization: Bearer $VERORA_ACCESS_TOKEN"

Expected response

{
  "verification_id": "elig_01H9...",
  "status": "succeeded",
  "environment": "sandbox",
  "simulated": true,
  "result": {
    "outcome": "eligible",
    "source": "sandbox_fixture"
  }
}

Reference

Build against these three endpoints first. Credentials select the environment; callers never put an environment selector in the request body.

POST /api/oauth/token — exchange one environment-bound client credential for a short-lived access token.
POST /api/v1/verifications — queue one verification. Returns 202 Accepted and the verification ID.
GET /api/v1/verifications/{verificationId} — retrieve the current normalized status and result.

Sandbox scenarios

Set test.scenario only in sandbox. Scenarios are deterministic so your CI suite has stable expected outcomes.

verified — Eligible result. A successful simulated eligibility response.
inactive — Ineligible result. A completed response with inactive coverage.
incomplete — Unknown result. A normalized result that requires more data.
manual_review — Unknown result. A fixture for your manual-review branch.
payer_timeout — Retryable failure. A deterministic failed job to exercise safe retry handling.

Live testing is a controlled readiness gate

It performs real eligibility checks. It is deliberately not a switch on a sandbox request or a self-service shortcut to production. Live-test access requires an active BAA, per-application approval, an active developer workspace, a verification-ready practice, and a matching provider NPI.

Errors & support

Keep the environment, verification ID, request ID, UTC timestamp, and error code. Do not send authorization headers or patient details to support.

400	The request is invalid Check field names, dates, and the sandbox scenario. Never include patient details in a support ticket.
401	The access token is invalid or expired Exchange the server-held client credential for a fresh short-lived token.
403	The environment or workspace is not authorized Confirm the application approval, selected workspace, and provider NPI for the intended environment.
409	The idempotency key conflicts Reuse a key only for the same logical verification. Generate a new key for a new request.
429	The request rate is limited Wait for the Retry-After value, then retry the same logical request safely.
503	The request could not be completed Retry with the same Idempotency-Key and retain the request ID for support.

About webhooks. Webhooks are not part of the initial v1 contract. Poll the verification URL until a signed delivery surface and replay ledger are available.