Using Plaid in a consumer facing app. When someone first links a bank account I only want to get the last 5 days worth of transactions (if any)... and then I want to compute what the "starting balance" was just before those transactions. (Please just trust me that I need that "starting balance" for my app!)
My idea here is to get the current
balance and then subtract off the transactions for the last 5 days.
The docs effectively say that the /transactions/get
API is deprecated - and I should use /transactions/sync
. That's fine - but /transactions/sync
doesn't provide the current account balance.
I could call /accounts/balance/get
, but that causes a balance refresh that might give me a newer balance that includes transactions that have come in after I've been through /transactions/sync
.
/accounts/get
is another option - and seems to return the "cached" balance that is probably the correct balance that goes with the transactions that just came through from sync
... but there is no guarantee. It's definitely possible that Plaid could have updated their cached balance to one that includes transactions beyond what I just got from sync
.
Basically: as far as I can tell, there is not a solution that uses sync
and guarantees a current balance that perfectly matches. Why in the heck doesn't sync
return THE current balance that goes with the transactions that just came through?
So now - I feel like I'm going to use /transactions/get
... because it WILL return the current balance and all of the transactions that went into the calculation of that balance. Unfortunately, this may return a huge amount of data - and I'll just have to throw it all away other than the last 5 days.
My plan is this:
INITIAL
webhook/transactions/get
/transactions/sync
to tell Plaid that I want to use the sync
API going forward.sync
going forward.Am I crazy? Is there a better way?!?
No errors - just unclear on the best way to proceed.
In step 4, why not just get the last 5 days of transactions? /transactions/get
allows you to specify the date range you want.
Note /transactions/get
isn’t going away any time soon (it will probably never go away) we just don’t recommend it as it has a number of usability problems that /transactions/sync
solves. If you find it better for your use case, it’s fine to use.
P.S. While it is theoretically possible that /accounts/get
could return a different balance than /transactions/sync
, if called immediately after, the odds of this happening should be so low as to be effectively zero.
EDIT TO ADD: The safe way to do it is: if you call /transactions/sync
, then call /accounts/get
, and then call /transactions/sync
again and receive no new transactions, you can safely assume that the balance returned by /accounts/get
is up-to-date with /transactions/sync
. Alternatively, you can listen for webhooks and can safely assume that the balances are the same until you receive a SYNC_UPDATES_AVAILABLE
webhook.