@zyphr-dev/node-sdk 0.1.36 → 0.1.38

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zyphr-dev/node-sdk",
-  "version": "0.1.36",
+  "version": "0.1.38",
   "description": "Official Zyphr SDK for Node.js, React, and React Native",
   "type": "module",
   "main": "./dist/index.cjs",
@@ -49,10 +49,15 @@
     "openapi"
   ],
   "license": "MIT",
-  "homepage": "https://docs.zyphr.dev/sdks/node",
+  "homepage": "https://zyphr.dev/docs/sdks/node",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/ArcRaz/zyphr.git",
+    "directory": "packages/sdk/node"
+  },
   "bugs": {
     "email": "support@zyphr.dev",
-    "url": "https://docs.zyphr.dev"
+    "url": "https://zyphr.dev/docs"
   },
   "engines": {
     "node": ">=18.0.0"

package/src/.openapi-generator/FILES

@@ -14,6 +14,7 @@ src/apis/AuthPasswordResetApi.ts
 src/apis/AuthPhoneApi.ts
 src/apis/AuthRegistrationApi.ts
 src/apis/AuthSessionsApi.ts
+src/apis/AuthUserDirectoryApi.ts
 src/apis/AuthUserProfileApi.ts
 src/apis/AuthWebAuthnApi.ts
 src/apis/DevicesApi.ts
@@ -166,6 +167,7 @@ src/models/InboundEmailResponse.ts
 src/models/InboxListMeta.ts
 src/models/InboxListResponse.ts
 src/models/InboxNotificationResponse.ts
+src/models/InviteEndUserRequest.ts
 src/models/ListWaaSApplications200Response.ts
 src/models/ListWaaSEndpointDeliveries200Response.ts
 src/models/ListWaaSEndpoints200Response.ts
@@ -210,6 +212,7 @@ src/models/OAuthConnectionsResponse.ts
 src/models/OAuthConnectionsResponseData.ts
 src/models/OAuthProvider.ts
 src/models/OAuthProviderInfo.ts
+src/models/OAuthProviderName.ts
 src/models/OAuthProvidersResponse.ts
 src/models/OAuthProvidersResponseData.ts
 src/models/OAuthTokensRefreshResponse.ts
@@ -304,6 +307,7 @@ src/models/SendSlackMessageResult.ts
 src/models/SendSmsData.ts
 src/models/SendSmsRequest.ts
 src/models/SendSmsResponse.ts
+src/models/SendTemplateTestEmailRequest.ts
 src/models/SendTestSmsData.ts
 src/models/SendTestSmsRequest.ts
 src/models/SendTestSmsResponse.ts
@@ -312,9 +316,11 @@ src/models/SessionListResponse.ts
 src/models/SessionListResponseData.ts
 src/models/SessionListResponseDataSessionInfo.ts
 src/models/SetDomainInboundRequest.ts
+src/models/SetEndUserClaimsRequest.ts
 src/models/SetPreferencesRequest.ts
 src/models/SetPreferencesRequestPreferencesInner.ts
 src/models/SignInAnonymouslyRequest.ts
+src/models/SignInWithGameCenterRequest.ts
 src/models/SlackMessage.ts
 src/models/SlackMessageListResponse.ts
 src/models/SlackMessageListResponseMeta.ts
@@ -370,6 +376,7 @@ src/models/UnsubscribeListResponse.ts
 src/models/UnsubscribeRequest.ts
 src/models/UnsubscribeResponse.ts
 src/models/UpdateCategoryRequest.ts
+src/models/UpdateEndUserByApplicationRequest.ts
 src/models/UpdateEndUserRequest.ts
 src/models/UpdateOrganizationMemberRoleRequest.ts
 src/models/UpdateOrganizationRequest.ts

package/src/clientAuth.ts

@@ -0,0 +1,182 @@
+/**
+ * Zyphr client-side auth (sc-7326, Option A).
+ *
+ * `ZyphrClient` is a browser / React Native-safe entry point for Auth-as-a-Service.
+ * Unlike the server `Zyphr` client (which requires a secret API key and, for auth,
+ * an application SECRET key), `ZyphrClient` is constructed with ONLY the publishable
+ * application key (`za_pub_*`) — the key that is safe to ship in a client bundle —
+ * plus, once the user is authenticated, their end-user access token.
+ *
+ * It deliberately exposes ONLY the end-user-scoped auth surface (login, registration,
+ * sessions, magic links, OAuth, phone, email-OTP, profile, MFA, WebAuthn, password
+ * reset, email verification) and device registration for push. It does NOT expose
+ * server-only APIs (emails, templates, webhooks, the secret-key user directory, etc.),
+ * because those require a secret this client must never hold.
+ *
+ * @example
+ * ```ts
+ * import { ZyphrClient } from '@zyphr-dev/node-sdk';
+ *
+ * const zyphr = new ZyphrClient({ applicationKey: 'za_pub_xxx' });
+ *
+ * const login = await zyphr.auth.login.loginEndUser({ ... });
+ * zyphr.setAccessToken(login.data.tokens.access_token);
+ *
+ * const me = await zyphr.auth.profile.getEndUser(zyphr.authedRequest());
+ * ```
+ */
+
+import { Configuration } from './src/runtime.js';
+import type { Middleware, ResponseContext } from './src/runtime.js';
+import {
+  AuthEmailOTPApi,
+  AuthEmailVerificationApi,
+  AuthLoginApi,
+  AuthMFAApi,
+  AuthMagicLinksApi,
+  AuthOAuthApi,
+  AuthOrganizationsApi,
+  AuthPasswordResetApi,
+  AuthPhoneApi,
+  AuthRegistrationApi,
+  AuthSessionsApi,
+  AuthUserProfileApi,
+  AuthWebAuthnApi,
+  DevicesApi,
+} from './src/apis/index.js';
+import { parseErrorResponse } from './errors.js';
+
+export interface ZyphrClientOptions {
+  /** Publishable application key (za_pub_*) — safe to embed in a client bundle. */
+  applicationKey: string;
+  /** Override the base API URL (defaults to https://api.zyphr.dev/v1). */
+  baseUrl?: string;
+  /** Optional end-user access token, if you already have a session on construction. */
+  accessToken?: string;
+}
+
+const errorMiddleware: Middleware = {
+  async post(context: ResponseContext): Promise<Response | void> {
+    if (context.response.status >= 200 && context.response.status < 300) {
+      return;
+    }
+    throw await parseErrorResponse(context.response);
+  },
+};
+
+/**
+ * Thrown when a secret-shaped credential is passed to the client-safe SDK. This
+ * is a guardrail against accidentally shipping a secret in a client bundle.
+ */
+export class ZyphrClientCredentialError extends Error {
+  constructor(message: string) {
+    super(message);
+    this.name = 'ZyphrClientCredentialError';
+  }
+}
+
+/** Prefixes that must NEVER reach a client bundle. */
+const SECRET_KEY_PREFIXES = ['za_sec_', 'zy_live_', 'zy_test_'];
+
+export class ZyphrClient {
+  readonly auth: {
+    readonly login: AuthLoginApi;
+    readonly registration: AuthRegistrationApi;
+    readonly sessions: AuthSessionsApi;
+    readonly emailVerification: AuthEmailVerificationApi;
+    readonly passwordReset: AuthPasswordResetApi;
+    readonly mfa: AuthMFAApi;
+    readonly magicLinks: AuthMagicLinksApi;
+    readonly oauth: AuthOAuthApi;
+    readonly organizations: AuthOrganizationsApi;
+    readonly phone: AuthPhoneApi;
+    readonly emailOtp: AuthEmailOTPApi;
+    readonly profile: AuthUserProfileApi;
+    readonly webauthn: AuthWebAuthnApi;
+  };
+
+  /** Device registration for push (takes an OS-acquired token). */
+  readonly devices: DevicesApi;
+
+  private readonly applicationKey: string;
+  private accessToken?: string;
+
+  constructor(options: ZyphrClientOptions) {
+    if (!options.applicationKey) {
+      throw new ZyphrClientCredentialError('applicationKey (za_pub_*) is required');
+    }
+    // Guardrail: reject secret-shaped credentials so a secret can't be shipped
+    // in a client bundle by mistake.
+    if (SECRET_KEY_PREFIXES.some((p) => options.applicationKey.startsWith(p))) {
+      throw new ZyphrClientCredentialError(
+        'ZyphrClient must be constructed with a publishable application key (za_pub_*), ' +
+          'never a secret key. Secret keys must stay server-side.'
+      );
+    }
+    if (!options.applicationKey.startsWith('za_pub_')) {
+      throw new ZyphrClientCredentialError(
+        'applicationKey must be a publishable application key (za_pub_*).'
+      );
+    }
+
+    this.applicationKey = options.applicationKey;
+    this.accessToken = options.accessToken;
+
+    const config = new Configuration({
+      basePath: options.baseUrl,
+      // The only credential this client sends automatically is the publishable
+      // application key. End-user Bearer tokens are attached per-request via
+      // authedRequest() so token rotation doesn't require rebuilding the client.
+      apiKey: (name: string) => (name === 'X-Application-Key' ? this.applicationKey : ''),
+      middleware: [errorMiddleware],
+    });
+
+    this.auth = {
+      login: new AuthLoginApi(config),
+      registration: new AuthRegistrationApi(config),
+      sessions: new AuthSessionsApi(config),
+      emailVerification: new AuthEmailVerificationApi(config),
+      passwordReset: new AuthPasswordResetApi(config),
+      mfa: new AuthMFAApi(config),
+      magicLinks: new AuthMagicLinksApi(config),
+      oauth: new AuthOAuthApi(config),
+      organizations: new AuthOrganizationsApi(config),
+      phone: new AuthPhoneApi(config),
+      emailOtp: new AuthEmailOTPApi(config),
+      profile: new AuthUserProfileApi(config),
+      webauthn: new AuthWebAuthnApi(config),
+    };
+    this.devices = new DevicesApi(config);
+  }
+
+  /** Store the end-user access token for subsequent authedRequest() calls. */
+  setAccessToken(accessToken: string | undefined): void {
+    this.accessToken = accessToken;
+  }
+
+  /** True when an end-user access token is currently set. */
+  get isAuthenticated(): boolean {
+    return Boolean(this.accessToken);
+  }
+
+  /**
+   * Build request overrides that authenticate as the current end user: the
+   * stored Bearer token plus the publishable application key required by
+   * user-scoped endpoints. Pass an explicit token to override the stored one.
+   *
+   * @example
+   * ```ts
+   * const me = await zyphr.auth.profile.getEndUser(zyphr.authedRequest());
+   * ```
+   */
+  authedRequest(accessToken?: string): RequestInit {
+    const token = accessToken ?? this.accessToken;
+    const headers: Record<string, string> = {
+      'X-Application-Key': this.applicationKey,
+    };
+    if (token) {
+      headers.Authorization = `Bearer ${token}`;
+    }
+    return { headers };
+  }
+}

package/src/errors.ts

@@ -43,8 +43,8 @@ export class ZyphrError extends Error {
  * Thrown when the API returns a 400/422 validation error.
  */
 export class ZyphrValidationError extends ZyphrError {
-  constructor(message: string, details?: Record<string, unknown>) {
-    super({ message, status: 422, code: 'validation_error', details });
+  constructor(message: string, details?: Record<string, unknown>, code = 'validation_error') {
+    super({ message, status: 422, code, details });
     this.name = 'ZyphrValidationError';
   }
 }
@@ -53,8 +53,8 @@ export class ZyphrValidationError extends ZyphrError {
  * Thrown when the API returns a 401/403 authentication error.
  */
 export class ZyphrAuthenticationError extends ZyphrError {
-  constructor(message: string) {
-    super({ message, status: 401, code: 'authentication_error' });
+  constructor(message: string, code = 'authentication_error') {
+    super({ message, status: 401, code });
     this.name = 'ZyphrAuthenticationError';
   }
 }
@@ -65,8 +65,8 @@ export class ZyphrAuthenticationError extends ZyphrError {
 export class ZyphrRateLimitError extends ZyphrError {
   readonly retryAfter?: number;
 
-  constructor(message: string, retryAfter?: number) {
-    super({ message, status: 429, code: 'rate_limit_exceeded' });
+  constructor(message: string, retryAfter?: number, code = 'rate_limit_exceeded') {
+    super({ message, status: 429, code });
     this.name = 'ZyphrRateLimitError';
     this.retryAfter = retryAfter;
   }
@@ -76,8 +76,8 @@ export class ZyphrRateLimitError extends ZyphrError {
  * Thrown when the API returns a 404 not found error.
  */
 export class ZyphrNotFoundError extends ZyphrError {
-  constructor(message: string) {
-    super({ message, status: 404, code: 'not_found' });
+  constructor(message: string, code = 'not_found') {
+    super({ message, status: 404, code });
     this.name = 'ZyphrNotFoundError';
   }
 }
@@ -93,8 +93,13 @@ export class ZyphrNotFoundError extends ZyphrError {
  * @see https://zyphr.dev/resources/api-limits
  */
 export class ZyphrPayloadTooLargeError extends ZyphrError {
-  constructor(message: string, details?: Record<string, unknown>, requestId?: string) {
-    super({ message, status: 413, code: 'payload_too_large', details, requestId });
+  constructor(
+    message: string,
+    details?: Record<string, unknown>,
+    requestId?: string,
+    code = 'payload_too_large',
+  ) {
+    super({ message, status: 413, code, details, requestId });
     this.name = 'ZyphrPayloadTooLargeError';
   }
 
@@ -145,25 +150,33 @@ export async function parseErrorResponse(response: Response): Promise<ZyphrError
   const error = (body.error ?? {}) as Record<string, unknown>;
   const meta = (body.meta ?? {}) as Record<string, unknown>;
   const message = (error.message as string) ?? response.statusText ?? 'Unknown error';
-  const code = error.code as string | undefined;
+  // Coerce a missing / null / empty code to `undefined` so the typed-error
+  // constructors fall back to their generic default (a bare `null`/'' from a
+  // malformed or proxy-mangled response would otherwise be preserved verbatim).
+  const code = (error.code as string | undefined) || undefined;
   const requestId = meta.request_id as string | undefined;
   const details = error.details as Record<string, unknown> | undefined;
 
+  // Preserve the API's machine-readable `error.code` on the typed error so
+  // consumers can branch on it (e.g. `account_frozen`, `otp_invalid`,
+  // `email_not_found`) instead of matching `message` text. The subclass
+  // identity and `status` are unchanged; when the body omits a code we fall
+  // back to each subclass's generic default (older API responses).
   switch (response.status) {
     case 400:
     case 422:
-      return new ZyphrValidationError(message, details);
+      return new ZyphrValidationError(message, details, code);
     case 401:
     case 403:
-      return new ZyphrAuthenticationError(message);
+      return new ZyphrAuthenticationError(message, code);
     case 404:
-      return new ZyphrNotFoundError(message);
+      return new ZyphrNotFoundError(message, code);
     case 413:
-      return new ZyphrPayloadTooLargeError(message, details, requestId);
+      return new ZyphrPayloadTooLargeError(message, details, requestId, code);
     case 429: {
       const retryAfterHeader = response.headers.get('Retry-After');
       const retryAfter = retryAfterHeader ? parseInt(retryAfterHeader, 10) : undefined;
-      return new ZyphrRateLimitError(message, retryAfter);
+      return new ZyphrRateLimitError(message, retryAfter, code);
     }
     default:
       return new ZyphrError({ message, status: response.status, code, requestId, details });

package/src/index.ts

@@ -21,5 +21,8 @@ export * from './src/models/index.js';
 // Error classes
 export * from './errors.js';
 
-// Client
+// Client (server-side; requires secret keys)
 export * from './client.js';
+
+// Client-safe auth (browser / React Native; publishable key only) — sc-7326
+export * from './clientAuth.js';

package/src/src/apis/AuthEmailOTPApi.ts

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zyphr API
- * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+ * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account\'s current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zyphr.dev

package/src/src/apis/AuthEmailTemplatesApi.ts

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zyphr API
- * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+ * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account\'s current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zyphr.dev

package/src/src/apis/AuthEmailVerificationApi.ts

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zyphr API
- * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+ * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account\'s current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zyphr.dev

package/src/src/apis/AuthLoginApi.ts

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zyphr API
- * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+ * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account\'s current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zyphr.dev

package/src/src/apis/AuthMFAApi.ts

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zyphr API
- * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+ * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account\'s current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zyphr.dev

package/src/src/apis/AuthMagicLinksApi.ts

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * Zyphr API
- * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+ * Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account\'s current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@zyphr.dev