Skip to main content

​
How Lead versions its APIs

Lead versions per resource, in the URL path. Different resources sit at different versions because they ship and evolve independently — the version prefix tells you which contract you’re on, and nothing else. The current version of every resource: Sandbox simulators live under the corresponding version (/v1/simulate/…, /v2/simulate/…, plus /v0/fundings/{id}/advance and /v0/simulate/lending/disbursements/{id}/advance). A lower number does not mean less stable: /v0 resources are production APIs. A resource’s version only increments when Lead must make a breaking change to it — as with Wires V2, driven by Fedwire’s ISO 20022 mandates.

​
How we make changes

Additive changes are not breaking. Lead may, without a version change: add new API endpoints; add new optional request fields; add new response fields; add new values to enums that are documented as extensible; add new event types; increase documented limits. Your integration should tolerate unknown response fields and unknown event types. Major breaking changes get a new version, notice, and sandbox time. Removing or renaming fields, changing types or semantics, or removing endpoints happens only in a new resource version, announced in Upcoming Changes with a migration guide, and available in sandbox before you’re required to move.  Deprecations follow the same lifecycle. When a version is scheduled for retirement, the timeline appears in Upcoming Changes (Announced → Sandbox Available → Enforcement Soon → Released) and the old version keeps working until the stated enforcement date.  Beta APIs are the exception. Resources labeled API — Beta may change without a version increment, but these changes will be announced in advance and our technical account team will work with you to implement the changes.