chore: update generated files from PR #11520#46
Conversation
There was a problem hiding this comment.
The generated type updates are generally coherent: loyalty_pass_install is threaded through configuration, customer availability, and history unions, and tightening language from unknown to string removes unnecessary consumer-side narrowing. The one elegance issue I found is at the package boundary: the branch exposes the new enroll endpoint in the OpenAPI types, but the hand-written client wrapper does not expose a matching customer method, so users of the primary createHeadlessApiClient() API still have to drop down to manual fetch/openapi-fetch for this one newly added workflow.
| "/headless/2025-06/{site_id}/customers/{merchant_id}/enroll": { | ||
| parameters: { | ||
| query?: never; | ||
| header?: never; | ||
| path?: never; | ||
| cookie?: never; | ||
| }; | ||
| get?: never; | ||
| put?: never; | ||
| post: operations["customers.enroll"]; |
There was a problem hiding this comment.
This adds a first-class customers.enroll operation to the typed API surface, but createHeadlessApiClient() still only exposes getCustomer, initializeSession, setBirthday, and subscribeToEmailMarketing under customers. Since this package’s main ergonomic surface is the wrapper client, adding the route here without the matching customers.enroll({ id }) helper leaves the new workflow discoverable in the raw types but not usable through the public client API, unlike the other customer endpoints around it.
Auto-generated by the CI pipeline.
Source: https://github.com/loyaltylion/hogwarts/pull/11520
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