abridge-webhooks-events

Abridge Partner Event Contract Handler

Overview

Build a fail-closed receiver whose transport, authentication, event names, schema, delivery semantics, and registration process come from the approved private contract. If no such contract exists, produce a polling or manual handoff design instead of inventing webhooks.

Prerequisites

• The authorized Abridge environment, clinical owner, and health-system policy set
• Current tenant-specific implementation evidence for every private interface in scope
• Synthetic data or the organization's formally approved test-record procedure

Tool Discipline

Use Read, Glob, and Grep to inspect repository configuration, adapters, tests, policies, and existing evidence. Use WebFetch only for current official Abridge, HHS, or named EHR documentation. Use Write or Edit only after confirming scope, environment, owners, patient-data boundary, and approval state. These tools do not confer access to Abridge, an EHR, or a clinical record; return exact operator steps or an approval-gated handoff for live actions.

Current Contract

• The cited public Abridge materials do not publish a universal webhook catalog, HMAC header, registration endpoint, or retry schedule.
• Session or encounter identifiers can be sensitive even when a payload omits note text.
• Duplicate, delayed, and out-of-order delivery must not duplicate EHR actions.

Authentication

Use only the health system's provisioned Abridge application access, SSO, administrative role, or tenant-specific partner authentication documented for the approved environment. Do not infer public API credentials, reuse production secrets in tests, or expose tokens and session material. Verify identity owner, least privilege, environment binding, storage, rotation, and revocation before any authenticated action.

Instructions

1. Verify contract owner, revision, event purpose, transport, authentication, schema, ordering, retry, retention, and support route.
2. Use Read, Glob, and Grep to inspect the receiver, queue, idempotency store, logs, and downstream action boundary.
3. Reject unknown events and fields according to contract; authenticate before parsing sensitive content and cap body size and age.
4. Persist an opaque event key and processing state; design duplicates, replays, gaps, poison events, and manual reconciliation.
5. Use Write or Edit to add the handler and synthetic contract tests without committing private payload examples.
6. Use WebFetch only for official workflow context; do not derive protocol details from marketing pages.

Approval Boundaries

Do not expose a callback publicly, register it with a vendor tenant, or enable downstream clinical writes without security, network, vendor, and EHR change approval.

Output

Return contract revision, authenticated boundary, accepted events, rejection policy, idempotency model, retention, test evidence, and unimplemented assumptions. Separate verified facts, tenant-specific evidence, assumptions, and actions still awaiting approval.

Error Handling

Condition	Response
No approved event contract	Do not implement a webhook; propose a bounded alternative.
Authentication is ambiguous	Reject all deliveries until resolved.
Duplicate may repeat a clinical action	Quarantine and require reconciliation.

Example

The example is a redacted operational receipt, not patient data or proof of vendor certification.

contract=partner-events-r3; auth=contract-defined; accepted=2; unknown=reject; duplicate-test=pass; live-registration=no

Resources

• Official documentation map — dated public evidence and the limits of what those sources establish.

Read the source map before changing a workflow. Recheck tenant-specific implementation evidence for every interface or capability that public documentation does not define.

Next Steps

Revalidate the evidence date and tenant-specific authority before repeating this workflow in another environment, cohort, care setting, or integration mode.