Release 1.10.0 - Support for negotiating Accounts API schema version via the Accept header - #188

[david-ruiz-cko]

This release adds support for Accounts API v3.0 onboarding and extends the SDK to handle new business requirements. The main changes include introducing new models and enumerations for onboarding, updating existing models with new attributes, and enhancing the AccountsClient to support versioned Accept headers for API requests.

Accounts API v3.0 onboarding support:

• Added new models and enums for onboarding, including AgreedTerms, ProcessingDetailsAch, ProcessingDetailsPayments, CompanyPosition, EntityRoles, NationalIdType, Citizenship, RepresentativeIndividual, FinancialStatements, FinancialStatementsType, and ArticlesOfAssociation. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]

• AccountsClient methods (create_entity, get_entity, update_entity, get_entity_requirements) now accept an optional schema_version parameter (defaulting to '3.0') and send a versioned Accept header, enabling API version negotiation. [1] [2] [3] [4]

Model enhancements and new attributes:

• Company now supports additional_trading_names (array of strings) and is_registered_company (boolean). [1] [2]
• DateOfIncorporation adds a day attribute.
• Phone adds a country_code attribute.
• OnboardEntity and Representative models are extended with new attributes for v3.0 (e.g., agreed_terms, individual, company_position, ownership_percentage). [1] [2] [3] [4]
• OnboardSubEntityDocuments now supports financial_statements and uses the new ArticlesOfAssociation type. [1] [2] [3]
• ProcessingDetails adds average_order_fulfillment_time and a nested payments attribute.

Enumerations and types:

• BusinessType expanded with several new business entity types to cover more onboarding scenarios.

These changes collectively enable the SDK to support the latest onboarding requirements and improve flexibility for future API versions.

[agent-wall-e]

🟡 Risk Classification: MINOR

Approval route: AI Review + Human Approval
Rollback controls: Staged rollout + rollback

Classification reasons

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 1

---

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
no_low_class_matched	informational	§2.2 (fall-through)	None of the deterministic Low classes (§2.2.3, §2.2.4, §2.2.7, docs-only) applied; classifier fell through to LLM evaluation.
prod_source_modified	informational	§2.1 M7 (informational)	At least one file is non-doc, non-test, non-IaC — i.e. application source code was modified.

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud