dbt made it easier for data teams to turn warehouse SQL into versioned, tested, documented models. The remaining gap is delivery: how does a trusted model become a stable dependency for an application, internal tool, partner, or agent?

Qry’s dbt-native workflow keeps that handoff explicit.

Your repository owns the model

The dbt project owns SQL, dependencies, tests, scheduling, and the build environment. Add a small meta.qry block to the models that should become endpoints. That metadata defines the endpoint identity, path, parameters, and serving limits.

Then run the same build you already trust:

dbt build --target production

Qry owns the release

After dbt succeeds, the Qry CLI discovers and validates the generated artifacts:

qry dbt validate
qry dbt publish

Qry reconciles endpoint definitions, creates a deterministic release plan, builds one serving artifact per endpoint, uploads through scoped presigned URLs, and verifies the result before activation. A failed release does not replace the last successful snapshot.

The separation also isolates credentials: CI keeps warehouse access, while Qry receives the publish authorization and resulting artifact, so Qry Cloud never needs the source-warehouse credential for this path.

The consumer gets a stable API

Once the release is active, downstream callers use a normal authenticated endpoint:

curl "https://api.qry.thedatadavis.com/e/acme/customer-health?account_id=123" \
  -H "Authorization: Bearer $QRY_API_KEY"

They do not need warehouse access, dbt knowledge, or a custom backend service, while the data team still controls the SQL, allowed variables, response limits, freshness policy, and key scope.

Start with a safe slice

The best first endpoint is narrow: one trusted model, a small response shape, explicit parameters, and one real consumer. Publish it from CI, call it from a script or internal tool, and watch the release and request logs so the team has a concrete production interface before expanding the surface area.

Qry also supports managed refresh when Qry should run approved SQL against a read-only warehouse connection. The dbt-native path is the option when your team wants to keep model execution and warehouse credentials inside its own environment.