~/.local/share/straddle/data.db by default.
Prepare the data for analysis
With credentials and account context configured, inspect the context and fetch the resources needed for payment analysis:--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 thesync_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:
--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: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 nonzerohidden_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:
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.
Investigate your payment data
Use the synchronized store for reconciliation, payment progress, returns, and charge and payout volume.