Webhooks
Currently uses webhooks to keep systems synchronized in real time. User changes, billing events, processing completions, and notifications flow through verified webhook handlers.
Webhook Handlers
Each webhook handler is purpose-built, signature-verified, and designed to keep Currently's dual-database architecture in sync.
User and organization lifecycle events keep both databases synchronized. When a user is created, updated, or removed in Clerk, both the platform DB and PHI DB are updated.
Billing events manage subscription state and feature gating per organization. Subscription changes automatically update what each org can access.
Issue tracking integration for internal operations. Create, update, and track support tickets and feature requests from within the platform.
Multi-channel notification delivery for processing events, approval requests, and system alerts. Reach users via in-app, email, and push notifications.
Architecture
The dual-database architecture makes webhook handling critical — every user and organization change must propagate to both databases atomically.
When Clerk fires a user event, the webhook handler writes to both the platform database and the PHI database using shared UUIDs. This keeps user/org records consistent without exposing PHI in the platform DB.
Every inbound webhook is signature-verified before processing. Clerk uses Svix signatures, Stripe uses their signing secret, and Linear uses HMAC verification. Unverified payloads are rejected.
Webhook handlers are designed for at-least-once delivery. Duplicate events are handled gracefully through upsert operations and event ID tracking.
Failed webhook processing is logged with full payload context. Retry logic ensures eventual consistency, and failed events are surfaced in the platform's operations dashboard.
Pipeline Events
Beyond external webhooks, Currently generates events as data flows through the pipeline.
Fired when a new processing job begins. Includes file metadata, organization context, and estimated processing time.
Emitted after each pipeline stage — parse, clean, FHIR convert, OMOP convert. Includes stage-specific metrics and any warnings.
Fired when all processing stages finish. Includes final quality scores, record counts, and links to output artifacts.
Triggered when data quality scores fall below configured thresholds. Includes affected records and specific quality issues.
Fired on processing failures — parse errors, validation failures, or conversion issues. Includes error context and affected records.
Emitted when scheduled or on-demand exports complete. Includes download links and export format details.
Get started
Start processing HL7 messages, ensure data quality, and enable FHIR-based interoperability — all from one platform.