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 introduces several enhancements and realignments to the Identities SDK, focusing on improved spec alignment, support for paginated asset and attempt retrieval, and more robust header handling. The most significant changes include new and updated API client methods for retrieving paginated attempts and assets, enhanced request models with clearer documentation and additional fields, and a safer, spec-compliant approach to HTTP header mapping.

API Client Enhancements

• Added paginated retrieval methods for attempts and assets to IdDocumentVerificationClient, AddressDocumentVerificationClient, and FaceAuthenticationClient, allowing users to fetch attempt details and uploaded assets with pagination support. [1] [2] [3] [4] [5]
• Updated invoke_patch in ApiClient to accept and forward custom headers, matching the behavior of other HTTP verbs.

Request Model Realignment and Documentation

• Realigned request classes (IdDocumentVerificationRequest, FaceAuthenticationRequest, AddressDocumentVerificationRequest) with the latest API specification, adding or clarifying attributes such as user_journey_id, declared_data, and phone_number, and marking deprecated fields with clear documentation. [1] [2] [3] [4]
• Improved attribute documentation to specify requirements, formats, and deprecation status, making the SDK easier to use and reducing integration errors. [1] [2] [3] [4]

HTTP Header Handling

• Refactored extra HTTP header mapping in ApiClient to use an explicit attribute-to-header string map, ensuring spec-compliant casing and eliminating subtle bugs in header emission.

Shared Types and Internal Structure

• Added shared types for phone numbers, addresses, and query filters, and ensured they are required at the top level for consistent SDK usage. [1] [2]

Minor Improvements

• Updated and clarified comments and method signatures throughout the SDK for better maintainability and developer experience. [1] [2] [3]

These changes improve the SDK's alignment with the underlying API, enhance developer usability, and ensure future compatibility.

⚠️ Breaking changes

Kind	Change
removed	activation_date -> scheduled_activation_date on UpdateCardRequest
behaviour	If-Match is now sent as If-Match. It was previously sent as If-match, because the header hash used Symbol keys and Faraday rewrites those. Servers treat header names case-insensitively, so no integration should notice, but the bytes on the wire changed

Note: the renamed attribute raises NoMethodError on the old name, so this break is visible rather than silent. The new query and headers parameters default to nil.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:1259>250

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 36

---

_{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 — 1259>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: Concerns worth a look

This PR needs a human approval. Before you give it, these are the things I'd want resolved.

The PR adds paginated attempt-assets endpoints, new shared types, a CardUpdateHeaders class, and a refactored header-mapping path. The implementation and tests look sound overall, but there is one concrete breaking change that callers will not expect, and one inconsistency in how ENV vars are accessed across the integration specs.

Concerns

• Breaking rename in UpdateCardRequest: activation_date has been silently renamed to scheduled_activation_date with no deprecation alias and no migration note. Any existing caller setting .activation_date = will silently stop sending that field (Ruby's attr_accessor does not raise on unknown setters if the old accessor is simply gone). The PR description says deprecated fields are "retained rather than removed" for backward compat, but this field was not retained — it should be if that policy applies here.
• Inconsistent ENV access in integration specs: The new id_document_verification_integration_spec.rb additions use ENV['CHECKOUT_IDV_DOC_ID'] (bracket access, returns nil silently) while the new address_document_verification_integration_spec.rb additions use ENV.fetch('CHECKOUT_ADV_ID', nil) (explicit fetch). This is minor but one of them will suppress a missing-env-var failure silently; both should be consistent, preferably using fetch with no default so CI fails loudly when the var is absent.
• user_journey_id changed from Required to Optional on IdDocumentVerificationRequest: The inline comment marks it [Optional] and the class comment cites the spec requiring it — the address document verification counterpart marks it [Required]. If the spec truly requires it for IDDV, the doc is wrong; if it is genuinely optional there, that is fine but should be confirmed against the spec.
• No tests for FaceAuthenticationClient.get_face_authentication_attempt_assets: The new pagination spec file covers ADV, IDDV, IDV, and FA list-attempts, and adds an assets test for ADV and IDDV, but there is no unit or integration test for FaceAuthenticationClient.get_face_authentication_attempt_assets (which was not added in this PR but was already present). The PR updates its doc comment to reference the new typed filter; a matching test showing the typed filter is forwarded is missing.
• CardUpdateHeaders is never required from issuing.rb — issuing_client.rb now accepts it as a parameter type, and card_update_headers.rb is required from issuing.rb, so that part is fine. However the spec file references the class at CheckoutSdk::Issuing::CardUpdateHeaders which will only resolve if issuing.rb (or some other entry point) has been required first; this is consistent with the rest of the SDK so it is not a bug, just worth confirming the top-level require ordering is unchanged.

⚠️ 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:1475>250

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 37

---

_{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 — 1475>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
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