> ## Documentation Index
> Fetch the complete documentation index at: https://docs.straddle.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Synchronize and query local data
> Prepare a scoped SQLite store for search, SQL, reconciliation, and payment analysis.
Synchronize Straddle resources to answer questions across payments, customers, paykeys, and funding events. The CLI stores the data in SQLite at `~/.local/share/straddle/data.db` by default.
## Prepare the data for analysis
With [credentials and account context configured](/developer-tools/cli/auth-context), inspect the context and fetch the resources needed for payment analysis:
```bash theme={null}
straddle agent-context --pretty
straddle sync --resources payments,funding-events --full --max-pages 0 --strict --json
```
`--full` restarts from the beginning instead of a saved checkpoint. `--max-pages 0` removes the default cap of 100 pages per resource. Sync bypasses the HTTP response cache and adds or updates returned records. It retains previously synchronized records that are absent from later API lists, including during a full sync.
For an interrupted sync, rerun with the same context and resources without `--full` to use its saved progress. Before an investigation that needs refreshed historical records, run the full command again.
## Check sync completeness
Read the JSON event stream and the `sync_summary` fields `success`, `warned`, and `errored`. Check each resource you need, including dependent resources added by sync. Naming a parent resource also synchronizes its parent-keyed dependents.
The following results need attention before you treat the data as complete:
| Result | Action |
| - | - |
| `sync_warning` for denied access | Confirm the key and account can read that resource. |
| `sync_warning` with `max_pages_cap_hit` | Repeat with `--max-pages 0` or a deliberate narrower scope. |
| `sync_anomaly` | Inspect malformed or dropped records, resolve the reported cause, and synchronize again. |
| A resource error | Resolve the error and rerun that resource. |
| A required resource missing from the run | Add it to `--resources` and synchronize again. |
`--strict` makes per-resource errors fail the command. Access warnings remain warnings, so a zero exit code alone doesn't prove complete coverage.
Query filters still apply during a full sync. `--param`, `--resource-param`, and `--global-param` can narrow the fetched data. `--latest-only` limits a resource to its first page when `--since` is absent, even with `--full --max-pages 0`.
In CLI v1.0.4, `--since` produces a `resource_not_incremental` warning for every supported sync resource and sends the request without a date filter. For a date-limited sync, use a query parameter supported by that resource's API operation.
The command shown here uses no saved profile. If you add `--profile`, inspect it first with `straddle profile show PROFILE_NAME`. Saved filters and `latest-only` still apply. A saved `path-context` can change the environment used by sync without changing the context of later queries.
## Query the local store
Search the synchronized data or run a read-only query:
```bash theme={null}
straddle search "failed" --type payments --data-source local --json
straddle sql "SELECT id FROM payments LIMIT 20" --json
```
`search` uses SQLite full-text search. For live filtered searches, use the resource command, such as `straddle payments --help`. SQL accepts one `SELECT` or `WITH` statement and runs against a read-only snapshot of the current context. Resource JSON is available in each table's `data` column.
If you sync to a custom `--db` path, pass that path to `search`, `sql`, and analytics commands that read it. Generated API read commands use the default store for local fallback.
## Keep the same environment and account
Local rows are separated by the resolved API origin and acting account. A context without an acting account has its own rows; it isn't an all-account view. Direct business integrations use no acting account.
Keep the environment and account selection the same for sync and analysis. Different profiles can share rows when they resolve to the same environment and account. Integration type controls request headers and account selection, rather than adding a separate database partition.
For a marketplace, customers and paykeys remain platform-owned. Sync fetches them without an account header, then stores them under the selected acting account's local context. That local grouping doesn't make those customers or paykeys account-owned.
Records written by versions before scoped storage remain hidden from scoped reads. A nonzero `hidden_legacy_records` count in diagnostics or read metadata means you need to resync the intended context.
## Choose between API, local data, and the response cache
Read commands that support both sources accept the following options:
| Option | Read behavior |
| - | - |
| `--data-source auto` | Try the API, update the local store after a successful supported read, and fall back locally for network failures. |
| `--data-source live` | Use the API path, with no local fallback. |
| `--data-source local` | Read synchronized data in the current context. |
The HTTP response cache is separate from SQLite and can reuse GET responses for five minutes. `--data-source live --no-cache` requests a fresh API result. `--no-cache` leaves your SQLite data intact. Commands such as `reconcile` and `sql` always read local data.
Use the synchronized store for reconciliation, payment progress, returns, and charge and payout volume.
## Related topics
- [Work with Straddle from your terminal](/developer-tools/cli/overview.md)
- [Investigate payment data](/playbooks/investigate-data.md)
- [Troubleshoot the Straddle CLI](/developer-tools/cli/troubleshooting.md)
- [Reporting and exporting payment data](/guides/payments/reports.md)
- [MSB: A fintech guide](/help/Reference-Materials/money-service.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.