SchemaLabsDocs
Docs · Integrations

Workflows and data stack

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

Any tool with an HTTP Request node can call Schema, 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

SettingValue
MethodPOST
URLhttps://api.schemalabs.ai/v2/serve/{endpoint_id} (or /v2/run)
HeadersAuthorization: Bearer {{ $secrets.SCHEMA_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 Errors.

Keep the layer current

A DAG or workflow that runs after each load:

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

Refresh bills only added and changed rows and re-scores held-out; a new report is minted per run so drift is visible in the trail. 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:

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

The bundle (per-table profile, imputation, predictions, unified rows) lands as rows you can join and model on. Batch bills the batch rate. See 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.

Metering

Sync itself is free; the pass after it bills only the diff. See Usage and billing.

Other channels

Wherever Schema is consumed outside the direct API (cloud model catalogs, warehouse model pages, orchestration and agent layers), the contract is the same REST API, the same output bundle, and the same meter. For a channel you need, contact us.

Type to search.
    navigate open