@zyphr-dev/node-sdk 0.1.39 → 0.1.41

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zyphr-dev/node-sdk",
-  "version": "0.1.39",
+  "version": "0.1.41",
   "description": "Official Zyphr SDK for Node.js, React, and React Native",
   "type": "module",
   "main": "./dist/index.cjs",

package/src/.openapi-generator/FILES

@@ -23,7 +23,6 @@ src/apis/EmailsApi.ts
 src/apis/ExecutionsApi.ts
 src/apis/InboundEmailApi.ts
 src/apis/InboxApi.ts
-src/apis/MuseApi.ts
 src/apis/PushApi.ts
 src/apis/SMSApi.ts
 src/apis/SlackApi.ts
@@ -38,6 +37,7 @@ src/apis/WaaSEventTypesApi.ts
 src/apis/WaaSEventsApi.ts
 src/apis/WaaSPortalApi.ts
 src/apis/WebhooksApi.ts
+src/apis/WorkflowsApi.ts
 src/apis/index.ts
 src/index.ts
 src/models/AddDomain200Response.ts
@@ -45,6 +45,8 @@ src/models/AddDomain200ResponseMeta.ts
 src/models/AddDomainRequest.ts
 src/models/AddOrganizationMemberRequest.ts
 src/models/AddTopicSubscribersRequest.ts
+src/models/AddWorkflowStep201Response.ts
+src/models/AddWorkflowStepRequest.ts
 src/models/ApiError.ts
 src/models/ApiErrorError.ts
 src/models/ApiErrorMeta.ts
@@ -111,10 +113,16 @@ src/models/CreateWaaSEndpointResponse.ts
 src/models/CreateWaaSEventType201Response.ts
 src/models/CreateWaaSEventTypeRequest.ts
 src/models/CreateWebhookRequest.ts
+src/models/CreateWorkflow201Response.ts
+src/models/CreateWorkflowRequest.ts
 src/models/DeleteDomainResponse.ts
 src/models/DeleteDomainResponseData.ts
 src/models/DeleteResult.ts
 src/models/DeleteResultData.ts
+src/models/DeleteWorkflow200Response.ts
+src/models/DeleteWorkflow200ResponseData.ts
+src/models/DeleteWorkflowStep200Response.ts
+src/models/DeleteWorkflowStep200ResponseData.ts
 src/models/Device.ts
 src/models/DeviceListResponse.ts
 src/models/DevicePushTopic.ts
@@ -172,6 +180,10 @@ src/models/ListWaaSApplications200Response.ts
 src/models/ListWaaSEndpointDeliveries200Response.ts
 src/models/ListWaaSEndpoints200Response.ts
 src/models/ListWaaSEventTypes200Response.ts
+src/models/ListWorkflowExecutions200Response.ts
+src/models/ListWorkflowExecutions200ResponseMeta.ts
+src/models/ListWorkflows200Response.ts
+src/models/ListWorkflows200ResponseMeta.ts
 src/models/LoginRequest.ts
 src/models/MagicLinkSendRequest.ts
 src/models/MagicLinkVerifyRequest.ts
@@ -266,6 +278,7 @@ src/models/RegisterRequest.ts
 src/models/RemoveTopicSubscribersRequest.ts
 src/models/RenameWebAuthnCredentialRequest.ts
 src/models/RenderTemplateRequest.ts
+src/models/ReorderWorkflowStepsRequest.ts
 src/models/ReplayWebhookEventsRequest.ts
 src/models/RequestMeta.ts
 src/models/ResetPasswordRequest.ts
@@ -336,7 +349,6 @@ src/models/SmsConfigDeleteResponseData.ts
 src/models/SmsConfigResponse.ts
 src/models/SmsDetailResponse.ts
 src/models/SmsListResponse.ts
-src/models/SmsListResponseMeta.ts
 src/models/SmsMessage.ts
 src/models/SmsMessageDetail.ts
 src/models/SubscribePushTopicRequest.ts
@@ -358,7 +370,6 @@ src/models/TemplateResponse.ts
 src/models/TestWebhookTransformRequest.ts
 src/models/Topic.ts
 src/models/TopicDeleteResponse.ts
-src/models/TopicDeleteResponseData.ts
 src/models/TopicListResponse.ts
 src/models/TopicResponse.ts
 src/models/TopicStatsData.ts
@@ -370,6 +381,9 @@ src/models/TopicSubscribersAddResponse.ts
 src/models/TopicSubscribersAddResult.ts
 src/models/TopicSubscribersRemoveResponse.ts
 src/models/TopicSubscribersRemoveResult.ts
+src/models/TriggerWorkflow202Response.ts
+src/models/TriggerWorkflow202ResponseData.ts
+src/models/TriggerWorkflowRequest.ts
 src/models/UnreadCountData.ts
 src/models/UnreadCountResponse.ts
 src/models/Unsubscribe.ts
@@ -390,11 +404,13 @@ src/models/UpdateWaaSApplicationRequest.ts
 src/models/UpdateWaaSEndpointRequest.ts
 src/models/UpdateWaaSEventTypeRequest.ts
 src/models/UpdateWebhookRequest.ts
+src/models/UpdateWorkflowRequest.ts
+src/models/UpdateWorkflowStatusRequest.ts
+src/models/UpdateWorkflowStepRequest.ts
 src/models/UpsertAuthEmailTemplateRequest.ts
 src/models/UpsertSmsConfigRequest.ts
 src/models/UserDevicesDeleteResponse.ts
 src/models/UserDevicesDeleteResponseData.ts
-src/models/V1MuseSubjectsSuggestPostRequest.ts
 src/models/ValidateResetTokenRequest.ts
 src/models/ValidateResetTokenResponse.ts
 src/models/ValidateResetTokenResponseData.ts
@@ -470,10 +486,14 @@ src/models/WebhookVersion.ts
 src/models/WebhookVersionsResponse.ts
 src/models/WebhookVersionsResponseData.ts
 src/models/WithdrawSubscriberConsentRequest.ts
+src/models/Workflow.ts
 src/models/WorkflowExecution.ts
 src/models/WorkflowExecutionStatus.ts
+src/models/WorkflowStatus.ts
+src/models/WorkflowStep.ts
 src/models/WorkflowStepExecution.ts
 src/models/WorkflowStepExecutionStatus.ts
+src/models/WorkflowStepType.ts
 src/models/index.ts
 src/runtime.ts
 tsconfig.esm.json

package/src/src/apis/AuthRegistrationApi.ts

@@ -116,7 +116,7 @@ export interface AuthRegistrationApiInterface {
     signInAnonymously(signInAnonymouslyRequest: SignInAnonymouslyRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<AuthResultResponse>;
 
     /**
-     * Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit\'s `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player\'s `gamePlayerID` and the app\'s bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer\'s own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+     * Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the player\'s `teamPlayerID` (the id GameKit signs the assertion over).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit\'s `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player\'s `teamPlayerID` (NOT `gamePlayerID`) and the app\'s bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer\'s own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
      * @summary Sign in with Apple Game Center
      * @param {SignInWithGameCenterRequest} signInWithGameCenterRequest 
      * @param {*} [options] Override http request option.
@@ -126,7 +126,7 @@ export interface AuthRegistrationApiInterface {
     signInWithGameCenterRaw(requestParameters: AuthRegistrationApiSignInWithGameCenterOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<AuthResultResponse>>;
 
     /**
-     * Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit\'s `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player\'s `gamePlayerID` and the app\'s bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer\'s own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+     * Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the player\'s `teamPlayerID` (the id GameKit signs the assertion over).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit\'s `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player\'s `teamPlayerID` (NOT `gamePlayerID`) and the app\'s bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer\'s own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
      * Sign in with Apple Game Center
      */
     signInWithGameCenter(signInWithGameCenterRequest: SignInWithGameCenterRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<AuthResultResponse>;
@@ -281,7 +281,7 @@ export class AuthRegistrationApi extends runtime.BaseAPI implements AuthRegistra
     }
 
     /**
-     * Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit\'s `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player\'s `gamePlayerID` and the app\'s bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer\'s own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+     * Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the player\'s `teamPlayerID` (the id GameKit signs the assertion over).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit\'s `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player\'s `teamPlayerID` (NOT `gamePlayerID`) and the app\'s bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer\'s own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
      * Sign in with Apple Game Center
      */
     async signInWithGameCenterRaw(requestParameters: AuthRegistrationApiSignInWithGameCenterOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<AuthResultResponse>> {
@@ -314,7 +314,7 @@ export class AuthRegistrationApi extends runtime.BaseAPI implements AuthRegistra
     }
 
     /**
-     * Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit\'s `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player\'s `gamePlayerID` and the app\'s bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer\'s own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+     * Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the player\'s `teamPlayerID` (the id GameKit signs the assertion over).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit\'s `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player\'s `teamPlayerID` (NOT `gamePlayerID`) and the app\'s bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer\'s own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
      * Sign in with Apple Game Center
      */
     async signInWithGameCenter(signInWithGameCenterRequest: SignInWithGameCenterRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<AuthResultResponse> {