Plaid Core Exchange – Gotchas

feed_status reads back as pending for every account in this release.

Plaid requires holder contact data on every account. account_holders, emails, addresses and phone_numbers must each carry at least one entry, or the account is rejected with one contact_required violation per missing list. Each list holds at most 10 items, and only the fields the bank-feed provider stores are forwarded: an address keeps type, line1–line3, city, state, postal_code and country, and id is dropped from every item.

• Each holder needs first_name and last_name, or business_name when type or relationship marks it as a business.
• At least one phone must be servable: type one of mobile, home, work, office, personal or fax, at most 15 digits across area_code and number, and the country code in country_code rather than a leading + in number.
• Each address needs line1, city and country as an uppercase ISO 3166 alpha-2 code. Address lines, city and state are limited to 64 characters and postal_code to 10. Each email must be a valid address.

An address that carries only fields the bank-feed provider does not store (for example only string) is dropped, and the account is then rejected as if the list were empty.

Creating an account is not idempotent: posting the same source_account_id twice creates two accounts, and Plaid serves both. If a create times out, list the accounts before retrying.

A connection only becomes callable once it reports ready, so a newly created one can briefly stay in the added state. Re-check it and retry rather than reading added as a failure.

Omit an optional field instead of sending null for it: null is rejected on type and on the holder name fields. feed_status is not returned on this create response — read the account back to see it.

Plaid cannot read the data yet: client authentication between Plaid and Apideck's FDX data provider is still pending, so ingested accounts are stored but not yet served to Plaid.

feed_status reads back as pending for every account in this release.

List responses carry statement metadata only — transactions is never included, however many statements the page holds. Fetch a single statement by id to read its transactions.

A successful create does not mean Plaid has the statement. This connector is pull-based: the statement is stored on the Apideck side and waits there for Plaid to read it. Because delivery happens later and out of band, status reads back as pending and does not advance to success in this release; a status other than pending sent on write is rejected.

Statements are validated on the way in, with the same rules as intuit-bank-feeds: at most 1000 transactions, unique source_transaction_ids, non-decreasing posted_date, posted transactions only, description up to 255 characters, an explicit timezone offset on every timestamp, and null rejected rather than ignored. A rejected statement comes back with every violation at once.

transactions is returned here, unlike the list operation, which carries statement metadata only. Fetching a statement by id is the only way to read its transactions.

status reads back as pending. See the create operation for why it does not advance to success in this release.