Release 2.4.0 - Add verification attempt-assets endpoints and card scheduled_activation_date - #209

[david-ruiz-cko]

⚠️ Breaking changes (see at the bottom)

This release 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

• 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: Concerns worth a look

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

This release adds paginated attempt/asset endpoints to verification clients, renames activation_date to scheduled_activation_date on UpdateCardRequest, fixes If-Match header casing, and bumps to 2.4.0. The diff is partial — the core SDK source changes (ApiClient, verification clients, request models, UpdateCardRequest) are not visible, so the most important claims cannot be verified.

Concerns

• The diff shown contains only version.rb and an integration spec fix; the PR description claims substantial changes to ApiClient, IdDocumentVerificationClient, AddressDocumentVerificationClient, FaceAuthenticationClient, request models, and UpdateCardRequest, but none of those files appear in the diff — the reviewer cannot verify correctness, missing error paths, or breaking-change scope from what is shown.
• The integration spec changes the processing_details currency from GBP to USD with a detailed comment explaining the API rejects GBP; this looks like a genuine fix for a broken test, but since this is an integration spec it implies the live API behaviour changed or was always stricter than the old test assumed — worth confirming the test now passes in CI.
• The claimed breaking change (activation_date → scheduled_activation_date on UpdateCardRequest) cannot be verified because UpdateCardRequest is not in the diff; the reviewer should ensure the file is included and that the old attribute is fully removed or raises NoMethodError as stated.
• The If-Match header casing fix (Symbol keys → String keys) is described as a behaviour change; the ApiClient changes are not visible in this diff, so the fix cannot be confirmed as implemented correctly or tested.
• No tests for the new paginated attempt/asset endpoints are visible in this diff; the reviewer should verify that unit or integration tests exist in the full PR for the new methods described in the PR body.
• The version bump from 2.3.0 to 2.4.0 is consistent with the stated breaking changes (renamed field), but cannot be fully assessed without seeing all changed files.

---

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

• no_low_class_matched
• prod_source_modified

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 2

---

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

[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