# Workflows and data stack

Call the model from any HTTP node, schedule syncs and refreshes from your orchestrator, and land bundles in the warehouse.

> Informational documentation, based on the paper Data Language Models: A New Foundation Model Class for Tabular Data (arXiv:2605.06290, https://arxiv.org/abs/2605.06290). Reference material, not a hosted service; hosts, keys, and ids are placeholders.

Any tool with an HTTP Request node can call the model, and any orchestrator can keep an endpoint current. The contract is the same everywhere: `POST /v2/run` for a stateless quick run, `POST /v2/serve/{endpoint_id}` for a live endpoint, a bearer key, JSON in, the bundle out.

## Workflow and no-code tools

| Setting | Value |
|---|---|
| Method | `POST` |
| URL | `https://api.example.com/v2/serve/{endpoint_id}` (or `/v2/run`) |
| Headers | `Authorization: Bearer {{ $secrets.API_KEY }}`, `Content-Type: application/json` |
| Body | `{ "tables": [ { "id": "...", "columns": [...], "rows": [...] } ] }` |

Map the incoming item (a form submission, a CRM row, a CSV chunk) into `rows`. Use a `serve`-scoped key for the serve call; the sync, refresh, and job-polling steps below need `manage` and `read`. Then branch on the bundle:

- `prediction.results[0].confidence` above your threshold → automate; below → human review.
- `tables[0].column_profile[*].pii == true` → mask before the next step.
- `cross_table_map.entity_matches[*].confidence` in your review band → review queue.
- `imputation.filled[*]` non-empty → write filled values back with their row confidence.

Endpoint creation, refresh, and batch runs return `202` with a `job_id`. Add a wait-and-poll loop on `GET /v2/jobs/{job_id}` (2 s, 4 s, 8 s, then every 15 s) and continue on `status == "done"`. Every failure is one JSON envelope with `error.type`; branch on it, and honor `Retry-After` on `429`. See the error envelope.

## Keep the layer current

A DAG or workflow that runs after each load:

```text
 load source  →  POST /v2/data/:id/sync  →  POST /v2/endpoints/:id/refresh
                                         →  poll job  →  read report
```

Use an `Idempotency-Key` per scheduled run so retries never duplicate work.

## Land the bundle in the warehouse

For large tables, run in batch and write the output to a warehouse table:

```http
POST /v2/run
{ "data": ["snowflake://example/warehouse/events_2025"],
  "target": { "column": "converted" },
  "options": { "processing": "batch", "out": "warehouse://analytics.outputs" } }
```

The bundle (per-table profile, imputation, predictions, unified rows) lands as rows you can join and model on. See [Batch and large runs](/model/data#batch-and-large-runs).

## dbt

Model the bundle tables like any source: `unified_rows` becomes a golden-record model, `imputation.filled` a repair log, `prediction.results` a scored table with the endpoint's `report_id` as lineage.

## Other channels

For a channel you need, contact us.