Intuit Bank Feeds – Gotchas

feed_status reads back as pending for every account in this release — it does not yet reflect whether QuickBooks has picked the feed up.

No QuickBooks OAuth connection is required or used. intuit-bank-feeds is a separate connector with its own connection lifecycle, so a bank-feeds-only integration never authenticates to QuickBooks: connecting quickbooks does nothing for this connector, and this connector needs nothing from it.

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.

Field handling is stricter than the unified contract: null is rejected rather than ignored, so omit an optional field instead of sending null for it. feed_status is not returned on this create response — read the account back to see it.

feed_status reads back as pending for every account in this release — it does not yet reflect whether QuickBooks has picked the feed up.

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 QuickBooks has the statement. This connector is pull-based: the statement is stored on the Apideck side and waits there for Intuit's scheduled pull. That is a fundamental difference from xero, where a successful push means Xero already holds the data. 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, and a violation is rejected — never silently dropped:

• At most 1000 entries in transactions.
• Every source_transaction_id must be unique, both within the statement and against transactions already submitted for the same bank feed.
• Transactions must be in chronological order: posted_date must be non-decreasing across the array.
• Posted transactions only — pending or authorization-hold transactions are not accepted.
• description is limited to 255 characters.
• Every timestamp needs an explicit timezone offset: start_date, end_date and each transaction's posted_date must end in Z or ±hh:mm. A bare local datetime such as 2026-01-15T12:00:00 is rejected, even though the unified date-time format permits it.
• null is rejected rather than ignored. Omit an optional field instead of sending null for it.

A rejected statement comes back with every violation at once, each naming the rule it broke, so a single round trip shows all of them.

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.