> ## Documentation Index > Fetch the complete documentation index at: https://learn.breezing.io/llms.txt > Use this file to discover all available pages before exploring further. # Sync Wallet API > Trigger an incremental or custom period Breezing wallet sync to pull blockchain or exchange transactions for accounting reconciliation. ## OpenAPI ````yaml POST /wallets/{id}/sync openapi: 3.1.0 info: title: Breezing Public API version: 1.0.0 description: >- Crypto accounting API for programmatic access and AI agents. Authenticate with an API key using the Authorization header: `Bearer brz_...` servers: - url: https://api.breezing.io/v1 security: - BearerAuth: [] paths: /wallets/{id}/sync: post: tags: - Wallets summary: Trigger a wallet sync (incremental or custom period) description: >- Trigger a sync on an existing wallet. **Without a body** this is the incremental sync: the server picks up from the last synced transaction's date and runs through the current time. **With a body** you can sync a custom window instead, e.g. to backfill an earlier period that was never imported: pass `dateFrom`/`dateTo` (unix seconds). Returns immediately while the sync runs in the background. Poll GET /wallets/{id} (status field) and GET /tasks for progress. Works for chain and exchange wallets (exchange credentials are stored on the wallet from initial dashboard creation). Returns 400 for unsupported wallet types (e.g. CSV-only or bank). **Duplicate-period protection:** when a custom window is provided and transactions already exist inside it for this wallet, the call returns 409 PERIOD_NOT_EMPTY with the count instead of importing duplicates. Choose a window that ends before the earliest already-imported transaction. **Solana wallets:** the provider cannot jump to an end date, so a custom `dateTo` is rejected. Pass `toHash` instead: the signature of the oldest transaction already imported for this wallet (or any transaction of this wallet to stop at). The sync starts at that transaction and walks backwards to `dateFrom`. When the hash matches an imported transaction, the duplicate-period check is bounded to the window before it, so a backfill behind existing data passes. Cardano, Bitcoin, and Tron also reject a custom `dateTo` (same provider limitation, no hash alternative). **Duplicate-run protection:** returns 409 CONFLICT if an `importTransactions` task is already in `pending` or `progress` status for this wallet (this also covers the initial sync started by `POST /wallets`). Different wallets in the same company can sync in parallel. Call GET /tasks first. parameters: - schema: type: string description: Wallet ID example: '1' required: true description: Wallet ID name: id in: path - schema: type: string description: >- Organization ID. Use GET /v1/companies to discover available org/company pairs. example: '1' required: true description: >- Organization ID. Use GET /v1/companies to discover available org/company pairs. name: orgId in: query - schema: type: string description: >- Company ID. Use GET /v1/companies to discover available companies and their access levels. example: '1' required: true description: >- Company ID. Use GET /v1/companies to discover available companies and their access levels. name: companyId in: query requestBody: required: false content: application/json: schema: $ref: '#/components/schemas/SyncWalletBody' responses: '200': description: Sync triggered successfully content: application/json: schema: type: object properties: success: type: boolean enum: - true data: type: object properties: walletId: type: number dateFrom: type: number description: >- Resolved sync window start (unix seconds). Custom dateFrom when provided, otherwise the last imported transaction date (or the wallet floor). dateTo: type: number description: >- Resolved sync window end (unix seconds). Custom dateTo when provided, otherwise the current time. status: type: string enum: - loading description: >- Wallet status while the sync runs. Matches the value GET /v1/wallets/{id} will return until the sync completes. required: - walletId - dateFrom - dateTo - status required: - success - data '400': description: >- Bad request (unsupported wallet type, invalid date range, toHash on a non-Solana wallet, or dateTo on a chain that does not support it) content: application/json: schema: type: object properties: success: type: boolean enum: - false error: type: object properties: code: type: string message: type: string required: - code - message required: - success - error '401': description: Invalid or missing API key content: application/json: schema: type: object properties: success: type: boolean enum: - false error: type: object properties: code: type: string message: type: string required: - code - message required: - success - error '403': description: >- API key has no access to this company, has read-only access where write was required, or the company subscription is inactive content: application/json: schema: type: object properties: success: type: boolean enum: - false error: type: object properties: code: type: string message: type: string required: - code - message required: - success - error '404': description: Wallet not found content: application/json: schema: type: object properties: success: type: boolean enum: - false error: type: object properties: code: type: string message: type: string required: - code - message required: - success - error '409': description: >- A sync is already running for this wallet (CONFLICT), or transactions already exist in the requested custom period (PERIOD_NOT_EMPTY) content: application/json: schema: type: object properties: success: type: boolean enum: - false error: type: object properties: code: type: string message: type: string required: - code - message required: - success - error '500': description: Internal server error content: application/json: schema: type: object properties: success: type: boolean enum: - false error: type: object properties: code: type: string message: type: string required: - code - message required: - success - error security: - BearerAuth: [] components: schemas: SyncWalletBody: type: object properties: dateFrom: type: integer minimum: 0 exclusiveMinimum: true description: >- Start of a custom sync window (unix seconds). Use this to backfill a period that was never imported (e.g. the wallet only holds 2026 data and 2024/2025 are missing). Omit the body entirely for the default incremental sync. example: 1704067200 dateTo: type: integer minimum: 0 exclusiveMinimum: true description: >- End of a custom sync window (unix seconds). Requires dateFrom. Must be <= now for a backfill that avoids overlapping already-imported data. Not supported on Solana, Cardano, Bitcoin, or Tron wallets (their providers paginate from the chain tip); on Solana pass toHash instead. example: 1735689599 toHash: type: string minLength: 1 maxLength: 120 description: >- Solana wallets only. A transaction signature used as the upper boundary: the sync starts at this transaction and walks BACKWARDS to dateFrom, so only transactions older than this hash are imported. Pass the signature of the oldest transaction already imported for this wallet so the backfill stops exactly where the existing data begins. Requires dateFrom. ````