CLI recipes: copy-paste SPSync commands for each use case

Every use case on the site ends with the exact commands that reproduce it. This page collects the same recipes in one place. Each recipe is export-config (discover the site/list and write the replication YAML), doctor (check the ODBC driver, Graph permissions and destination connectivity before moving data), then run (full load first time, delta after). Replace https://contoso.sharepoint.com/sites/example and the --client-id with your own tenant’s, and see Setup if you have not signed in yet.

More recipes arrive here as their use case pages publish; the commands below are generated and tested against the real CLI parser, the same way the site’s own “Script it” blocks are, so a flag rename cannot leave this page wrong.

Working across several tenants or accounts: each spsync auth login keeps a separate sign-in per app and tenant, and when one tenant has several accounts, copy the home_account_id that spsync auth login or spsync auth status prints into the config’s auth.account so every recipe below runs as the account you meant.

Reporting and analytics on SharePoint list data

Replicate a site’s lists into Postgres so Power BI, Excel or Tableau query fast, joined tables instead of the Graph API (see the use case).

spsync auth login --client-id <client-id>

spsync export-config \
  --output replication.yaml \
  --pipeline-name reporting_and_analytics \
  --prefix reporting_and_analytics \
  --destination-kind postgres \
  --connection-string-env SPSYNC_DB_CONNECTION \
  --dataset-name reporting_and_analytics \
  --client-id <client-id> \
  --site-url https://contoso.sharepoint.com/sites/example \
  --all-lists

spsync doctor replication.yaml
spsync run replication.yaml

Scriptable migrations across many sites

Config in git, reviewed in a pull request, run from CI, batched across many sites with one command (see the use case and Run a SharePoint list to database sync from CI).

spsync auth login --client-id <client-id>

spsync export-config \
  --output replication.yaml \
  --pipeline-name scriptable_migrations \
  --prefix scriptable_migrations \
  --destination-kind postgres \
  --connection-string-env SPSYNC_DB_CONNECTION \
  --dataset-name scriptable_migrations \
  --client-id <client-id> \
  --site-url https://contoso.sharepoint.com/sites/example \
  --all-lists

spsync doctor replication.yaml
spsync run replication.yaml

Batch many sites from one file instead of repeating --site-url:

spsync batch create batch.yaml

See the schema reference for the batch YAML’s shape.

A SQL Server destination

Every recipe above works unchanged against SQL Server. Swap --destination-kind:

spsync auth login --client-id <client-id>

spsync export-config \
  --output replication.yaml \
  --pipeline-name reporting_and_analytics \
  --prefix reporting_and_analytics \
  --destination-kind mssql \
  --connection-string-env SPSYNC_DB_CONNECTION \
  --dataset-name reporting_and_analytics \
  --client-id <client-id> \
  --site-url https://contoso.sharepoint.com/sites/example \
  --all-lists

--destination-kind accepts every destination kind the YAML destination.kind accepts, including duckdb (--connection-string-env names a variable holding a local .duckdb path or a MotherDuck md: DSN).

See CLI automation for scheduling any of these on a timer.