InFlow Parsing Guide

InFlow parses MCA application packages and bank statement PDFs. It can return parsed application fields, financial metrics, statement coverage, and review details.

Use POST /v1/inflow/parsing to submit one application package.

Request Format

InFlow accepts multipart/form-data.

• metadata: optional JSON metadata, including optional application data.
• files: one or more PDF files.

ZIP files are not accepted.

Each package can include up to 100 PDFs. Each PDF must be 25 MB or smaller.

Classification

Use classification to tell B2 Systems what kind of PDFs you are sending.

bank_statements means all PDFs are bank statements.

auto means the package may include both bank statements and a merchant application form.

If you are only submitting bank statements from your CRM, use bank_statements.

Create Deal

create_deal defaults to false.

Set it to true when you want the parsed application to create a dashboard deal.

For broker deals, auto_submit defaults to auto, which inherits the dashboard auto-submit settings. Use disabled to guarantee that the created deal is not auto-submitted. The API cannot force auto-submit when the dashboard setting or entitlement is off. Funder-owned deals do not use auto-submit.

{
  "classification": "bank_statements",
  "create_deal": false,
  "auto_submit": "auto",
  "external_id": "crm-deal-10042"
}

Submit PDFs

curl https://api.b2systems.io/v1/inflow/parsing \
  -H "Authorization: Bearer $B2_API_KEY" \
  -H "Idempotency-Key: crm-deal-10042-inflow-v1" \
  -F 'metadata={
    "classification": "bank_statements",
    "create_deal": false,
    "auto_submit": "auto",
    "external_id": "crm-deal-10042"
  };type=application/json' \
  -F "[email protected];type=application/pdf" \
  -F "[email protected];type=application/pdf" \
  -F "[email protected];type=application/pdf"

The response returns a parsing_id.

Application Data and Validation

The optional application object in metadata uses the same application shape as the Deal and TrueSight APIs. Tax-ID country fields accept US or CA. Phone-country fields accept US or CA, and supported phone numbers are stored in E.164 format.

When a supplied tax ID is invalid or ambiguous, the API returns 422 Unprocessable Entity with the validation_failed code and does not queue the parsing job. Include the applicable tax-ID country and type when the value cannot be resolved unambiguously.

Safe Retries

For write requests, you can send Idempotency-Key to safely retry the same request if your system times out or loses the response.

Use one unique key per logical submission. Retrying the same metadata and PDF contents with the same key returns the original queued parsing job. Multipart ordering and filenames do not change the identity of the PDF package; the actual PDF bytes do. Reusing the same key with different files or metadata returns a conflict.

Check Status

curl https://api.b2systems.io/v1/inflow/parsing/a8f58172-cb32-4aa8-8429-1d3c4bf150f4 \
  -H "Authorization: Bearer $B2_API_KEY"

Common statuses are:

• queued
• processing
• completed
• failed
• superseded

superseded is terminal. It means a newer processing run replaced this job. A superseded job does not publish a completed or failed webhook.

An InFlow job remains processing until every submitted PDF reaches a terminal result. Do not treat partial statement results as a completed package.

Parsing Details

When parsing is complete, parsing_details explains what B2 Systems found and whether anything needs review.

Important fields include:

• review_status: whether the parsed data is ready or needs review.
• can_continue: whether the package has enough information to continue.
• application_fields: application fields checked during parsing.
• bank_statements: statement-level parsing checks and values.
• coverage: statement month coverage.
• statement_issue_document_ids: statements that need review.
• application_issue_field_keys: application fields that need review.

Empty arrays mean B2 Systems checked that area and found no items to return.

Failed or unreconciled bank statements remain in bank_statements and are returned as review items. A month-to-date statement also remains visible, but it does not satisfy a required full statement month in coverage.

Credits

Each original bank-statement PDF can consume at most one credit, even when the processor returns multiple accounts, months, or result rows for that PDF. Merchant application PDFs do not consume statement-processing credits.

A terminal failed or unreconciled bank statement consumes one credit because the document was processed and is returned for review. Startup, configuration, transport, timeout, and internal orchestration failures do not consume a credit unless an individual bank statement already reached a terminal result. In a partial package, only terminal bank statements consume credits.

If the exact same PDF bytes are processed again by the same organization within 30 days, the PDF is not counted again. Renaming the file does not change that result. Editing any bytes creates a different document and consumes a new credit. The same exact PDF processed after 30 days consumes a new credit, and the same PDF submitted by a different organization counts for that organization.

Credits are reflected in the parsing response and in GET /v1/usage.