Quickstart

Learn how to get started with Soda.

This quickstart shows how Soda detects unexpected data issues by leveraging AI powered Anomaly Detection and prevents future problems by using data contracts.

Scenario

A data engineer at a retail company needs to maintain the regional_sales dataset so their team can manage regional sales data from hundreds of stores across the country. The dataset feeds executive dashboards and downstream ML models for inventory planning. Accuracy and freshness are critical, so you need both:

Automated anomaly detection on key metrics (row counts, freshness, schema drift)
Proactive enforcement of business rules via data contracts

Contact us at support@soda.io to get an account set up.

After signing up, you can follow the steps below to set up a data source and start improving data quality.

Add a Data Source

Soda AI, paired with Soda Cloud’s no-code UI, lets you connect to any data source, onboard datasets, and monitor results in minutes.

Establish connection

Navigate to the Data Sources > Create a New data source

Fill out the connection details. Then, click on Connect.

Learn more details on how to Onboard data sources & datasets.

Onboard datasets

You can onboard datasets by asking Soda AI to do it for you.

If you prefer to onboard datasets manually, head to the onboarding page.

Enable Metric Monitoring

You can enable Metric Monitoring in several ways:

While manually onboarding
By navigating to the dataset > Metric Monitoring tab
By asking Soda AI to enable Metric Monitoring

If you onboarded the dataset via Soda AI, the dataset page won't show any monitors yet.

Soda AI can enable Metric Monitoring for you:

Review Anomaly Detection results

Congratulations, you’ve onboarded your first dataset! Now let’s make sure you always know what’s happening with it.

That’s where Metric Monitoring comes in. It automatically tracks key metrics like volume, freshness, and schema changes, with no manual setup required. You’ll spot anomalies, detect trends, and catch unexpected shifts before they become problems.

Open the Metric Monitors dashboard

Go to Datasets → select the dataset to inspect.

Navigate to the Metric Monitors tab to learn more about the metrics calculated.

If enabled, key metrics are automatically monitored by default, helping you detect pipeline issues, data delays, and unexpected structural changes as they happen.

View anomalies in a specific monitor

In this guide, we will focus on the Most recent timestamp monitor. The panel shows that it was expected to be in a range of 0 - 5m 31s, but the recorded value at scan time was 56m 49s. In order to take a closer look:

Click the Most recent timestamp (or monitor of your choice) block.

In the monitor page you’ll see:

any red-dot anomalies flagged by the model,
measured value vs. expected range,
buttons to Mark as expected, Create new incident, etc.

Flag an outlier as "expected" or investigate it further.

Soda’s anomaly detection engine was built in-house (no third-party libraries) and optimized for high precision. It continuously adapts to your data patterns, and it incorporates your feedback to reduce false alarms. Designed to minimize false positives and missed detections, it shows a 70% improvement in detecting anomalous data quality metrics compared to Facebook Prophet across hundreds of diverse, internally curated datasets containing known data quality issues.

The Anomaly Detection Algorithm offers complete control and transparency in the modeling process to allow for interpretability and adaptations. It features high accuracy while leveraging historical data, delivering improvements over time.

Attack the issues in Soda Cloud

Our automated anomaly detection has just done the heavy lifting for you, identifying unusual patterns and potential data issues without any setup required.

But to prevent those issues from happening again, you must define exactly what your data should look like; every column, every rule, every expectation.

That’s where Data Contracts come in. They let you proactively set the standards for your data, so problems like this are flagged or even prevented before they impact your business.

Create a Data Contract

Create a new data contract to define and enforce data quality expectations.

In your dataset page, go to the Checks tab.

Click Create Contract.

When creating a data contract, Contract Autopilot will connect to your dataset and build a data contract.

[Optional] Ask Contract Copilot to edit the contract.

With Soda, you can edit a contract:

via Contract Copilot,
using a no-code interface, or
directly in code.

This ensures an optimal experience for all users while also providing a version-controlled code format that can be synced with a Git repository.

Publish & verify

Click Test to verify the contract executes as expected

When you are done with the contract, click Publish

Click Verify all checks.

Soda will evaluate your rules against the current data.

Review check results

Review the outcomes of the contract checks to confirm whether the data meets expectations.

You can drill into those failures in the Checks tab.

Attack the issues in your pipeline

The same contract you published in Soda Cloud can be verified from your terminal or from a pipeline step. Run it after a transformation and before anything downstream reads the table, and bad data stops where it was produced.

Three tools do this. Pick by where the verification runs.

Tool

Use it when

Soda CLI (sodacli)

You want one tool for the pipeline and the platform. A single Go binary, no dependencies, structured exit codes.

Core CLI (soda)

You want local execution in a Python environment, with fine-grained control over which checks run.

Python API

Verification is one step inside Python code you already maintain, such as an Airflow task or a notebook.

Install

brew tap sodadata/tap
brew install sodacli

Confirm it with sodacli version.

Windows and install-script options are on the Soda CLI reference.

Authenticate

sodacli auth login
sodacli auth status

auth login prompts for host, API key ID and secret, and stores them in ~/.soda/credentials. In CI, pass --api-key-id, --api-key-secret and --no-interactive instead.

Generate the keys from your profile: Generate API keys.

Verify the contract

sodacli contract verify databricks_demo/unity_catalog/demo_sales_operations/regional_sales

This runs the checks on a Soda Runner. To run them locally through Soda Core instead, add --local --datasource datasource.yml.

Review the results

sodacli results list --status failing
sodacli job logs <scan-id>

Output is a table in a terminal and JSON when piped. Force either with --output json or --output csv.

Install

Install the soda package and the connector for your data source, for example soda-databricks or soda-postgres.

The soda package ships from a private PyPI index and needs a Team or Enterprise license, unless you run verifications on a Soda Runner. Contact support@soda.io for access.

Installation flow and package list: Soda Python Libraries.

Connect to Soda Cloud

soda cloud create -f sc_config.yml

Fill in the generated file:

sc_config.yml

soda_cloud:
  host: cloud.soda.io          # Use cloud.us.soda.io for the US region
  api_key_id: ${env.SODA_API_KEY_ID}
  api_key_secret: ${env.SODA_API_KEY_SECRET}

Test it with soda cloud test -sc sc_config.yml.

Verify the contract

Fetch the contract you published in Soda Cloud, then verify it:

soda contract fetch -d databricks_demo/unity_catalog/demo_sales_operations/regional_sales -f contract.yaml -sc sc_config.yml

soda contract verify -ds ds_config.yml -c contract.yaml --publish

--publish sends the results back to Soda Cloud, so a pipeline run shows up next to the scheduled ones. It requires the Manage contract permission on the dataset.

Run a subset of checks

Verifying the whole contract on every pipeline run is often more than you need. Select checks by type, column or attribute:

soda contract verify -ds ds_config.yml -c contract.yaml -cf attributes.severity=critical

Filters, wildcards and check paths: Core CLI reference

Install and configure

Install the soda package, then create sc_config.yml as shown in the Core CLI tab. The Python API reads the same file. {% endstep %}

Verify the contract

Create verify_contract.py:

from soda_core import configure_logging
from soda_core.contracts import verify_contracts_on_runner

configure_logging(verbose=False)

result = verify_contracts_on_runner(
    dataset_identifiers=["databricks_demo/unity_catalog/demo_sales_operations/regional_sales"],
    soda_cloud_file_path="sc_config.yml",
)

print(result.get_logs_str())

The runner fetches the published contract from Soda Cloud and executes it against your data source.

Calling verification in a loop? Call configure_logging() inside the loop, before each verification. The logging setup does not reset between iterations.

Every parameter and result attribute: Python API.

Fail the pipeline when a check fails

Verification is only worth putting in a pipeline if a failed check stops the run. Each tool reports the outcome in a way your orchestrator can act on.

sodacli contract verify returns:

Code

Meaning

0

All checks passed.

1

One or more checks failed. Fail the pipeline.

2

Execution error. Retry or alert.

3

Authentication error. Check credentials.

A GitHub Actions step stops on a non-zero code with no extra wiring:

- name: Verify data contract
  run: |
    sodacli auth login --host cloud.soda.io \
      --api-key-id ${{ secrets.SODA_KEY_ID }} \
      --api-key-secret ${{ secrets.SODA_KEY_SECRET }} \
      --no-interactive
    sodacli contract verify contracts/regional_sales.yml --no-interactive

soda contract verify returns a different set of codes to sodacli. The same codes apply with --use-runner.

Code

Meaning

0

All checks passed.

1

One or more checks failed.

2

One or more checks warned and none failed.

3

The verification could not run: a contract parse error, an engine error, or a scan that errored, was canceled, or timed out.

4

Results could not be sent to Soda Cloud.

Treat 2 deliberately. A warning is not a failure, so decide whether your pipeline continues on it:

soda contract verify -ds ds_config.yml -c contract.yaml --publish
status=$?
if [ $status -eq 1 ] || [ $status -ge 3 ]; then
  exit $status
fi

Verification returns a ContractVerificationSessionResult. Read the outcome from it rather than parsing the logs:

if not result.is_ok:
    print(result.get_errors_str())
    raise SystemExit(1)

Attribute

True when

is_passed

No contract has failed checks.

is_failed

At least one contract has a failed check. Execution errors are ignored.

is_warned

At least one contract has a warned check.

has_errors

At least one contract hit an execution error.

is_ok

No failed checks and no errors.

For per-check detail, iterate result.contract_verification_results and read each check_results entry. {% endtab %} {% endtabs %}

Your contract now runs wherever your data is produced.

Prefer to try this in a notebook first? Contract verification example notebook

What’s next?

Profiling

Explore Profiling in the Discover tab to curate column selections for deeper analysis.

Notification Rules

Set up Notification Rules (bell icon → Add Notification Rule) to push alerts to Slack, Jira, PagerDuty, etc.

Custom monitors

Dive into Custom Monitors via scan.yml or the UI for even more tailored metrics.

You are not logged in to Soda and are viewing the default public documentation. Learn more about Licensing & documentation access.

If you do have a Soda license, make sure to log in to Soda Cloud in this same browser.

PreviousWhat is Soda?

NextSoda AI

Last updated 21 days ago

Was this helpful?

Scenario

Sign up

Add a Data Source

Establish connection

Onboard datasets

Enable Metric Monitoring

Review Anomaly Detection results

Open the Metric Monitors dashboard

View anomalies in a specific monitor

Attack the issues in Soda Cloud

Create a Data Contract

Publish & verify

Review check results

Attack the issues in your pipeline

Fail the pipeline when a check fails

What’s next?