feature/INT-1695 - Add verification attempt-assets endpoints and card scheduled_activation_date

[david-ruiz-cko]

⚠️ Breaking changes (see at the bottom)

This pull request 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

• exceeds_bounded_scope:1684>250

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 73

---

_{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
exceeds_bounded_scope — 1684>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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.

Large additive SDK change introducing new verification attempt-assets endpoints, multiple new model classes, breaking renames (signedUrl→pdfReport, activationDate→scheduledActivationDate, clientInformation moved, several fields retyped to enums). The code looks structurally consistent across the visible diff, but the truncation means roughly 35 files cannot be assessed.

For you to decide

• The diff is explicitly truncated ('35 more files omitted'), so completeness cannot be verified — the card scheduledActivationDate changes, identity verification client changes, and several other claimed changes are not visible.
• Breaking change: signedUrl renamed to pdfReport in AddressDocumentVerificationReportResponse (and claimed for IdDocument and Identity variants too) — callers deserializing or referencing signedUrl will silently get null at runtime if JSON field name also changed; confirm the API actually returns pdf_report not signed_url.
• Breaking change: clientInformation removed from BaseAttemptResponse and pushed down to FaceAuthenticationAttemptResponse and (presumably) IdentityVerificationAttemptResponse — AddressDocumentVerificationAttemptResponse and IdDocumentVerificationAttemptResponse will silently drop this field if it's present in API responses; confirm this is intentional.
• Breaking change: five country/nationality fields changed from String to CountryCode enum — if the API ever returns a country code not present in the CountryCode enum, Gson will deserialize to null without any warning; the enum coverage should be verified as exhaustive.
• New RiskLabel enum has only three values (MULTIPLE_FACES_DETECTED, MCC_NOT_CONFIDENT, RISKY_DOCUMENT_FORMAT) — same null-on-unknown-value risk; if the API can return additional risk labels, existing list elements will silently become null.
• AttemptAssetsQueryFilter is referenced in the getIdDocumentVerificationAttemptAssets and address equivalent methods but the file is not shown in the diff — cannot confirm its structure matches AttemptsQueryFilter (skip/limit) or whether it adds additional filter fields.
• The new patchAsync/patch overloads with IHeaders delegate correctly to sendRequestAsync/sendRequestSync with headers, consistent with existing patterns; no logic error visible here.
• No new tests are visible in the truncated diff — a change of this scope (new endpoints, breaking field renames, type changes) warrants test coverage confirmation from the reviewer.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

_{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}

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:1806>250

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 75

---

_{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
exceeds_bounded_scope — 1806>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:1806>250

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 75

---

_{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
exceeds_bounded_scope — 1806>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:1806>250

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 75

---

_{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
exceeds_bounded_scope — 1806>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:1806>250

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 77

---

_{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
exceeds_bounded_scope — 1806>250	classifying	§2.1 M8	More than 250 non-test, non-doc, non-lockfile lines changed.

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
3 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