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 structural improvements to the identity verification and face authentication modules. The main updates include adding support for pagination when listing verification attempts, introducing new fields and types for richer applicant data, and enabling retrieval of document/image assets for verification attempts. The changes also improve type annotations and documentation for better clarity and extensibility.

Pagination and Asset Retrieval Enhancements:

• Added support for optional pagination (skip and limit) when listing verification attempts in the get...Attempts methods for identity, ID document, address document, and face authentication clients, using the new AttemptsQueryFilter class. These methods now use the new query method in ApiClient to handle query parameters. [1] [2] [3] [4] [5] [6]
• Introduced new API methods to retrieve uploaded document/image assets for specific verification attempts in the ID document and address document verification clients, supporting optional pagination. [1] [2]

Applicant Data Model Improvements:

• Added new entity classes: PhoneNumber, IdvAddress, IdentityDeclaredData, and IdentityVerificationClientInformation to capture richer applicant details, including phone, email, address, document issuing country, and document type. [1] [2] [3] [4]
• Updated request objects for verification attempts to support the new applicant data fields and types, and improved property annotations for clarity and validation. [1] [2] [3]

Type and Documentation Improvements:

• Improved type annotations and documentation for fields in ClientInformation, DeclaredData, and related request/response objects, specifying formats, examples, and optionality for better developer experience and validation. [1] [2]

Dependency and Import Updates:

• Added necessary imports for new classes in client and request files to support the new features and types. [1] [2] [3] [4]

These updates make the API more flexible, extensible, and user-friendly, especially for clients needing to paginate results or capture additional applicant information.

⚠️ Breaking changes

Kind	Change
removed	$activation_date -> $scheduled_activation_date on CardRequest and UpdateCardRequest

Note: nothing else is breaking. The new getXAttempts($id, ?AttemptsQueryFilter $query = null) and updateCardDetails($cardId, $request, ?CardUpdateHeaders $headers = null) parameters default to null, and ApiClient::query() was widened to accept a nullable filter. Properties are untyped, so the IdentityDeclaredData and IdentityVerificationClientInformation subclasses are a docblock change only.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:472>250

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 32

---

_{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 — 472>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: Looks good to me

This PR still needs a human approval — wall-e cannot auto-approve it. For what it's worth, I read the diff and found nothing I'd block on.

Adds pagination support to the list-attempts methods across all four identity/face-auth clients, introduces new attempt-assets endpoints, adds richer applicant data model classes, renames activation_date to scheduled_activation_date on card requests, and adds a CardUpdateHeaders helper. The implementation is consistent, backward-compatible (new params are optional with defaults), and well-tested including a wire-level test against real Guzzle.

What I checked

• The activation_date → scheduled_activation_date rename in both CardRequest and UpdateCardRequest is a breaking change for any caller currently using the old field name — existing serialized requests or code using $request->activation_date will silently send nothing to the API. This is the most operationally significant item but may be intentional to track the upstream API rename.
• The ApiClient::query() null-guard change is correct: when $requestBody is null it now falls through to a plain GET, which matches the stated intent and is backward-compatible for all existing callers of query() with a non-null filter.
• The CardUpdateHeaders::getHeaderMappings() method is defined but the diff does not show IssuingClient::updateCardDetails (or ApiClient::patch) consuming it — if the patch path doesn't read getHeaderMappings() the header values would not be sent with the correct HTTP header names. The diff is truncated so this may be handled elsewhere, but is worth confirming.
• IdentityVerificationRequest::$declared_data and IdentityVerificationAndOpenRequest::$declared_data are switched from DeclaredData to IdentityDeclaredData; since PHP doesn't enforce property types at runtime this won't break existing code that passes a plain DeclaredData, but callers expecting the new subclass fields would get nothing — acceptable given it's a documentation/type annotation only.
• All four list-attempts tests that previously mocked get() are correctly updated to mock query(), and the new AttemptsPaginationWireTest exercises the actual URI construction through a real ApiClient with a stubbed Guzzle handler, giving solid coverage of the core feature.
• Integration tests for the new pagination and assets endpoints are correctly marked markTestSkipped, so they won't fail CI without a live environment.

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

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 33

---

_{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 — 522>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
13 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