sinfactura-types 1.10.658 → 1.10.660

package/dist/auth.d.ts

@@ -894,8 +894,8 @@ declare global {
      *   never arrive: a code `social-bridge-mint` issued with `purpose: 'link'` on
      *   the store's slug host, and the SAME `state` that mint was sent. Single
      *   use, 60 s, redeemable only from its `returnOrigin` at its own store and
-     *   for the session's store; any failure, a missing or different `state`
-     *   included, is `401 BRIDGE_CODE_INVALID` (see
+     *   for the session's store; any failure, a missing or different `state` or a
+     *   `sign-in` or `register` code included, is `401 BRIDGE_CODE_INVALID` (see
      *   {@link SOCIAL_BRIDGE_ERROR_CODES}) and spends the code.
      */
     type CustomerLinkSignInMethodRequest = {
@@ -909,12 +909,70 @@ declare global {
         state: string;
         accessToken?: never;
     });
+    /**
+     * `POST /auth { mode: 'register-social' }` on the STOREFRONT host — create a
+     * CUSTOMER from a verified social identity instead of an email and password.
+     * Field for field what the `register-social` schema accepts as INPUT, beside
+     * `mode`, exactly as {@link CustomerRegisterInput} is for `mode: 'register'`.
+     * The tie is compile-time: `AssertCustomerSocialRegisterInputMatchesSchema`,
+     * declared beside that schema (`stacks/web/lambdas/auth/registerSocial.ts`).
+     *
+     * The profile is {@link CustomerRegisterInput} without `email` and `password`
+     * — derived from it, so the two legs cannot drift: `fullName`, `cuit` and
+     * `phone` are REQUIRED with the same bounds, and the optional address and
+     * `afip` fields are identical.
+     *
+     * The identity arrives as EXACTLY ONE of the two — both, or neither, is the
+     * ordinary `400` validation refusal, as on {@link CustomerLinkSignInMethodRequest}:
+     * - `accessToken` — a Firebase ID token, exactly as {@link Social.accessToken},
+     *   on an origin Firebase authorises (the platform slug host).
+     * - `bridgeCode` + `state` — on a CUSTOM domain: a code `social-bridge-mint`
+     *   issued with `purpose: 'register'` on the store's slug host, and the SAME
+     *   `state` that mint was sent. A `sign-in` or `link` code, or any other
+     *   bridge failure, is `401 BRIDGE_CODE_INVALID` (see
+     *   {@link SOCIAL_BRIDGE_ERROR_CODES}) and spends the code — but a
+     *   `bridgeCode` without `state` is the `400` validation refusal, unspent.
+     *
+     * ⚠️ There is NO `email` here, deliberately. The account's email is ALWAYS the
+     * verified token's — an `email` in the body is stripped, never compared and
+     * never stored. For an Apple private-relay identity that is the relay address.
+     * An identity whose provider has not verified its email, or that carries none,
+     * is `401 SIGN_IN_IDENTITY_UNVERIFIED` and creates nothing.
+     *
+     * ⚠️ There is NO `password` either: the account is created without one and
+     * with `emailVerified: true`, its first linked sign-in method being the
+     * token's provider. The way back in is `mode: 'social'` with the same
+     * provider.
+     *
+     * No captcha, like `mode: 'social'`. A closed shop or a foreign Origin is
+     * refused exactly as `mode: 'register'` refuses it — on the bridge leg,
+     * against the store the code was minted for. Every other refusal is in
+     * {@link CUSTOMER_SOCIAL_REGISTER_ERROR_CODES}. The 200 is a
+     * {@link CustomerRegisterResult}, the same body `mode: 'register'` answers.
+     */
+    type CustomerSocialRegisterInput = Omit<CustomerRegisterInput, 'email' | 'password'> & ({
+        accessToken: string;
+        bridgeCode?: never;
+        state?: never;
+    } | {
+        bridgeCode: string;
+        state: string;
+        accessToken?: never;
+    });
     /**
      * What a social-bridge code is FOR. A `sign-in` code redeems only through
      * `social-bridge-redeem`; a `link` code only through `link-sign-in-method`'s
-     * `bridgeCode`. The wrong one is `401 BRIDGE_CODE_INVALID`, and spent.
+     * `bridgeCode`; a `register` code only through `register-social`'s
+     * `bridgeCode` (see {@link CustomerSocialRegisterInput}). The wrong one is
+     * `401 BRIDGE_CODE_INVALID`, and spent — so `social-bridge-redeem` and
+     * `link-sign-in-method` refuse a `register` code exactly as `register-social`
+     * refuses a `sign-in` or `link` one.
+     *
+     * ⚠️ `register` was added after the other two. A consumer that narrows an
+     * incoming value to this union must widen its own guard, or it drops a valid
+     * `register` flow as unknown.
      */
-    type CustomerSocialBridgePurpose = 'sign-in' | 'link';
+    type CustomerSocialBridgePurpose = 'sign-in' | 'link' | 'register';
     /**
      * `POST /auth` body for `social-bridge-mint`. Public, captcha-exempt like
      * `mode: 'social'`.
@@ -927,14 +985,20 @@ declare global {
      * and requires `returnOrigin` to be exactly `https://` + the store's ACTIVE
      * canonical custom host, or its `www.` — anything else is
      * `400 BRIDGE_ORIGIN_NOT_ALLOWED`. An expired or malformed token is
-     * `401 INVALID_ID_TOKEN`; an unverified identity is `400 USER_NOT_ENABLED`, as
-     * on `mode: 'social'`.
+     * `401 INVALID_ID_TOKEN`; an unverified identity is
+     * `401 SIGN_IN_IDENTITY_UNVERIFIED`, as on `mode: 'social'`.
      */
     interface CustomerSocialBridgeMintRequest {
         mode: 'social-bridge-mint';
         idToken: string;
         /** A bare origin, as `location.origin` prints it: no path, no trailing slash, no port (not even `:443`). */
         returnOrigin: string;
+        /**
+         * Which mode may redeem the code — see {@link CustomerSocialBridgePurpose}.
+         * Mint `register` for a custom-domain `register-social`: the token's
+         * identity is verified here exactly as for the other two purposes, and the
+         * customer is only created when the custom domain redeems the code.
+         */
         purpose: CustomerSocialBridgePurpose;
         /**
          * The custom-domain page's own random nonce for this flow, 16–128 of
@@ -960,8 +1024,8 @@ declare global {
      * body, refresh cookie and session `mode: 'social'` answers with, and every
      * other refusal of that mode (`CUSTOMER_NOT_FOUND`, `SIGN_IN_UID_MISMATCH`, …)
      * can follow a valid code. A malformed, unknown, used or expired code, another
-     * Origin, another store, a `link` code, or a missing or different `state` is
-     * `401 BRIDGE_CODE_INVALID` — and the code is spent either way.
+     * Origin, another store, a `link` or `register` code, or a missing or different
+     * `state` is `401 BRIDGE_CODE_INVALID` — and the code is spent either way.
      */
     interface CustomerSocialBridgeRedeemRequest {
         mode: 'social-bridge-redeem';
@@ -1330,12 +1394,15 @@ declare global {
  *   UID than this verified token carries. Closes the gap where a matching email
  *   address was enough. A security event, not a bad password.
  * - `SIGN_IN_IDENTITY_MISMATCH` (link) — the minted token's identity is not the
- *   account being linked to. ⚠️ Distinguishable here and deliberately NOT on the
+ *   account being linked to — including an Apple private relay that another
+ *   customer of the store holds as its email, which sign-in would resolve to
+ *   that customer and never to this one. ⚠️ Distinguishable here and deliberately NOT on the
  *   unauthenticated sign-in path: the linking caller is cookie-authenticated and
  *   already holds both operands, so naming the mismatch discloses nothing it did
  *   not supply. Naming it on sign-in would enumerate the customer table.
- * - `SIGN_IN_IDENTITY_UNVERIFIED` (link) — the provider asserts an identity it
- *   has not itself verified.
+ * - `SIGN_IN_IDENTITY_UNVERIFIED` (link, `social`, `social-bridge-mint`,
+ *   `register-social`) — the provider asserts an identity it has not itself
+ *   verified. Never the disabled-account answer: that stays `USER_NOT_ENABLED`.
  * - `INVALID_ID_TOKEN` — the token failed verification outright: malformed,
  *   expired, or signed by the wrong issuer. Retryable by re-authenticating.
  * - `SIGN_IN_PROVIDER_UNSUPPORTED` — the provider is not one this store accepts.
@@ -1370,22 +1437,69 @@ export declare const SIGN_IN_METHOD_ERROR_CODES: readonly ["SIGN_IN_METHOD_LAST_
 export type SignInMethodErrorCode = (typeof SIGN_IN_METHOD_ERROR_CODES)[number];
 /**
  * Refusals of the custom-domain social bridge — `social-bridge-mint`,
- * `social-bridge-redeem` and `link-sign-in-method`'s `bridgeCode`.
+ * `social-bridge-redeem`, and the `bridgeCode` of `link-sign-in-method` and
+ * `register-social`.
  *
  * - `BRIDGE_ORIGIN_NOT_ALLOWED` · 400 (mint) — the request's Origin is not the
  *   store's own ACTIVE slug host (or `x-store` is malformed), or `returnOrigin`
  *   is not exactly `https://` + the store's ACTIVE canonical custom host or its
  *   `www.`: a pending, failed or spare domain, another store's domain, `http:`,
  *   a path, any explicit port or a trailing slash.
- * - `BRIDGE_CODE_INVALID` · 401 (redeem, link) — ONE code for every failure:
- *   malformed, unknown, already used, older than 60 s, presented from another
- *   Origin or at another store, minted for the other purpose, or sent without
+ * - `BRIDGE_CODE_INVALID` · 401 (redeem, link, register-social) — ONE code for
+ *   every failure: malformed, unknown, already used, older than 60 s, presented
+ *   from another Origin or at another store, minted for a different
+ *   {@link CustomerSocialBridgePurpose} than the redeeming mode's, or sent without
  *   the `state` it was minted for. Deliberately
  *   undifferentiated, so it is no oracle. Not retryable with the same code: it
  *   is spent by the attempt. Start the bridge again.
+ *   ⚠️ Except a `register-social` `bridgeCode` sent WITHOUT `state`: that mode's
+ *   schema requires `state`, so it is `400 VALIDATION_FAILED` before any redeem,
+ *   and the code is NOT spent — where `social-bridge-redeem` and
+ *   `link-sign-in-method` answer this `401` and spend it.
  */
 export declare const SOCIAL_BRIDGE_ERROR_CODES: readonly ["BRIDGE_ORIGIN_NOT_ALLOWED", "BRIDGE_CODE_INVALID"];
 export type SocialBridgeErrorCode = (typeof SOCIAL_BRIDGE_ERROR_CODES)[number];
+/**
+ * `body.error` codes `POST /auth { mode: 'register-social' }` can refuse with —
+ * see {@link CustomerSocialRegisterInput}. Nothing is written on any of them.
+ *
+ * A CONST TUPLE, module-scope, for the same reason as the sign-in cohort above:
+ * a consumer keys an exhaustive `Record<CustomerSocialRegisterErrorCode, string>`
+ * of copy off it, and the compiler re-checks that record when a member is added.
+ *
+ * The status is stated per member, but ⚠️ MATCH ON `body.error`, never on the
+ * status alone — the two 401s want different remedies.
+ *
+ * - `EMAIL_TAKEN_BY_ANOTHER_ACCOUNT` · 400 — a customer of this store already
+ *   holds the token's email, or (Apple) already has this private-relay identity
+ *   linked. Route to `mode: 'social'` sign-in, never to registering again. The
+ *   same answer `mode: 'register'` gives for a taken email, or for a typed
+ *   private-relay address already linked to a customer.
+ * - `CUSTOMER_ID_ALLOCATION_EXHAUSTED` · 409 — the store's customer-id space
+ *   could not yield a free id. Nothing the shopper sent is wrong; retryable
+ *   later. Shared with `mode: 'register'`.
+ * - `SIGN_IN_IDENTITY_UNVERIFIED` · 401 — the provider has not verified the
+ *   token's email, or the token carries none. Not retryable with this identity.
+ * - `INVALID_ID_TOKEN` · 401 — the token failed verification outright:
+ *   malformed, expired or wrongly issued. Retryable by re-authenticating with
+ *   the provider.
+ * - `SIGN_IN_PROVIDER_UNSUPPORTED` · 400 — a verified token from a provider
+ *   other than Google, Apple or Facebook. A configuration answer, not a
+ *   credential one.
+ *
+ * ⚠️ The last three are ALSO members of {@link SIGN_IN_METHOD_ERROR_CODES},
+ * deliberately: the same verification failure reads the same on every mode that
+ * verifies a token, so one copy entry can serve both.
+ *
+ * ⚠️ Not listed, because they are not this mode's own: a closed shop or a
+ * foreign Origin answers `403 STOREFRONT_UNAVAILABLE` / `403
+ * ORIGIN_STORE_MISMATCH` exactly as `mode: 'register'` does, and the
+ * `bridgeCode` leg's `401 BRIDGE_CODE_INVALID` lives in
+ * {@link SOCIAL_BRIDGE_ERROR_CODES}. An invalid `cuit` or `phone`, or a body
+ * with both or neither identity, is the ordinary `400` validation refusal.
+ */
+export declare const CUSTOMER_SOCIAL_REGISTER_ERROR_CODES: readonly ["EMAIL_TAKEN_BY_ANOTHER_ACCOUNT", "CUSTOMER_ID_ALLOCATION_EXHAUSTED", "SIGN_IN_IDENTITY_UNVERIFIED", "INVALID_ID_TOKEN", "SIGN_IN_PROVIDER_UNSUPPORTED"];
+export type CustomerSocialRegisterErrorCode = (typeof CUSTOMER_SOCIAL_REGISTER_ERROR_CODES)[number];
 /**
  * `body.error` codes the operator refresh/session leg can refuse with —
  * `POST /auth { mode: 'refresh' }` and the body-transport ingress it shares with

package/dist/auth.js

@@ -40,12 +40,15 @@
  *   UID than this verified token carries. Closes the gap where a matching email
  *   address was enough. A security event, not a bad password.
  * - `SIGN_IN_IDENTITY_MISMATCH` (link) — the minted token's identity is not the
- *   account being linked to. ⚠️ Distinguishable here and deliberately NOT on the
+ *   account being linked to — including an Apple private relay that another
+ *   customer of the store holds as its email, which sign-in would resolve to
+ *   that customer and never to this one. ⚠️ Distinguishable here and deliberately NOT on the
  *   unauthenticated sign-in path: the linking caller is cookie-authenticated and
  *   already holds both operands, so naming the mismatch discloses nothing it did
  *   not supply. Naming it on sign-in would enumerate the customer table.
- * - `SIGN_IN_IDENTITY_UNVERIFIED` (link) — the provider asserts an identity it
- *   has not itself verified.
+ * - `SIGN_IN_IDENTITY_UNVERIFIED` (link, `social`, `social-bridge-mint`,
+ *   `register-social`) — the provider asserts an identity it has not itself
+ *   verified. Never the disabled-account answer: that stays `USER_NOT_ENABLED`.
  * - `INVALID_ID_TOKEN` — the token failed verification outright: malformed,
  *   expired, or signed by the wrong issuer. Retryable by re-authenticating.
  * - `SIGN_IN_PROVIDER_UNSUPPORTED` — the provider is not one this store accepts.
@@ -91,21 +94,73 @@ export const SIGN_IN_METHOD_ERROR_CODES = [
 ];
 /**
  * Refusals of the custom-domain social bridge — `social-bridge-mint`,
- * `social-bridge-redeem` and `link-sign-in-method`'s `bridgeCode`.
+ * `social-bridge-redeem`, and the `bridgeCode` of `link-sign-in-method` and
+ * `register-social`.
  *
  * - `BRIDGE_ORIGIN_NOT_ALLOWED` · 400 (mint) — the request's Origin is not the
  *   store's own ACTIVE slug host (or `x-store` is malformed), or `returnOrigin`
  *   is not exactly `https://` + the store's ACTIVE canonical custom host or its
  *   `www.`: a pending, failed or spare domain, another store's domain, `http:`,
  *   a path, any explicit port or a trailing slash.
- * - `BRIDGE_CODE_INVALID` · 401 (redeem, link) — ONE code for every failure:
- *   malformed, unknown, already used, older than 60 s, presented from another
- *   Origin or at another store, minted for the other purpose, or sent without
+ * - `BRIDGE_CODE_INVALID` · 401 (redeem, link, register-social) — ONE code for
+ *   every failure: malformed, unknown, already used, older than 60 s, presented
+ *   from another Origin or at another store, minted for a different
+ *   {@link CustomerSocialBridgePurpose} than the redeeming mode's, or sent without
  *   the `state` it was minted for. Deliberately
  *   undifferentiated, so it is no oracle. Not retryable with the same code: it
  *   is spent by the attempt. Start the bridge again.
+ *   ⚠️ Except a `register-social` `bridgeCode` sent WITHOUT `state`: that mode's
+ *   schema requires `state`, so it is `400 VALIDATION_FAILED` before any redeem,
+ *   and the code is NOT spent — where `social-bridge-redeem` and
+ *   `link-sign-in-method` answer this `401` and spend it.
  */
 export const SOCIAL_BRIDGE_ERROR_CODES = ['BRIDGE_ORIGIN_NOT_ALLOWED', 'BRIDGE_CODE_INVALID'];
+/**
+ * `body.error` codes `POST /auth { mode: 'register-social' }` can refuse with —
+ * see {@link CustomerSocialRegisterInput}. Nothing is written on any of them.
+ *
+ * A CONST TUPLE, module-scope, for the same reason as the sign-in cohort above:
+ * a consumer keys an exhaustive `Record<CustomerSocialRegisterErrorCode, string>`
+ * of copy off it, and the compiler re-checks that record when a member is added.
+ *
+ * The status is stated per member, but ⚠️ MATCH ON `body.error`, never on the
+ * status alone — the two 401s want different remedies.
+ *
+ * - `EMAIL_TAKEN_BY_ANOTHER_ACCOUNT` · 400 — a customer of this store already
+ *   holds the token's email, or (Apple) already has this private-relay identity
+ *   linked. Route to `mode: 'social'` sign-in, never to registering again. The
+ *   same answer `mode: 'register'` gives for a taken email, or for a typed
+ *   private-relay address already linked to a customer.
+ * - `CUSTOMER_ID_ALLOCATION_EXHAUSTED` · 409 — the store's customer-id space
+ *   could not yield a free id. Nothing the shopper sent is wrong; retryable
+ *   later. Shared with `mode: 'register'`.
+ * - `SIGN_IN_IDENTITY_UNVERIFIED` · 401 — the provider has not verified the
+ *   token's email, or the token carries none. Not retryable with this identity.
+ * - `INVALID_ID_TOKEN` · 401 — the token failed verification outright:
+ *   malformed, expired or wrongly issued. Retryable by re-authenticating with
+ *   the provider.
+ * - `SIGN_IN_PROVIDER_UNSUPPORTED` · 400 — a verified token from a provider
+ *   other than Google, Apple or Facebook. A configuration answer, not a
+ *   credential one.
+ *
+ * ⚠️ The last three are ALSO members of {@link SIGN_IN_METHOD_ERROR_CODES},
+ * deliberately: the same verification failure reads the same on every mode that
+ * verifies a token, so one copy entry can serve both.
+ *
+ * ⚠️ Not listed, because they are not this mode's own: a closed shop or a
+ * foreign Origin answers `403 STOREFRONT_UNAVAILABLE` / `403
+ * ORIGIN_STORE_MISMATCH` exactly as `mode: 'register'` does, and the
+ * `bridgeCode` leg's `401 BRIDGE_CODE_INVALID` lives in
+ * {@link SOCIAL_BRIDGE_ERROR_CODES}. An invalid `cuit` or `phone`, or a body
+ * with both or neither identity, is the ordinary `400` validation refusal.
+ */
+export const CUSTOMER_SOCIAL_REGISTER_ERROR_CODES = [
+    'EMAIL_TAKEN_BY_ANOTHER_ACCOUNT',
+    'CUSTOMER_ID_ALLOCATION_EXHAUSTED',
+    'SIGN_IN_IDENTITY_UNVERIFIED',
+    'INVALID_ID_TOKEN',
+    'SIGN_IN_PROVIDER_UNSUPPORTED',
+];
 /**
  * `body.error` codes the operator refresh/session leg can refuse with —
  * `POST /auth { mode: 'refresh' }` and the body-transport ingress it shares with

package/dist/cjs/auth.js

@@ -1,6 +1,6 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.SESSION_ACTION_ERROR_CODES = exports.PASSKEY_ERROR_CODES = exports.TWO_FACTOR_MANAGEMENT_ERROR_CODES = exports.LOGIN_2FA_ERROR_CODES = exports.LOGIN_ERROR_CODES = exports.STEP_UP_ERROR_CODES = exports.REFRESH_ERROR_CODES = exports.SOCIAL_BRIDGE_ERROR_CODES = exports.SIGN_IN_METHOD_ERROR_CODES = void 0;
+exports.SESSION_ACTION_ERROR_CODES = exports.PASSKEY_ERROR_CODES = exports.TWO_FACTOR_MANAGEMENT_ERROR_CODES = exports.LOGIN_2FA_ERROR_CODES = exports.LOGIN_ERROR_CODES = exports.STEP_UP_ERROR_CODES = exports.REFRESH_ERROR_CODES = exports.CUSTOMER_SOCIAL_REGISTER_ERROR_CODES = exports.SOCIAL_BRIDGE_ERROR_CODES = exports.SIGN_IN_METHOD_ERROR_CODES = void 0;
 /**
  * `body.error` codes the sign-in-method paths can refuse with.
  *
@@ -43,12 +43,15 @@ exports.SESSION_ACTION_ERROR_CODES = exports.PASSKEY_ERROR_CODES = exports.TWO_F
  *   UID than this verified token carries. Closes the gap where a matching email
  *   address was enough. A security event, not a bad password.
  * - `SIGN_IN_IDENTITY_MISMATCH` (link) — the minted token's identity is not the
- *   account being linked to. ⚠️ Distinguishable here and deliberately NOT on the
+ *   account being linked to — including an Apple private relay that another
+ *   customer of the store holds as its email, which sign-in would resolve to
+ *   that customer and never to this one. ⚠️ Distinguishable here and deliberately NOT on the
  *   unauthenticated sign-in path: the linking caller is cookie-authenticated and
  *   already holds both operands, so naming the mismatch discloses nothing it did
  *   not supply. Naming it on sign-in would enumerate the customer table.
- * - `SIGN_IN_IDENTITY_UNVERIFIED` (link) — the provider asserts an identity it
- *   has not itself verified.
+ * - `SIGN_IN_IDENTITY_UNVERIFIED` (link, `social`, `social-bridge-mint`,
+ *   `register-social`) — the provider asserts an identity it has not itself
+ *   verified. Never the disabled-account answer: that stays `USER_NOT_ENABLED`.
  * - `INVALID_ID_TOKEN` — the token failed verification outright: malformed,
  *   expired, or signed by the wrong issuer. Retryable by re-authenticating.
  * - `SIGN_IN_PROVIDER_UNSUPPORTED` — the provider is not one this store accepts.
@@ -94,21 +97,73 @@ exports.SIGN_IN_METHOD_ERROR_CODES = [
 ];
 /**
  * Refusals of the custom-domain social bridge — `social-bridge-mint`,
- * `social-bridge-redeem` and `link-sign-in-method`'s `bridgeCode`.
+ * `social-bridge-redeem`, and the `bridgeCode` of `link-sign-in-method` and
+ * `register-social`.
  *
  * - `BRIDGE_ORIGIN_NOT_ALLOWED` · 400 (mint) — the request's Origin is not the
  *   store's own ACTIVE slug host (or `x-store` is malformed), or `returnOrigin`
  *   is not exactly `https://` + the store's ACTIVE canonical custom host or its
  *   `www.`: a pending, failed or spare domain, another store's domain, `http:`,
  *   a path, any explicit port or a trailing slash.
- * - `BRIDGE_CODE_INVALID` · 401 (redeem, link) — ONE code for every failure:
- *   malformed, unknown, already used, older than 60 s, presented from another
- *   Origin or at another store, minted for the other purpose, or sent without
+ * - `BRIDGE_CODE_INVALID` · 401 (redeem, link, register-social) — ONE code for
+ *   every failure: malformed, unknown, already used, older than 60 s, presented
+ *   from another Origin or at another store, minted for a different
+ *   {@link CustomerSocialBridgePurpose} than the redeeming mode's, or sent without
  *   the `state` it was minted for. Deliberately
  *   undifferentiated, so it is no oracle. Not retryable with the same code: it
  *   is spent by the attempt. Start the bridge again.
+ *   ⚠️ Except a `register-social` `bridgeCode` sent WITHOUT `state`: that mode's
+ *   schema requires `state`, so it is `400 VALIDATION_FAILED` before any redeem,
+ *   and the code is NOT spent — where `social-bridge-redeem` and
+ *   `link-sign-in-method` answer this `401` and spend it.
  */
 exports.SOCIAL_BRIDGE_ERROR_CODES = ['BRIDGE_ORIGIN_NOT_ALLOWED', 'BRIDGE_CODE_INVALID'];
+/**
+ * `body.error` codes `POST /auth { mode: 'register-social' }` can refuse with —
+ * see {@link CustomerSocialRegisterInput}. Nothing is written on any of them.
+ *
+ * A CONST TUPLE, module-scope, for the same reason as the sign-in cohort above:
+ * a consumer keys an exhaustive `Record<CustomerSocialRegisterErrorCode, string>`
+ * of copy off it, and the compiler re-checks that record when a member is added.
+ *
+ * The status is stated per member, but ⚠️ MATCH ON `body.error`, never on the
+ * status alone — the two 401s want different remedies.
+ *
+ * - `EMAIL_TAKEN_BY_ANOTHER_ACCOUNT` · 400 — a customer of this store already
+ *   holds the token's email, or (Apple) already has this private-relay identity
+ *   linked. Route to `mode: 'social'` sign-in, never to registering again. The
+ *   same answer `mode: 'register'` gives for a taken email, or for a typed
+ *   private-relay address already linked to a customer.
+ * - `CUSTOMER_ID_ALLOCATION_EXHAUSTED` · 409 — the store's customer-id space
+ *   could not yield a free id. Nothing the shopper sent is wrong; retryable
+ *   later. Shared with `mode: 'register'`.
+ * - `SIGN_IN_IDENTITY_UNVERIFIED` · 401 — the provider has not verified the
+ *   token's email, or the token carries none. Not retryable with this identity.
+ * - `INVALID_ID_TOKEN` · 401 — the token failed verification outright:
+ *   malformed, expired or wrongly issued. Retryable by re-authenticating with
+ *   the provider.
+ * - `SIGN_IN_PROVIDER_UNSUPPORTED` · 400 — a verified token from a provider
+ *   other than Google, Apple or Facebook. A configuration answer, not a
+ *   credential one.
+ *
+ * ⚠️ The last three are ALSO members of {@link SIGN_IN_METHOD_ERROR_CODES},
+ * deliberately: the same verification failure reads the same on every mode that
+ * verifies a token, so one copy entry can serve both.
+ *
+ * ⚠️ Not listed, because they are not this mode's own: a closed shop or a
+ * foreign Origin answers `403 STOREFRONT_UNAVAILABLE` / `403
+ * ORIGIN_STORE_MISMATCH` exactly as `mode: 'register'` does, and the
+ * `bridgeCode` leg's `401 BRIDGE_CODE_INVALID` lives in
+ * {@link SOCIAL_BRIDGE_ERROR_CODES}. An invalid `cuit` or `phone`, or a body
+ * with both or neither identity, is the ordinary `400` validation refusal.
+ */
+exports.CUSTOMER_SOCIAL_REGISTER_ERROR_CODES = [
+    'EMAIL_TAKEN_BY_ANOTHER_ACCOUNT',
+    'CUSTOMER_ID_ALLOCATION_EXHAUSTED',
+    'SIGN_IN_IDENTITY_UNVERIFIED',
+    'INVALID_ID_TOKEN',
+    'SIGN_IN_PROVIDER_UNSUPPORTED',
+];
 /**
  * `body.error` codes the operator refresh/session leg can refuse with —
  * `POST /auth { mode: 'refresh' }` and the body-transport ingress it shares with

package/dist/customer.d.ts

@@ -262,7 +262,9 @@ declare global {
         /** Absent after erasure or the final merge flip; registration still requires an address. */
         email?: string;
         /**
-         * Set ONLY by the customer OTP verify transaction.
+         * Set `true` ONLY where the address is proven: by the customer OTP verify
+         * transaction, or at creation by a storefront `register-social`, whose
+         * provider verified the email (an unverified identity creates nothing).
          *
          * ⚠️ UNDEFINED MEANS **NOT** VERIFIED — deliberately the INVERSE of
          * `User.emailVerified`, which carries a grandfather clause telling apps to
@@ -272,7 +274,10 @@ declare global {
          * verified and defeat the backfill it exists to force.
          */
         emailVerified?: boolean;
-        /** ms-epoch of the OTP verification. Absent whenever `emailVerified` is not `true`. */
+        /**
+         * ms-epoch of the proof: the OTP verification, or — for a `register-social`
+         * account — the row's `createdAt`. Absent whenever `emailVerified` is not `true`.
+         */
         emailVerifiedAt?: number;
         /**
          * Set ONLY by the customer's own phone verification (an SMS code they ask
@@ -1539,13 +1544,16 @@ declare global {
         refreshToken?: string;
     }
     /**
-     * The storefront registration body (`POST /auth {mode:'register'}`). On
-     * success it is the signed-in `AuthCustomer`, exactly as a password sign-in
-     * answers. On the one leg where the customer row committed but the session
-     * could not be minted it is the created customer with no token and
-     * `sessionIssued: false`: the account exists and its password works, so a
-     * client sends the shopper to sign in — never to register again, which the
-     * email uniqueness constraint would now refuse.
+     * The storefront registration body — `POST /auth` with `mode: 'register'`
+     * or `mode: 'register-social'`, which answer the same shape. On success it
+     * is the signed-in `AuthCustomer`, exactly as a sign-in answers. On the one
+     * leg where the customer row committed but the session could not be minted
+     * it is the created customer with no token and `sessionIssued: false`: the
+     * account exists and the credential it was created with works, so a client
+     * sends the shopper to sign in with THAT credential — the password on
+     * `register`, `mode: 'social'` with the same provider on `register-social`
+     * (that account has no password) — never to register again, which the email
+     * uniqueness constraint would now refuse.
      */
     type CustomerRegisterResult = AuthCustomer | (Customer & {
         accessToken?: never;

package/dist/storefrontEvent.d.ts

@@ -113,10 +113,9 @@ declare global {
          * The sign-in twin's union minus `'passkey'` — a passkey is registered
          * from an existing session, never at sign-up.
          *
-         * ⚠️ Only `'email'` is emitted today — registration is api-side and has
-         * no social leg. The social members are reachable shape, not observed
-         * data; do not read a member's presence here as evidence that path
-         * exists.
+         * `'email'` is password registration (`mode: 'register'`); the social
+         * members are `mode: 'register-social'`, which emits the provider the
+         * verified token names.
          */
         method: 'email' | 'google' | 'facebook' | 'apple';
     }

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "sinfactura-types",
-	"version": "1.10.658",
+	"version": "1.10.660",
 	"description": "Shared wire and entity contracts for the SINFACTURA platform.",
 	"type": "module",
 	"main": "dist/index.js",