chore: update generated files from PR #11571#49
Conversation
![loyaltylion-minerva[bot]](https://avatars.githubusercontent.com/in/3258495?s=60&v=4){kind=small}
There was a problem hiding this comment.
The generated type updates are mostly coherent: the new loyalty-pass rule is threaded through both configuration and customer-available rule unions, and the custom voucher reward shape is reflected in configuration, available rewards, claimed rewards, and redeem responses. The main elegance gap is that the branch widens the typed OpenAPI surface but does not widen the package's ergonomic client surface to match, so consumers using createHeadlessApiClient cannot actually exercise the new customer session-token/enrollment flows without dropping beneath the public helper.
I could not read .claude/skills/core-elegance-review/SKILL.md because it is not present in this checkout, so I applied the requested static full-diff pass and second pass directly.
| @@ -63,6 +79,22 @@ export interface paths { | |||
| patch?: never; | |||
| trace?: never; | |||
| }; | |||
| "/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.
These new customer operations are present in the generated paths, but createHeadlessApiClient().customers still only exposes getCustomer, initializeSession, setBirthday, and subscribeToEmailMarketing. That leaves the package's primary client API unable to call enroll or createSessionToken even though the types now advertise them. Since the existing customer endpoints are mirrored in src/client.ts, this should add matching helper methods as part of the same API update.
| /** @description When `true`, the response will include a `session_token`: a short-lived token scoped to this customer, which can be handed to a browser or app to call supported headless API endpoints directly on behalf of the customer */ | ||
| include_session_token?: boolean; |
There was a problem hiding this comment.
The new include_session_token query option is not reachable through createHeadlessApiClient().customers.initializeSession: that helper accepts only cart, session, and customer, and it never sends params.query. As written, callers using the high-level client can see session_token?: SessionTokenStruct in the response type but have no way to request it through the intended helper path.
There was a problem hiding this comment.
Previous feedback about the high-level client surface remains unresolved, so I left those threads open and did not repeat them below. The new scope additions mostly fit the session-token model, but they add one new contract mismatch around the documented insufficient_scope error shape.
| * @description The scopes this session token holds, which bound the endpoints it can call. Requests to an endpoint requiring a scope the token does not hold fail with a 403 `insufficient_scope` error code | ||
| * @example [ | ||
| * "read", | ||
| * "profile", | ||
| * "redeem", | ||
| * "rules" | ||
| * ] | ||
| */ | ||
| scopes: ("read" | "profile" | "redeem" | "rules")[]; |
There was a problem hiding this comment.
This now documents insufficient_scope as a 403 error code, but the generated operation types still model every 403 response as { error: { message: string; details?: ... } } with no code field. That leaves callers unable to type-narrow the exact error the token contract tells them to handle. The scope change should also update the relevant 403 response schema(s) to include code: "insufficient_scope" wherever session tokens can hit scope-gated endpoints.
1 participant
Auto-generated by the CI pipeline.
Source: https://github.com/loyaltylion/hogwarts/pull/11571
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