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 pagination and asset retrieval in various identity verification APIs, and improves card update functionality with optional encrypted credential headers. The most significant changes are the introduction of paginated query parameters for listing attempts, new endpoints for retrieving attempt assets, and the ability to request encrypted card credentials via custom headers.

Identity Verification APIs

• Added optional pagination parameters (skip, limit) to all listAttempts methods for identity, ID document, address document, and face authentication verifications, and updated the Identities wrapper to support these parameters. [1] [2] [3] [4] [5] [6] [7] [8]
• Introduced new methods getAttemptAssets for ID document and address document verifications, allowing retrieval of uploaded document images for a specific attempt, with pagination support. These are also exposed in the Identities wrapper. [1] [2] [3] [4]
• Refactored query parameter handling by introducing a buildQueryParams utility to properly append query strings only when needed, avoiding unnecessary trailing question marks.

Issuing/Card APIs

• Enhanced the updateCard method to accept optional HTTP headers, enabling clients to request encrypted CVV values by setting return-encrypted-cvv and Encryption-Key headers. Updated documentation accordingly and propagated the change to the Issuing wrapper. [1] [2]

Other Improvements

• Changed the return value of getPDFReport in identity verifications to return a JSON object with a pre-signed PDF URL, instead of a raw CSV buffer, aligning with the updated API response.

⚠️ Breaking changes

Kind	Change
return type	identityVerifications.getPDFReport and identities.getIdentityVerificationPDFReport now resolve to the parsed JSON body carrying pdf_report, instead of a Buffer. The method previously requested text/csv and Buffer-wrapped a response the API sends as application/json, so pdf_report was unreachable
types	Promise -> Promise on the three getPDFReport declarations and the three aggregate delegates. For the address document and ID document variants the implementation always returned JSON, so those two are declaration corrections with no runtime change

Note: nothing else is breaking. The new params and headers arguments are trailing and optional in both the JavaScript and the type declarations.

[agent-wall-e]

🟡 Risk Classification: MINOR

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

Classification reasons

• exceeds_bounded_scope:279>250

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 19

---

_{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 — 279>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.

What I checked

• The diff matches the stated intent: pagination params added to all listAttempts methods, new getAttemptAssets endpoints for ID and address document verifications, buildQueryParams improved to avoid bare trailing '?', updateCard extended with optional headers, and getPDFReport changed from csv buffer to JSON response.
• buildQueryParams correctly skips appending '?' when params is undefined or when all values produce an empty query string; skip=0 (falsy but valid) is preserved because encodeURIComponent(0) produces '0', not an empty string.
• The updateCard headers approach (spreading onto a config copy rather than the body) correctly avoids leaking header fields into the JSON body, and the unit test explicitly asserts this.
• The getPDFReport change (removing csv:true and returning response.json) is a breaking change for existing callers relying on a Buffer return value, but the old behaviour was documented as incorrect, and the unit tests have been updated consistently.
• New getAttemptAssets methods in address-document-verifications.js and id-document-verifications.js follow the same pattern as the pre-existing face-authentications.js and identity-verifications.js implementations — structurally consistent.
• All new integration test files are marked describe.skip, so they will not run in CI without opt-in, which is the correct pattern for tests requiring live credentials.
• Unit tests cover: skip/limit forwarding, no-params (no trailing '?'), empty asset pages, header isolation from body, and delegation through the Identities wrapper — coverage is thorough for the changed surface area.

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

Operational gates

• ✅ jira_ticket (INT-1695)
• ✅ independent_review

Files analysed: 27

---

_{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 — 366>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
1 New issue
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