dbt

dbt is the transformation layer many operators use to model raw warehouse data into analysis-ready tables. For ProPay, dbt isn’t a claims system to read from, it’s the layer that transforms ProPay’s exported data once it has landed in your warehouse. The direction runs the other way from most of ProPay’s integrations: ProPay is the source, dbt is the destination.

What ProPay writes into dbt

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 dbt: raw claim, parts, and payment events, modeled into your existing dbt project structure.

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 dbt 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 dbt in a form your team can query directly.

How the dbt connection works

ProPay’s exported events land in your warehouse as raw tables; from there, dbt models them alongside the rest of your data using whatever transformation logic your team already maintains.

A Forward Deployed Engineer sets up the export format and schedule against dbt during deployment, matching whatever structure your existing reporting already expects.

What stays in dbt

Everything else already living in dbt, 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 dbt comes from a company-specific ProPay instance, one client’s claim and financial data are never accessible to another before they reach dbt. ProPay is SOC 2 compliant, with both Type I and Type II audits complete.

Every underlying recommendation that produced the data landing in dbt 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 dbt 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 dbt

Does ProPay read claims from dbt?

No. dbt 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 dbt?

ProPay’s exported events land in your warehouse as raw tables; from there, dbt models them alongside the rest of your data using whatever transformation logic your team already maintains.

What kind of data lands in dbt?

Raw claim, parts, and payment events, modeled into your existing dbt project structure, structured and ready to query alongside whatever else already lives in dbt.