Skip to main content
Lead is making two connected changes to how you integrate: moving every integration workflow from files to APIs, and unifying the platform’s object model so the same concepts work the same way across every product. This page is where we describe those changes. Every other page in these docs describes the platform as it works today, and Integration Surfaces by Product states, product by product, exactly what that is.

​
Why the Platform Works the Way It Does Today

Lead’s platform has two integration surfaces. The core surface covers the accounts Lead operates for your program. The user surface covers the products your customers hold. Lead built them at different times for different purposes, so the same concept can take a different shape depending on which surface you work with. That difference is real, and the upcoming unified object model closes it.

​
What’s Changing

From files to APIs. Some workflows run on APIs today and some run on daily SFTP files. Integration Surfaces by Product shows the current state for each product. Over time, every file-based workflow gains an API equivalent, and new programs integrate entirely over APIs. A unified object model. Both surfaces move to the same shape. Three changes matter most:
  • Balances and Transactions become API objects on the core surface. You read a core balance or transaction directly from the API instead of only from daily reports. This change closes the file dependency described in Integration Surfaces by Product.
  • Account Numbers point to a Balance, not an Account. A customer’s Account Number attaches to that customer’s balance directly, which removes the routing ambiguity that exists when an account holds more than one balance.
  • IDs gain typed prefixes. Typed IDs, such as core_account_* and user_account_*, replace the single account_id used across both surfaces today, so an object’s ID indicates which surface it belongs to. Treat IDs as opaque strings and do not parse meaning out of them.
  • The daily receivables sale becomes an API. Credit and lending programs purchase each day’s receivables through a sale object and webhooks instead of the Sales Request / Response file exchange — same daily cycle, same settlement amounts, structured and same-day.

​
What Is Not Changing

  • The APIs and file feeds you use today keep working.
  • You do not need to re-integrate from scratch.
  • Nothing requires action from you until your program’s migration window opens, and your Lead team contacts you before it does.

​
Preparing Your Integration Today

Do not build against the new model. Lead publishes API contracts only when they are available to test. The choices you make now determine how much work the transition takes later, and each item below is good practice today regardless. Treat IDs as opaque strings. Store them exactly as Lead returns them. Do not parse them, pattern-match on them, or derive meaning from their format beyond string, unique, and prefixed by object type. Store IDs in a string column with generous length limits. Typed prefixes make IDs longer than they are today. Model balances as their own entity. Do not treat a balance as a field on an account. An account can hold more than one balance, and Account Numbers attach to a balance rather than an account. Integrations that already model balances separately are well-prepared to absorb this change. Record which surface an object comes from. A single account_id shape covers both the core and user surfaces today, and typed IDs make the distinction explicit. Keep that distinction in your own data now and you avoid reconstructing it later. Key reconciliation on object IDs, not file rows. Balances and transactions arrive as daily files today and become API objects later. Reconciliation logic keyed to a filename, line position, or delivery date needs a rewrite at the transition. Logic keyed to the object’s own ID does not.

​
How Changes Reach You

Lead announces every change before it lands. We announce new APIs and required changes in Upcoming Changes, following the lifecycle you already know: Announced, Sandbox Available, Enforcement Soon, and Released. Nothing requires action from you without advance notice, and sandbox access precedes enforcement. Migration happens by cohort. When your program’s migration window opens, your Lead team contacts you with a specific plan. Timing. New programs begin integrating fully over APIs starting late 2026. Existing programs migrate in cohorts through 2027; your Lead team schedules yours with you. Concrete steps are announced in Upcoming Changes as each becomes available to test.