Release 8.4.0 - Add verification attempt-assets endpoints and card scheduled_activation_date

[david-ruiz-cko]

⚠️ Breaking changes (see at the bottom)

This release adds support for retrieving paginated address document verification attempts and their associated assets (such as document images), and introduces several new response models to represent these assets. It also enhances the ApiClient interface to allow custom headers for PATCH requests. Additionally, it improves type safety for address country codes and updates the report response model.

Address Document Verification API enhancements:

• Added methods to AddressDocumentVerificationClient and its implementation to retrieve paginated verification attempts (with optional query filters) and to fetch assets (document images) uploaded for a specific attempt, both asynchronously and synchronously. [1] [2] [3] [4] [5] [6] [7] [8]
• Introduced new response models: AddressDocumentVerificationAttemptAsset, AddressDocumentVerificationAttemptAssetType, and AddressDocumentVerificationAttemptAssetsResponse to represent and paginate assets. [1] [2] [3]

ApiClient interface improvements:

• Added overloaded patch and patchAsync methods to ApiClient and its implementation, allowing custom headers to be passed with PATCH requests. [1] [2] [3] [4]

Type safety and model updates:

• Changed the country field in the Address response model from String to the CountryCode enum for better type safety. [1] [2]
• Renamed the signedUrl field to pdfReport in AddressDocumentVerificationReportResponse and improved its documentation.…on_date

⚠️ Breaking changes

Kind	Change
removed	activationDate -> scheduledActivationDate on CardRequest, UpdateCardRequest, CardDetailsResponse, including the builder field name
removed	signedUrl -> pdfReport on AddressDocumentVerificationReportResponse, IdDocumentVerificationReportResponse, IdentityVerificationReportResponse
moved	clientInformation off BaseAttemptResponse onto FaceAuthenticationAttemptResponse and IdentityVerificationAttemptResponse
moved, retyped	riskLabels List -> List on FaceAuthenticationResponse and IdentityVerificationResponse, and added to AddressDocumentVerificationResponse
retyped	declaredData DeclaredData -> IdentityDeclaredData on IdentityVerificationRequest, CreateAndOpenIdentityVerificationRequest, IdentityVerificationResponse
retyped	clientInformation ClientInformation -> IdentityVerificationClientInformation on IdentityVerificationAttemptRequest and IdentityVerificationAttemptResponse
retyped	five country fields String -> CountryCode: Address.country, ClientInformation.preSelectedResidenceCountry, DocumentDetails.documentIssuingCountry, DocumentDetails.nationality, VerifiedIdentity.nationality
builder	ClientInformation and DeclaredData are no longer final and moved from @builder to @SuperBuilder so they can be subclassed. X.builder() still works; only code that names the generated builder type explicitly is affected

Note: the PhysicalCardRequest and VirtualCardRequest constructors keep their arity and parameter types, so positional constructor calls still compile. Only the parameter name changed.

[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 6b4ce2b3b45a…}

[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}

[agent-wall-e]

🔵 Advisory review: Sound, but needs your judgement

This PR needs a human approval. The code itself reads as correct; whether it should land depends on context I don't have.

The diff provided contains only a version bump from 8.3.0 to 8.4.0 in gradle.properties, while the PR description claims extensive breaking changes and new features — the reviewer must verify the actual code changes are present and correct before approving.

For you to decide

• The diff is partial: only gradle.properties is visible, but the PR claims changes to AddressDocumentVerificationClient, ApiClient, Address model, CardRequest, and multiple response models — none of which can be verified here.
• The PR advertises multiple breaking changes (field renames, type changes, builder modifications) that a human must confirm are correctly implemented and documented in the changelog or migration guide.
• Version bump to 8.4.0 is consistent with the described scope of breaking changes, but the reviewer should confirm the release notes or changelog accurately reflects all breaking changes listed in the PR body.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[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