AsyncAPI Specification
generated: '2026-08-15'
method: searched
source: >-
https://eligible.com/community/webhooks-helper-apis/ and
https://eligible.com/community/eligible-dev-tools-1/ and
https://eligible.com/community/eligible-developer-tools-2/ (Eligible's own published
Developer Tools series), plus the site-wide footer navigation which links
https://eligible.com/docs/developer-tools/webhooks under "For Developers".
docs: https://eligible.com/docs/introduction-to-webhooks
asyncapi: false
asyncapi_note: >-
NO ASYNCAPI DOCUMENT EXISTS. Eligible publishes no AsyncAPI, no event schema and no
machine-readable event catalog anywhere, and the pages that describe the webhook
payloads sit behind the account login. This artifact therefore records the webhook
SURFACE — which Eligible documents publicly and in detail on its own community site —
and does not invent the message schemas. Every event below is named in Eligible's own
published prose; none is inferred.
note: >-
Webhooks are not a convenience on this API, they are the primary delivery mechanism.
Eligible states the reason plainly: "Much of what happens in healthcare is
asynchronous. While certain API calls, such as our Coverage endpoint, can return data
instantly, others will require processing time on the payer's side. Normally you would
need to continue polling in order to see when the information was updated, but
webhooks handle this work for you." Batch submission and claim adjudication both
return their results only over webhooks.
transport:
style: HTTP callback to a consumer-hosted endpoint
direction: provider-to-consumer
subscription_management: >-
Configured in the Eligible account console. Eligible also documents per-payer
webhook capability through the Payers endpoint, and its FAQ notes that upgrading to
the standardized payer list is what unlocks "our new payer list management endpoints
such as payer listing, status, webhooks".
security: not publicly documented (signature scheme, retry policy and delivery
guarantees are all inside the gated reference)
events:
- id: enrollment.response
name: Enrollment response
trigger: A trading-partner enrollment is submitted.
delivery: webhook
evidence: >-
"Our sandbox allows you to submit an enrollment and immediately receive a webhook
response."
source: https://eligible.com/community/eligible-dev-tools-1/
related_api: eligible:enrollment
- id: claim.acknowledgement
name: Claim acknowledgement
trigger: A submitted 837 claim is acknowledged or rejected by the payer.
delivery: webhook (also retrievable at GET /claims/acknowledgements.json)
evidence: >-
"When submitting a claim, the sandbox automatically generates Claim
Acknowledgements and Payment reports. These are also delivered via webhook, or
accessible through their respective APIs."
source: https://eligible.com/community/eligible-dev-tools-1/
related_api: eligible:claims
- id: claim.payment_report
name: Payment report (835 remittance)
trigger: A payer issues a remittance / payment advice for a claim.
delivery: webhook (also retrievable at GET /claims/payment_reports.json)
source: https://eligible.com/community/eligible-dev-tools-1/
related_api: eligible:claims
- id: claim.status_changed
name: Claim status change
trigger: >-
Eligible polls the payer's 276/277 claim status daily for every outstanding claim
in adjudication and emits an event ONLY when the status has actually changed.
delivery: webhook
evidence: >-
"we will automatically check the payment status every day for outstanding claims
in adjudication, then push a webhook event to our customers only if the status had
changed."
source: https://eligible.com/community/eligible-developer-tools-2/
docs: https://eligible.com/docs/claim-webhooks
related_api: eligible:claims
note: >-
Polling cadence is a commercial decision, not a technical one: Eligible polls
daily for payers with no passthrough fee, and on a consumer-chosen interval for
payers that charge one, "so that there are no surprise charges".
- id: batch.result
name: Batch job result
trigger: >-
A batch submission completes. Batch is offered for Real-Time Eligibility, Coverage
and Estimated Primary Payer.
delivery: webhook
batch_endpoints:
- POST /coverage/all/batch.json
- POST /demographic/all/batch.json
- POST /medicare/coverage/batch.json
- GET /batch/payment/status.json
source: https://eligible.com/community/webhooks-helper-apis/
docs: https://eligible.com/docs/batch-events
- id: payer.status_changed
name: Payer status change
trigger: A payer connection's status or capability changes.
delivery: webhook
evidence: >-
Eligible's FAQ lists "payer listing, status, webhooks" among the endpoints
unlocked by the standardized payer list.
source: https://eligible.com/community/technical-features-faq/
related_api: eligible:payers
confidence: medium
testing:
sandbox_generates_events: true
detail: sandbox/eligible-sandbox.yml
tutorials: https://eligible.com/docs/testing-webhooks
note: >-
Eligible publishes tutorials on standing up a test server to receive webhooks, and
its sandbox synthesizes acknowledgements and payment reports so the asynchronous
half of the integration can be exercised without a live payer.
coverage:
events_named: 6
events_with_published_schema: 0
gap: >-
Six event types are named publicly and none has a public payload schema. The
payloads, the signature scheme, the retry policy and the delivery guarantees are all
inside https://eligible.com/docs, which serves a Sign In page. For an API whose
primary result channel is the webhook, that is the single largest machine-readability
gap in this profile — larger than the missing OpenAPI, because the REST surface can
at least be reconstructed from the first-party clients and the event surface cannot.
evidence:
- url: https://eligible.com/community/webhooks-helper-apis/
status: 200
- url: https://eligible.com/community/eligible-dev-tools-1/
status: 200
- url: https://eligible.com/community/eligible-developer-tools-2/
status: 200
- url: https://eligible.com/docs/introduction-to-webhooks
status: 403
- url: https://eligible.com/docs/developer-tools/webhooks
status: 404