userinfo: HTTP 200 sparse address rejected by SDK validator (CLI 0.27.0)

Start with packages/sdk/src/resources/user-info.ts, especially the userInfoSchema declaration and retrieve() parsing path cited in the report. Compare the schema with the documented API address contract and inspect or add offline fixtures for sparse, absent, null, complete, and invalid address values. Done means the API and SDK behavior agree and the regression cases pass; the issue leaves which side should change unresolved.

Summary

With @stripe/[email protected], an approved userinfo:read device-flow session received HTTP 200 from GET https://api.link.com/userinfo, but user-info retrieve exited 1 because the response address omitted required SDK fields.

Among the SDK's named address fields, country was a string while line1, city, state, and postal_code were absent. Only field presence and types were retained; unknown fields were not retained. The actual response body and all account values are omitted from this report.

Environment and invocation

• Official npm package @stripe/[email protected]; unchanged bundled dist/cli.js, invoked directly with Node.
• macOS; Node.js 24.20.0.
• Device login completed with the granted scope verified as exactly userinfo:read; no extra authorization details.
• A separate auth file was selected with documented --auth. LINK_NO_REFRESH=1 was set, and no token refresh occurred.

Equivalent CLI arguments are below. $AUTH_FILE represents the same private absolute auth-file path in both commands; the display label is replaced with a generic example. These are documentation of the completed flow, not a request for credentials:

LINK_NO_REFRESH=1 link-cli --auth "$AUTH_FILE" auth login \
  --client-name "Example agent" --scope userinfo:read
# Owner completes the device authorization and the CLI obtains the grant.
LINK_NO_REFRESH=1 link-cli --auth "$AUTH_FILE" --format json --full-output \
  user-info retrieve

For the diagnostic read, a local guard permitted one GET to the official userinfo endpoint and prevented other network requests. It added redirect: 'error', inspected a bounded clone for field names/types, and returned the original Response unchanged. An offline mock test confirms response identity, body bytes, method, and headers are preserved. No redirect or blocked extra request occurred in the observed HTTP 200 read. The vendor schema failure also reproduces offline without that guard, authentication, or network.

Actual result

HTTP 200
CLI exit code 1
UNKNOWN
Invalid response while attempting to retrieve user info (200)

Retained validation details identify address.city, address.state, and address.postal_code as expected string / received undefined. The diagnostic's initial path filter did not retain digit-containing line1; its absence was recorded by the field-shape check and independently confirmed as a fourth validation failure by the offline fixture below.

Synthetic offline reproduction

The following is a minimal synthetic fixture, not the actual account response:

{"address":{"country":"ZZ"}}

Evaluating the exact userInfoSchema declarations extracted from the unchanged published CLI bundle rejects it with four missing-field paths:

address.city
address.line1
address.postal_code
address.state

Five offline fixture cases were checked: country-only fails at those four paths; omitted whole address passes; null whole address passes; required components explicitly null with a string country passes; adding optional line2: null to the sparse object still fails.

Documentation/source check and expected behavior

The CLI README's login/user-info flow does not state that a complete profile address, payment method, guided onboarding, or purchase is required before retrieving user info. It describes omitted/null address enrichment. userinfo:read is the documented identity scope.

The released validator requires line1, city, state, postal_code, and country as nullable strings; only line2 is optional. The checked current validator has identical bytes. retrieve() parses successful JSON through this schema.

Please clarify and align the API/SDK address contract. If omitted components are supported, the SDK should preserve omissions while validating present values. If all components are required, the successful API response should supply the required nullable fields. The reviewed public documentation does not explicitly guarantee a country-only address, so this report identifies an observed response/validator mismatch rather than assuming which side must change.

Suggested regression fixtures: sparse/country-only, whole address absent, whole address null, complete address, and invalid present component types.

No account identifiers, profile values, tokens, authorization codes, local private paths, or raw account responses are included. No payment or account-profile modification was attempted. Issue #406 concerns refresh HTTP 400 and is a different failure.