Ellipse Gradient for Header

Plaid Integration Guide

Connect Plaid’s REST APIs and product-specific webhook notifications to enterprise workflows for financial data synchronization, verification, and automation.

Plaid integration options at a glance

Plaid’s primary server-side integration mechanism is its REST API, which supports Link-token creation, public-token exchange, account and balance retrieval, transaction synchronization, identity access, asset reports, and selected payment or transfer operations. Plaid also provides product-specific webhook notifications for transaction updates, Item status changes, asset report processing, and selected lifecycle events. Transactions can be synchronized incrementally with cursors, while some reports are processed asynchronously. Martini can securely call Plaid endpoints, receive webhook notifications, persist Item access tokens and cursors, map financial data, orchestrate asynchronous workflows, and route normalized results to enterprise applications or databases.

Integration pointSupported by Plaid?Common use casesHow Martini supports it
REST APIsYesCreate Link tokens, exchange public tokens, retrieve Accounts and balances, synchronize Transactions, retrieve Identity data, create Asset Reports, and access enabled payment or transfer resources.Martini can consume Plaid REST endpoints from workflows, store state between calls, transform responses, apply business rules, and expose controlled APIs to client applications.
Webhooks and outbound callbacksLimitedReceive selected product and lifecycle notifications for Transactions, Items, Assets, Identity, income, investments, payments, or transfers where supported.Martini can expose a receiving API or webhook workflow, validate and deduplicate notifications, then call Plaid for current state or incremental data.
Bulk, asynchronous, and batch operationsLimitedHandle asynchronous operations such as Asset Report creation and processing. Plaid does not provide one general bulk API for all resources.Martini can orchestrate create, wait, callback, status, and retrieval stages using event-driven or scheduled workflows with bounded retries.
File and report retrievalLimitedRetrieve Asset Reports and selected statements or document content when supported by the relevant Plaid product and institution.Martini can retrieve supported report or document responses, transform them, persist them in an approved target, and coordinate downstream processing.
AuthenticationYesUse client_id and secret for application access, Link tokens for the connection experience, public-token exchange, and Item-specific access_tokens for subsequent product calls.Martini can store application credentials and Item access tokens in protected environment configuration or secure application storage and inject them into workflow requests.
Cursor-based synchronizationYesUse Transactions Sync to process additions, modifications, and removals incrementally across multiple pages.Martini can persist a cursor per Item, loop until synchronization is complete, process changes idempotently, and commit the cursor after successful writes.
SDKsYesUse Plaid client libraries and Link integrations for selected languages and client experiences.A Martini workflow can consume the documented HTTP API directly, so a Plaid SDK is not required for server-side orchestration.
GraphQL APIsNot confirmedPlaid’s supplied documentation describes REST-style endpoints; no official GraphQL API was identified.Martini can consume REST APIs, but a Plaid GraphQL integration should not be assumed without vendor confirmation.
SOAP APIsNoPlaid documents REST-style APIs rather than SOAP services.Martini should use Plaid REST endpoints and product-specific webhooks instead of expecting a SOAP interface.

How Plaid exposes data and business events

Plaid REST APIs

Plaid’s REST-style API is the primary server integration mechanism. It supports Link-token creation, public-token exchange, account and balance retrieval, transaction synchronization, identity access, asset reports, and selected product-specific operations.

Martini implementation pattern

Martini workflows call the required Plaid endpoint with protected application credentials and the Item access token where applicable. The workflow validates responses, transforms the provider model into a canonical model, applies business rules, persists state, and returns or forwards a controlled result.

Implementation sequence

Receive an authorized integration request
Create or retrieve the required Plaid Link token
Exchange the public token for an Item access token
Call the product-specific Plaid endpoint
Validate and transform the response
Persist approved data and workflow state

Plaid Webhooks

Plaid provides webhook notifications for selected products and events, including transaction synchronization signals, Item errors, asset report processing, and selected identity, income, investment, payment, or transfer events. Coverage is product-specific rather than universal.

Martini implementation pattern

Martini exposes a receiving API or webhook workflow for Plaid notifications. It validates the request, applies idempotency controls, treats the notification as a signal rather than complete state, and calls Plaid to retrieve current or incremental data before writing downstream results.

Implementation sequence

Receive the Plaid webhook notification
Validate the request and identify the Item or operation
Check the event against the deduplication store
Retrieve current or incremental Plaid state
Process the resulting data and business rules
Record the outcome and return an appropriate response

Transactions Sync

Plaid Transactions supports cursor-based incremental synchronization through /transactions/sync. Responses can contain additions, modifications, removals, and a cursor for continuing across pages.

Martini implementation pattern

Martini loads the cursor associated with the Item, repeatedly calls Transactions Sync until Plaid indicates completion, maps each change type to the target model, and commits the new cursor only after all required downstream writes succeed.

Implementation sequence

Load the stored cursor for the Item
Call Plaid Transactions Sync
Process additions, modifications, and removals
Map and write changes to the target system
Repeat while additional data is available
Commit the cursor after successful processing

Asset Reports and asynchronous processing

Selected Plaid operations, including Asset Report generation, are asynchronous. A report may require creation, processing, and later retrieval, with webhooks or status checks indicating progress where supported.

Martini implementation pattern

Martini starts the report workflow, stores the operation identifier, and waits for a supported webhook or scheduled status check. Once ready, it retrieves and transforms the report, then sends it to the approved underwriting or loan-origination target with duplicate-creation safeguards.

Implementation sequence

Request creation of the Asset Report
Store the operation identifier and requested context
Receive a completion notification or run a status check
Retrieve the completed report
Transform and deliver the report
Record completion and prevent duplicate processing

Common Plaid integration patterns

Pattern 1: Synchronize Plaid Transactions to a finance platform

When to use this pattern

Use this pattern when transaction data must be delivered to NetSuite, QuickBooks Online, or an internal finance store without repeatedly downloading full history. Plaid’s transaction webhook can initiate the process, while the cursor-based API provides the authoritative incremental changes.

Integration direction
Plaid
Martini
NetSuite
Example Mapping
Plaid FieldCanonical FieldTarget Field
transaction_idexternalTransactionIdexternalId
amountamountamount
datetransactionDatedate
merchant_namemerchantNamepayeeName
Martini implementation pattern

Martini receives a selected Plaid transaction notification, loads the Item-specific cursor, loops through Transactions Sync pages, and maps additions, modifications, and removals. It applies account and reconciliation rules, upserts by stable identifiers, retries transient failures with backoff, and commits the cursor only after successful target processing.

Martini capabilities used
  • workflows
  • API consumption
  • webhook receiving
  • data mapping
  • business rules
  • idempotent processing
  • error handling

Pattern 2: Verify accounts and balances during onboarding

When to use this pattern

Use this pattern when an onboarding application needs account ownership, balance, or funding-source information available through the configured Plaid product and connected institution.

Integration direction
Onboarding application
Martini
Plaid
Example Mapping
Plaid FieldCanonical FieldTarget Field
account_idexternalAccountIdaccountId
nameaccountNameaccountName
balances.currentcurrentBalanceavailableBalance
subtypeaccountSubtypeaccountType
Martini implementation pattern

Martini creates a Link token, receives the public token from the application, exchanges it for an Item access token, and retrieves the permitted Accounts and balances. It validates required fields, applies consent and threshold rules, returns a minimized result, and routes Item or institution errors to a reconnection path.

Martini capabilities used
  • API exposure
  • API consumption
  • secure configuration
  • data mapping
  • validation
  • business rules
  • error handling

Pattern 3: Generate Asset Reports for underwriting

When to use this pattern

Use this pattern when a lending or underwriting process requires an Asset Report that may not be available immediately after the request is submitted.

Integration direction
Martini
Plaid
Underwriting system
Example Mapping
Plaid FieldCanonical FieldTarget Field
asset_report_idexternalReportIdreportId
processing_statusreportStatusstatus
accountsverifiedAccountsaccounts
itemssourceItemsconnectedItems
Martini implementation pattern

Martini requests the report, stores its identifier and business context, then waits for a supported Plaid notification or performs bounded status checks. When ready, it retrieves and transforms the report, applies underwriting eligibility rules, delivers it to the target, and prevents duplicate report creation or delivery.

Martini capabilities used
  • workflows
  • API consumption
  • scheduled execution
  • webhook receiving
  • asynchronous orchestration
  • data transformation
  • retry handling

Pattern 4: Manage Item health and reconnection

When to use this pattern

Use this pattern when connected financial institutions can require user action, reauthentication, or reconnection and the business needs reliable operational follow-up.

Integration direction
Plaid
Martini
ServiceNow
Example Mapping
Plaid FieldCanonical FieldTarget Field
item_idconnectionIdu_plaid_item_id
error_codeconnectionErrorCodeu_provider_error_code
statusconnectionStatusstate
institution_idinstitutionIdu_institution_id
Martini implementation pattern

Martini receives selected Item lifecycle notifications, validates and deduplicates them, stores status and error details, and creates or updates a ServiceNow case when customer action is required. Temporary provider failures receive bounded retries, while non-recoverable or consent-related states are routed directly to a reconnection workflow.

Martini capabilities used
  • webhook receiving
  • workflows
  • data mapping
  • business rules
  • idempotency
  • error handling
  • API exposure

Applications commonly integrated with Plaid

Plaid can be integrated with named enterprise and financial applications when account connectivity, transaction data, identity information, verification, or Item lifecycle events need to participate in broader business processes. These are architectural patterns rather than confirmed Plaid-native application connectors; the target application’s own APIs and permissions must be evaluated.

Application Scenario Direction Martini Pattern
Salesforce Enrich customer or applicant processes with verified account, identity, or financial status information where consent and data-minimization requirements permit. Plaid → Martini → Salesforce Martini exposes a Link-token workflow, exchanges the public token, retrieves the required Plaid data, applies consent and field-selection rules, and writes normalized values to Salesforce through its APIs. Failed Item states are routed for follow-up rather than repeatedly retried.
NetSuite Import normalized account and transaction data into reconciliation and financial operations workflows. Plaid → Martini → NetSuite A Martini webhook or scheduled workflow loads the Item cursor, calls Plaid Transactions Sync until complete, maps additions, modifications, and removals into NetSuite records, and commits the cursor only after successful target processing.
QuickBooks Online Support accounting workflows by synchronizing connected bank-account and transaction information. Plaid → Martini → QuickBooks Online Martini retrieves incremental Plaid transaction pages, normalizes dates, amounts, account identifiers, and status values, applies duplicate and reconciliation rules, and sends accepted data to QuickBooks Online through its APIs.
Workday Support permitted financial-wellness, payroll-adjacent verification, or employee financial-data workflows. Workday → Martini → Plaid Martini receives an authorized process request from Workday or an associated portal, creates a Plaid Link token, handles the server-side token exchange, and returns only the approved verification result rather than unnecessary financial history.
ServiceNow Create support cases or tasks when an Item requires reconnection, user action, or investigation. Plaid → Martini → ServiceNow Martini receives selected Plaid Item webhook notifications, records status and error details, deduplicates repeated events, and creates or updates ServiceNow cases with controlled customer and Item context.
Stripe Coordinate account verification, funding-source, and payment operations across Plaid and Stripe workflows. Stripe → Martini → Plaid Martini orchestrates the business process across both APIs, keeps Plaid access tokens and Stripe identifiers separate, applies consent and eligibility rules, and uses compensating or retry workflows when one provider is temporarily unavailable.
Marqeta Combine bank-account connectivity with card-program onboarding, funding, or account-management processes. Plaid → Martini → Marqeta Martini coordinates application events, retrieves the minimum required Plaid account or verification data, maps it to the Marqeta process model, and routes institution or Item exceptions to an operational workflow.
Zendesk Open or update support tickets when a Plaid Item requires reconnection or customer action. Plaid → Martini → Zendesk A Martini webhook workflow validates and deduplicates Plaid Item notifications, maps error and reconnection context to Zendesk fields, and uses idempotent upsert logic to avoid duplicate tickets.

How to build a Plaid integration in Martini

Objective

Establish Plaid application and Item authentication without exposing credentials or access tokens to clients, workflow definitions, or logs.

Instructions in Martini

  • Store client_id and secret in protected environment configuration.
  • Define secure handling for each Item access token.
  • Keep sandbox, development, and production settings separate.
  • Restrict logging of credentials and sensitive financial data.

Objective

Select the trigger that matches the Plaid product and required freshness, recognizing that webhook coverage is product-specific.

Instructions in Martini

  • Use a Martini API or webhook workflow for selected Plaid notifications.
  • Use a scheduler for reconciliation where webhook coverage is incomplete.
  • Use an application request to initiate Link-token and onboarding flows.
  • Prevent concurrent synchronization jobs for the same Item.

Objective

Call the appropriate Plaid endpoint and retrieve current or incremental state rather than treating a webhook payload as the complete dataset.

Instructions in Martini

  • Create Link tokens and exchange public tokens when required.
  • Call the relevant product endpoint with the Item access token.
  • Use Transactions Sync with the stored Item-specific cursor.
  • Track asynchronous report identifiers and processing state.

Objective

Coordinate API calls, pagination, asynchronous processing, state persistence, and downstream actions in a maintainable Martini workflow.

Instructions in Martini

  • Use workflow branches for success, retryable failure, and user-action states.
  • Loop through all available transaction pages.
  • Use callbacks or scheduled status checks for asynchronous reports.
  • Persist operational state needed for safe resumption.

Objective

Convert Plaid’s product- and institution-dependent responses into a stable internal model while applying consent and data-minimization rules.

Instructions in Martini

  • Map Accounts, Transactions, Identity, Items, and reports to canonical fields.
  • Handle additions, modifications, and removals explicitly.
  • Validate required fields and approved products before downstream delivery.
  • Preserve or safely ignore unknown provider fields according to the target contract.

Objective

Deliver approved, normalized data to enterprise applications, databases, or APIs using idempotent target operations.

Instructions in Martini

  • Upsert by stable Plaid or canonical identifiers where appropriate.
  • Commit cursors only after target writes succeed.
  • Create or update operational cases for Item errors.
  • Return only the minimum approved information to client applications.

Common Plaid data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
ItemRepresents the connection between a Plaid client and a financial institution, including lifecycle and error state.CRM, onboarding applications, ServiceNow, support platforms, internal databasesMartini stores the Item association and status, processes lifecycle notifications, and routes reconnection or user-action requirements without exposing sensitive credentials.
Access TokenCredential used to access data for a specific Item after public-token exchange.Secure secrets store, integration database, workflow stateMartini keeps access tokens in protected environment configuration or secure application storage, scopes them to the relevant tenant or Item, and excludes them from logs and client responses.
InstitutionFinancial institution associated with an Item or available through Plaid connectivity.Onboarding applications, CRM, risk and support systemsMartini maps institution identifiers and availability data where required and preserves provider-specific values without assuming uniform coverage.
AccountBank, credit card, loan, investment, or other account associated with an Item.NetSuite, QuickBooks Online, underwriting systems, internal finance storesMartini maps account identifiers, types, balances, and institution context while tolerating product- and institution-specific fields.
TransactionFinancial activity returned by Plaid Transactions and synchronized through additions, modifications, and removals.NetSuite, QuickBooks Online, finance data stores, reconciliation platformsMartini uses the Item-specific cursor, processes all change categories idempotently, applies categorization or business rules, and commits the cursor after successful target writes.
IdentityAccount-holder identity information such as names and addresses, subject to product availability and consent.Salesforce, onboarding systems, underwriting platforms, compliance workflowsMartini applies field minimization and consent rules, maps verified values to the target model, and prevents sensitive data from being unnecessarily logged or replicated.

Authentication and security considerations

Application and Item credentials

Plaid server requests use application credentials such as client_id and secret, while product calls use an Item-specific access_token obtained through the public-token exchange. Store both in protected, environment-specific configuration or secure application storage.

Consent and data minimization

Configure Link for only the products required by the use case and preserve the associated consent context. Do not expose Item access tokens to browsers or external clients, and avoid copying or logging unnecessary financial and identity data.

Webhook protection

Protect the Martini receiving API with appropriate authentication and authorization controls, validate incoming Plaid notifications according to Plaid guidance, and treat webhook payloads as signals that may require a follow-up API request.

  • Separate sandbox, development, and production credentials.
  • Restrict workflow logs containing tokens or sensitive financial information.
  • Apply retention and deletion controls to Accounts, Transactions, Identity data, and access tokens.

Operational considerations for Plaid integrations

Rate limits and retries

Use bounded retries with backoff for transient Plaid failures. Do not repeatedly retry authentication, consent, or Item-state errors that require remediation.

Pagination and cursors

Transactions Sync can return multiple pages. Persist an Item-specific cursor only after all corresponding additions, modifications, and removals have been processed successfully.

Idempotency and concurrency

Webhook deliveries may repeat. Deduplicate notifications and use Item, account, transaction, report, and event identifiers to prevent duplicate writes or concurrent synchronization jobs.

Schema and institution variation

Plaid responses vary by product, institution, account type, region, and availability. Use tolerant mappings, test representative sandbox and production responses, and preserve provider error details.

Asynchronous operations

Asset Reports and other long-running operations require state tracking, supported callbacks or scheduled checks, and safeguards against duplicate creation or delivery.

Why use Martini instead of scripts or point-to-point integrations?

Centralized orchestration

Martini coordinates Link-token creation, public-token exchange, product API calls, webhook handling, cursor-based synchronization, asynchronous processing, and downstream delivery in reusable workflows.

Maintainable transformations

Instead of embedding provider-specific logic in multiple scripts or point-to-point mappings, Martini centralizes data mapping, validation, consent rules, and target-specific transformations.

Operational reliability

Martini provides workflow-level handling for retries, idempotency, pagination, state persistence, error routing, and monitoring so Plaid integrations can be operated consistently across environments.

Controlled APIs

Martini can expose an API façade that keeps Plaid credentials and Item access tokens server-side while presenting client applications with approved, normalized business operations.

Frequently asked questions

How can Plaid be integrated with enterprise systems?

Plaid can be integrated through its REST API, Link-token and public-token exchange flow, Item access tokens, product-specific webhook notifications, cursor-based Transactions Sync, and selected asynchronous report and document retrieval capabilities. Enterprise workflows typically use Plaid notifications to initiate API retrieval, then map approved financial data into business applications.

Can Martini integrate with Plaid?

Yes. No native Martini Plaid connector is documented in the supplied materials, but Martini can consume Plaid’s REST API, receive selected Plaid webhook notifications, securely manage application credentials and Item access tokens, orchestrate synchronization, and transform Plaid data for enterprise targets.

Do I need a connector to integrate Plaid with Martini?

No. A dedicated Plaid connector is not required. Martini can use Plaid’s confirmed native integration mechanisms, including REST APIs, product-specific webhooks, Link-token flows, Item access tokens, cursor-based synchronization, and asynchronous report processing.

Is there any extra Lonti cost to integrate Plaid with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate Plaid. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Plaid, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.

Which Plaid integration methods should an enterprise use?

Plaid’s REST API is the primary method for server-side integration. Use Link and public-token exchange to establish an Item, Item access tokens for product calls, Transactions Sync for incremental transaction data, and webhooks where the required product event is supported. Asset Reports and other asynchronous operations should use status tracking and supported notifications.

Can Martini receive Plaid webhooks and event notifications?

Yes. Martini can expose a receiving API or webhook workflow for Plaid notifications. Coverage is product-specific, so integrations should treat webhooks as signals, validate and deduplicate them, retrieve current state from Plaid when needed, and use scheduled reconciliation where event coverage is incomplete.

How should Plaid data synchronization, mapping, and retries work?

For Transactions, store a cursor per Item and process additions, modifications, and removals until synchronization is complete. Martini can map Plaid objects into canonical and target models, apply consent and validation rules, use idempotent writes, and retry transient failures with bounded backoff. Cursors should be committed only after successful downstream processing.

Can Martini expose an API façade for Plaid?

Yes. Martini can expose a controlled API that creates Link tokens, accepts application requests, returns approved normalized results, or starts a business workflow. This façade can keep Plaid credentials and Item access tokens server-side while enforcing authentication, authorization, validation, consent, and data-minimization policies.