use crate::FluentRequest;
use serde::{Serialize, Deserialize};
use httpclient::InMemoryResponseExt;
use crate::model::TransactionsSyncRequestOptions;
/**You should use this struct via [`PlaidClient::processor_transactions_sync`].
On request success, this will return a [`ProcessorTransactionsSyncResponse`].*/
#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct ProcessorTransactionsSyncRequest {
pub count: Option<i64>,
pub cursor: Option<String>,
pub options: Option<TransactionsSyncRequestOptions>,
pub processor_token: String,
}
impl FluentRequest<'_, ProcessorTransactionsSyncRequest> {
///Set the value of the count field.
pub fn count(mut self, count: i64) -> Self {
self.params.count = Some(count);
self
}
///Set the value of the cursor field.
pub fn cursor(mut self, cursor: &str) -> Self {
self.params.cursor = Some(cursor.to_owned());
self
}
///Set the value of the options field.
pub fn options(mut self, options: TransactionsSyncRequestOptions) -> Self {
self.params.options = Some(options);
self
}
}
impl<'a> ::std::future::IntoFuture
for FluentRequest<'a, ProcessorTransactionsSyncRequest> {
type Output = httpclient::InMemoryResult<
crate::model::ProcessorTransactionsSyncResponse,
>;
type IntoFuture = ::futures::future::BoxFuture<'a, Self::Output>;
fn into_future(self) -> Self::IntoFuture {
Box::pin(async move {
let url = "/processor/transactions/sync";
let mut r = self.client.client.post(url);
if let Some(ref unwrapped) = self.params.count {
r = r.json(serde_json::json!({ "count" : unwrapped }));
}
if let Some(ref unwrapped) = self.params.cursor {
r = r.json(serde_json::json!({ "cursor" : unwrapped }));
}
if let Some(ref unwrapped) = self.params.options {
r = r.json(serde_json::json!({ "options" : unwrapped }));
}
r = r
.json(
serde_json::json!(
{ "processor_token" : self.params.processor_token }
),
);
r = self.client.authenticate(r);
let res = r.await?;
res.json().map_err(Into::into)
})
}
}
impl crate::PlaidClient {
/**Get incremental transaction updates on a processor token
This endpoint replaces `/processor/transactions/get` and its associated webhooks for most common use-cases.
The `/processor/transactions/sync` endpoint allows developers to subscribe to all transactions associated with a processor token and get updates synchronously in a stream-like manner, using a cursor to track which updates have already been seen. `/processor/transactions/sync` provides the same functionality as `/processor/transactions/get` and can be used instead of `/processor/transactions/get` to simplify the process of tracking transactions updates.
This endpoint provides user-authorized transaction data for `credit`, `depository`, and some loan-type accounts (only those with account subtype `student`; coverage may be limited). For transaction history from `investments` accounts, use `/investments/transactions/get` instead.
Returned transactions data is grouped into three types of update, indicating whether the transaction was added, removed, or modified since the last call to the API.
In the first call to `/processor/transactions/sync` for a processor token, the endpoint will return all historical transactions data associated with that processor token up until the time of the API call (as "adds"), which then generates a `next_cursor` for that processor token. In subsequent calls, send the `next_cursor` to receive only the changes that have occurred since the previous call.
Due to the potentially large number of transactions associated with a processor token, results are paginated. The `has_more` field specifies if additional calls are necessary to fetch all available transaction updates. Call `/processor/transactions/sync` with the new cursor, pulling all updates, until `has_more` is `false`.
When retrieving paginated updates, track both the `next_cursor` from the latest response and the original cursor from the first call in which `has_more` was `true`; if a call to `/processor/transactions/sync` fails when retrieving a paginated update, which can occur as a result of the [`TRANSACTIONS_SYNC_MUTATION_DURING_PAGINATION`](https://plaid.com/docs/errors/transactions/#transactions_sync_mutation_during_pagination) error, the entire pagination request loop must be restarted beginning with the cursor for the first page of the update, rather than retrying only the single request that failed.
Whenever new or updated transaction data becomes available, `/processor/transactions/sync` will provide these updates. Plaid typically checks for new data multiple times a day, but these checks may occur less frequently, such as once a day, depending on the institution. To force Plaid to check for new transactions, use the `/processor/transactions/refresh` endpoint.
Note that for newly created processor tokens, data may not be immediately available to `/processor/transactions/sync`. Plaid begins preparing transactions data when the corresponding Item is created, but the process can take anywhere from a few seconds to several minutes to complete, depending on the number of transactions available.
To receive Transactions webhooks for a processor token, set its webhook URL via the [`/processor/token/webhook/update`](https://plaid.com/docs/api/processor-partners/#processortokenwebhookupdate) endpoint.
See endpoint docs at <https://plaid.com/docs/api/processor-partners/#processortransactionssync>.*/
pub fn processor_transactions_sync(
&self,
processor_token: &str,
) -> FluentRequest<'_, ProcessorTransactionsSyncRequest> {
FluentRequest {
client: self,
params: ProcessorTransactionsSyncRequest {
count: None,
cursor: None,
options: None,
processor_token: processor_token.to_owned(),
},
}
}
}