Apache Kafka
Event streaming for real-time claim and work order events
ProPay integrates with Apache Kafka as a data destination, not a claims source. Apache Kafka is the event streaming backbone many operators already use to move data between systems in real time. ProPay writes claim, parts, and payment events into it for reporting and analytics.
Apache Kafka is the event streaming backbone many operators already use to move data between systems in real time. For ProPay, Apache Kafka isn’t a claims system to read from, it’s a real-time event bus ProPay can publish claim and work order events onto. The direction runs the other way from most of ProPay’s integrations: ProPay is the source, Apache Kafka is the destination.
What ProPay writes into Apache Kafka
As ProPay works a claim, intake, triage, authorization, parts sourcing, and payment, it generates a structured record of what happened at every stage. That record is what flows into Apache Kafka: claim status changes, dispatch events, and payment events as they happen.
Every one of those events traces back to a real interaction, a homeowner’s SMS thread, a technician’s status update, a supplier’s shipping confirmation, not a manual log entry. That’s what makes the data landing in Apache Kafka usable for analysis rather than another reporting gap to fill by hand.
That includes the metrics ProPay is built to move: homeowner SMS engagement, truck rolls avoided through triage, parts procurement overspend identified against optimal routing, and cycle time from claim to payment, all landing in Apache Kafka in a form your team can query directly.
How the Apache Kafka connection works
ProPay publishes claim and work order events onto a Kafka topic as they occur, so anything already consuming that topic sees ProPay’s activity in real time rather than on a batch schedule.
A Forward Deployed Engineer sets up the export format and schedule against Apache Kafka during deployment, matching whatever structure your existing reporting already expects.
What stays in Apache Kafka
Everything else already living in Apache Kafka, your other data sources, existing models, and reporting logic, is untouched. ProPay adds a new, accurate source of claims data; it doesn’t touch what’s already there.
Data handling and security
Data written into Apache Kafka comes from a company-specific ProPay instance, one client’s claim and financial data are never accessible to another before they reach Apache Kafka. ProPay is SOC 2 compliant, with both Type I and Type II audits complete.
Every underlying recommendation that produced the data landing in Apache Kafka carries a confidence level and the inputs behind it, so the data itself is auditable back to the decision that created it.
Deploying the integration
A dedicated Forward Deployed Engineer configures the export into Apache Kafka to match your schema and cadence, so it plugs into existing dashboards and models rather than requiring new tooling.
Frequently asked questions about ProPay and Apache Kafka
Does ProPay read claims from Apache Kafka?
No. Apache Kafka is a destination for ProPay’s own claim, parts, and payment data, not a source ProPay reads a claim record from.
How does ProPay connect to Apache Kafka?
ProPay publishes claim and work order events onto a Kafka topic as they occur, so anything already consuming that topic sees ProPay’s activity in real time rather than on a batch schedule.
What kind of data lands in Apache Kafka?
Claim status changes, dispatch events, and payment events as they happen, structured and ready to query alongside whatever else already lives in Apache Kafka.
