Keep Your Data in Sync with Bud

At Bud, we understand that many of our clients maintain their own storage for customer financial data, such as accounts, balances, and transactions. We actively encourage this practice to ensure you have full control and ownership of your data.

How to Sync Your Storage with Bud

1. Initial Full Sync (One-Time Setup)

If this is your first time using this synchronisation method, you'll need to perform an initial full sync for each customer to establish a baseline. This should be done either at the point of a new connection or if it's an existing connection following the latest refresh.

• Fetch all transactions for a customer from Bud's GET /financial/v2/transactions endpoint. You can do this by omitting the updated_after parameter.
• Store these transactions in your local database. This creates your initial, complete copy of the data.

If you already have an existing integration with Bud, please reach out to us to let us know when you plan to run the initial full sync for your entire customer base.

2. Incremental Sync (Regular Operation)

Once your baseline is established, you can perform regular incremental syncs. This should be performed periodically, we recommend after a refresh task is complete (when the open_banking.refresh.completed webhook is received, or the refresh task status is Completed).

• Call the Retrieve Transactions V2 endpoint with the updated_after parameter set to the timestamp of your last successful sync. This tells Bud to only return data that has changed or been deleted since that specific moment.
• Process the data array:
  • For each transaction in the data array, check if you already have a record with that transaction_id in your local storage.
  • If you do have it, update your existing record with the new information from Bud.
  • If you don't have it, insert it as a new transaction into your local storage.
• Process the metadata.deleted array:
  • Look for the new deleted array within the metadata section of the API response.
  • For each transaction_id listed in this deleted array, remove the corresponding transaction from your local storage. This ensures you're only holding active records.

Example API Response

Here's a simplified example of what the enhanced API response might look like, highlighting the new deleted section:

{  
  "operation_id": "v2_transactions_get",  
  "data": [  
    {  
      "transaction_id": "40d32711-4af8-423f-a738-9bbe96947219",  
      "account_id": "32352b68-76de-408b-a451-22e37803271a",  
      "description": "Chevron",  
      "credit_debit_indicator": "debit",  
      // ... other transaction details  
    }  
  ],  
  "metadata": {  
    "results": 1,  
    "updated_after": "2025-07-30T00:00:00Z",  
    "deleted": [  
      {  
        "transaction_id": "d2ea249c-0d1b-4346-b88e-53ec8bc32083",  
        "at": "2025-07-30T03:00:00Z"  
      },  
      {  
        "transaction_id": "d2ea249c-0d1b-4346-b88e-53ec8bc32084",  
        "at": "2025-07-30T03:00:00Z"  
      }  
    ]  
  }  
}

In this example, the data array contains transactions that are new or have been updated since 2025-07-30T00:00:00Z. The deleted array explicitly tells you that transactions with IDs d2ea249c-0d1b-4346-b88e-53ec8bc32083 and d2ea249c-0d1b-4346-b88e-53ec8bc32084 were removed from Bud's system at the specified at timestamps.

Key Benefits for You

• Efficiency: Significantly reduces the data transfer and processing required for synchronisation.
• Accuracy: Ensures your local data is always an accurate reflection of Bud's records, including deletions.
• Cost Savings: Lower API call volumes and less complex reconciliation logic can lead to reduced operational costs for your systems.
• Simplicity: Integrates seamlessly with your existing GET /financial/v2/transactions calls, avoiding the need for new endpoints or complex integration patterns.