chore: update generated files from PR #11738#51
Conversation
There was a problem hiding this comment.
The generated type updates are mostly coherent: the new loyalty_pass_install rule is threaded through the configuration, customer, and history unions in both generated type surfaces; custom reward voucher fulfillment is represented with a useful discriminator; and the language fields are tightened from unknown to string.
The main elegance concern is the boundary between generated API coverage and the package's ergonomic client. This PR adds the enroll operation to the generated paths/operations, but the public createHeadlessApiClient() wrapper still exposes helpers for every other customer operation and not this one. If this branch is intentionally types-only, that is a reasonable release choice; if the new endpoint is meant to be first-class in the package API, the wrapper should move with the generated surface.
| @@ -63,6 +63,22 @@ export interface paths { | |||
| patch?: never; | |||
| trace?: never; | |||
| }; | |||
| "/headless/2025-06/{site_id}/customers/{merchant_id}/enroll": { | |||
There was a problem hiding this comment.
This adds POST /customers/{merchant_id}/enroll to the generated API surface, but the hand-written createHeadlessApiClient().customers wrapper was not updated with a matching enroll helper. Every other customer path in this block has a corresponding convenience method, so consumers using the package's primary client API cannot reach the new operation without dropping down to their own request/openapi client. If the endpoint is intended to ship as part of this client release, add the wrapper method alongside the generated types.
Auto-generated by the CI pipeline.
Source: https://github.com/loyaltylion/hogwarts/pull/11738
These files were regenerated from changes to the API contracts. Review and merge alongside the main PR.
Generated files:
src/types/api.tssrc/types/schemas.ts