feat(customers): accept typed agreement consents for seven documents

.stainless/stainless.yml

@@ -113,9 +113,13 @@ resources:
       business_customer_create_request: '#/components/schemas/BusinessCustomerCreateRequest'
       individual_customer_update_request: '#/components/schemas/IndividualCustomerUpdateRequest'
       business_customer_update_request: '#/components/schemas/BusinessCustomerUpdateRequest'
+      agreement_type: '#/components/schemas/AgreementType'
+      agreement_acceptance_method: '#/components/schemas/AgreementAcceptanceMethod'
       end_user_terms: '#/components/schemas/EndUserTerms'
-      end_user_terms_consent: '#/components/schemas/EndUserTermsConsent'
-      end_user_terms_consent_request: '#/components/schemas/EndUserTermsConsentRequest'
+      agreement_document: '#/components/schemas/AgreementDocument'
+      agreement_document_list_response: '#/components/schemas/AgreementDocumentListResponse'
+      agreement_consent: '#/components/schemas/AgreementConsent'
+      agreement_consent_request: '#/components/schemas/AgreementConsentRequest'
       # Internal-account management (list/update/export under this resource)
       internal_account_list_response: '#/components/schemas/InternalAccountListResponse'
       internal_account_update_request: '#/components/schemas/InternalAccountUpdateRequest'
@@ -142,6 +146,7 @@ resources:
       create_kyc_link:
         endpoint: post /customers/{customerId}/kyc-link
         body_param_name: KycLinkCreateRequest
+      list_agreements: get /customers/agreements
       retrieve_end_user_terms: get /customers/end-user-terms
     # Subresources define resources that are nested within another for more powerful
     # logical groupings, e.g. `cards.payments`.

mintlify/changelog.mdx

@@ -48,6 +48,31 @@ Three card-statement corrections to `CardTransaction`:
 - `GET /transactions` accepts a `cardId` filter (`Card:` LSID or UUID) for listing one
   card of a multi-card cardholder, and rejects `status` combined with `type=CARD` with a
   400—`status` applies to payment transactions only.
+## Record consent for each agreement by type
+
+`agreementConsents` supersedes `endUserTermsConsent`: a list with one entry per agreement,
+so a customer's acceptance of each document is recorded and auditable separately.
+
+- Each entry carries a `type` alongside the existing `acceptedAt`, `ipAddress`,
+  `termsVersion`, and `acceptanceMethod` fields. Send at most one entry per type.
+- `GET /customers/agreements` lists every supported agreement with its `type`, current
+  `version`, and hosted `url`. Send an entry's `version` as `termsVersion` when recording
+  that agreement's acceptance. `GET /customers/end-user-terms` is deprecated but unchanged
+  — it still returns the single `{ version, url }` object, so existing callers keep working.
+- Customer responses return `agreementConsents`, holding the most recent acceptance per
+  accepted type, and an empty list until the first acceptance.
+- On update, supplying consents records additional acceptances; acceptances already on
+  file for other types are left untouched.
+
+`endUserTermsConsent` is **deprecated, not removed** — it still works on both the request
+and response, and is equivalent to a single `LIGHTSPARK_END_USER_TERMS` entry. Acceptance
+you have already recorded is migrated for you and reported under that type; you don't need
+to re-collect it. Sending both fields in one request is rejected.
+
+Accepting one agreement never implies acceptance of another, so the remaining six types
+must be collected from each customer.
+
+See [Disclosures](/payouts-and-b2b/onboarding/disclosures).
 
 ## Card returns report as `SETTLED` with a `refundedAmount`