@zyphr-dev/node-sdk 0.1.59 → 0.1.61

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (550) hide show
  1. package/dist/index.cjs +65 -6
  2. package/dist/index.cjs.map +1 -1
  3. package/dist/index.d.cts +646 -546
  4. package/dist/index.d.ts +646 -546
  5. package/dist/index.js +60 -6
  6. package/dist/index.js.map +1 -1
  7. package/package.json +1 -1
  8. package/src/.openapi-generator/FILES +1 -0
  9. package/src/src/apis/AuthApplicationApi.ts +1 -1
  10. package/src/src/apis/AuthEmailOTPApi.ts +1 -1
  11. package/src/src/apis/AuthEmailTemplatesApi.ts +1 -1
  12. package/src/src/apis/AuthEmailVerificationApi.ts +1 -1
  13. package/src/src/apis/AuthLoginApi.ts +1 -1
  14. package/src/src/apis/AuthMFAApi.ts +1 -1
  15. package/src/src/apis/AuthMagicLinksApi.ts +1 -1
  16. package/src/src/apis/AuthOAuthApi.ts +1 -1
  17. package/src/src/apis/AuthOrganizationsApi.ts +1 -1
  18. package/src/src/apis/AuthPasswordResetApi.ts +1 -1
  19. package/src/src/apis/AuthPhoneApi.ts +1 -1
  20. package/src/src/apis/AuthRegistrationApi.ts +1 -1
  21. package/src/src/apis/AuthSessionsApi.ts +1 -1
  22. package/src/src/apis/AuthUserDirectoryApi.ts +1 -1
  23. package/src/src/apis/AuthUserProfileApi.ts +1 -1
  24. package/src/src/apis/AuthWebAuthnApi.ts +1 -1
  25. package/src/src/apis/DevicesApi.ts +1 -1
  26. package/src/src/apis/DomainsApi.ts +1 -1
  27. package/src/src/apis/EmailsApi.ts +1 -1
  28. package/src/src/apis/ExecutionsApi.ts +1 -1
  29. package/src/src/apis/InboundEmailApi.ts +1 -1
  30. package/src/src/apis/InboxApi.ts +1 -1
  31. package/src/src/apis/PushApi.ts +1 -1
  32. package/src/src/apis/SMSApi.ts +1 -1
  33. package/src/src/apis/SlackApi.ts +1 -1
  34. package/src/src/apis/SubscribersApi.ts +1 -1
  35. package/src/src/apis/TemplatesApi.ts +1 -1
  36. package/src/src/apis/TopicsApi.ts +1 -1
  37. package/src/src/apis/UtilityApi.ts +1 -1
  38. package/src/src/apis/WaaSApplicationsApi.ts +1 -1
  39. package/src/src/apis/WaaSDeliveriesApi.ts +1 -1
  40. package/src/src/apis/WaaSEndpointsApi.ts +1 -1
  41. package/src/src/apis/WaaSEventTypesApi.ts +1 -1
  42. package/src/src/apis/WaaSEventsApi.ts +1 -1
  43. package/src/src/apis/WaaSPortalApi.ts +1 -1
  44. package/src/src/apis/WebhooksApi.ts +1 -1
  45. package/src/src/apis/WorkflowsApi.ts +1 -1
  46. package/src/src/models/AddDomain200Response.ts +1 -1
  47. package/src/src/models/AddDomain200ResponseMeta.ts +1 -1
  48. package/src/src/models/AddDomainRequest.ts +1 -1
  49. package/src/src/models/AddOrganizationMemberRequest.ts +1 -1
  50. package/src/src/models/AddTopicSubscribersRequest.ts +1 -1
  51. package/src/src/models/AddWorkflowStep201Response.ts +1 -1
  52. package/src/src/models/AddWorkflowStepRequest.ts +1 -1
  53. package/src/src/models/ApiError.ts +1 -1
  54. package/src/src/models/ApiErrorError.ts +1 -1
  55. package/src/src/models/ApiErrorMeta.ts +1 -1
  56. package/src/src/models/ApplicationSelf.ts +1 -1
  57. package/src/src/models/ApplicationSelfResponse.ts +1 -1
  58. package/src/src/models/AuthEmailTemplate.ts +1 -1
  59. package/src/src/models/AuthEmailTemplateDefault.ts +1 -1
  60. package/src/src/models/AuthEmailTemplateDefaultResponse.ts +1 -1
  61. package/src/src/models/AuthEmailTemplateDeleteResponse.ts +1 -1
  62. package/src/src/models/AuthEmailTemplateDeleteResponseData.ts +1 -1
  63. package/src/src/models/AuthEmailTemplateListResponse.ts +1 -1
  64. package/src/src/models/AuthEmailTemplatePreviewDraft.ts +1 -1
  65. package/src/src/models/AuthEmailTemplatePreviewRequest.ts +1 -1
  66. package/src/src/models/AuthEmailTemplatePreviewResponse.ts +1 -1
  67. package/src/src/models/AuthEmailTemplatePreviewResult.ts +1 -1
  68. package/src/src/models/AuthEmailTemplateResponse.ts +1 -1
  69. package/src/src/models/AuthEmailTemplateTestRequest.ts +1 -1
  70. package/src/src/models/AuthEmailTemplateTestResponse.ts +1 -1
  71. package/src/src/models/AuthEmailTemplateTestResult.ts +1 -1
  72. package/src/src/models/AuthEmailTemplateVersion.ts +1 -1
  73. package/src/src/models/AuthEmailTemplateVersionsResponse.ts +1 -1
  74. package/src/src/models/AuthEmailType.ts +1 -1
  75. package/src/src/models/AuthLoginResponse.ts +1 -1
  76. package/src/src/models/AuthLoginResult.ts +1 -1
  77. package/src/src/models/AuthLoginResultMfaChallenge.ts +1 -1
  78. package/src/src/models/AuthMethods.ts +1 -1
  79. package/src/src/models/AuthResult.ts +1 -1
  80. package/src/src/models/AuthResultResponse.ts +1 -1
  81. package/src/src/models/AuthSession.ts +1 -1
  82. package/src/src/models/AuthTokens.ts +1 -1
  83. package/src/src/models/AuthUser.ts +1 -1
  84. package/src/src/models/AuthUserResponse.ts +1 -1
  85. package/src/src/models/AuthUserResponseData.ts +1 -1
  86. package/src/src/models/BatchPublishWaaSEvents201Response.ts +1 -1
  87. package/src/src/models/BatchRecipient.ts +1 -1
  88. package/src/src/models/BulkRetryWebhookDeliveriesRequest.ts +1 -1
  89. package/src/src/models/BulkUpsertAuthEmailTemplatesRequest.ts +1 -1
  90. package/src/src/models/BulkUpsertAuthEmailTemplatesResponse.ts +1 -1
  91. package/src/src/models/Category.ts +1 -1
  92. package/src/src/models/CategoryListResponse.ts +1 -1
  93. package/src/src/models/CategoryResponse.ts +1 -1
  94. package/src/src/models/ChangePasswordRequest.ts +1 -1
  95. package/src/src/models/CloseWaaSEndpointCircuit200Response.ts +1 -1
  96. package/src/src/models/CloseWaaSEndpointCircuit200ResponseData.ts +1 -1
  97. package/src/src/models/ConfirmEmailVerificationRequest.ts +1 -1
  98. package/src/src/models/ConfirmEmailVerificationResponse.ts +1 -1
  99. package/src/src/models/ConfirmEmailVerificationResponseData.ts +1 -1
  100. package/src/src/models/ConsentHistoryEntry.ts +1 -1
  101. package/src/src/models/ConsentHistoryResponse.ts +1 -1
  102. package/src/src/models/ConsentRecordResponse.ts +1 -1
  103. package/src/src/models/ConsentRecordResponseData.ts +1 -1
  104. package/src/src/models/ConsentStatus.ts +1 -1
  105. package/src/src/models/ConsentStatusResponse.ts +1 -1
  106. package/src/src/models/ConsentWithdrawResponse.ts +1 -1
  107. package/src/src/models/ConvertAnonymousUserRequest.ts +1 -1
  108. package/src/src/models/ConvertAnonymousUserRequestOneOf.ts +1 -1
  109. package/src/src/models/ConvertAnonymousUserRequestOneOf1.ts +1 -1
  110. package/src/src/models/ConvertAnonymousUserRequestOneOf1AppleUser.ts +1 -1
  111. package/src/src/models/ConvertAnonymousUserRequestOneOf1AppleUserName.ts +1 -1
  112. package/src/src/models/CreateCategoryRequest.ts +1 -1
  113. package/src/src/models/CreateOrganizationRequest.ts +1 -1
  114. package/src/src/models/CreateSubscriberRequest.ts +1 -1
  115. package/src/src/models/CreateTemplateRequest.ts +1 -1
  116. package/src/src/models/CreateTopicRequest.ts +1 -1
  117. package/src/src/models/CreateWaaSApplication201Response.ts +1 -1
  118. package/src/src/models/CreateWaaSApplicationRequest.ts +1 -1
  119. package/src/src/models/CreateWaaSEndpoint201Response.ts +1 -1
  120. package/src/src/models/CreateWaaSEndpointRequest.ts +1 -1
  121. package/src/src/models/CreateWaaSEndpointResponse.ts +1 -1
  122. package/src/src/models/CreateWaaSEventType201Response.ts +1 -1
  123. package/src/src/models/CreateWaaSEventTypeRequest.ts +1 -1
  124. package/src/src/models/CreateWebhookRequest.ts +1 -1
  125. package/src/src/models/CreateWorkflow201Response.ts +1 -1
  126. package/src/src/models/CreateWorkflowRequest.ts +1 -1
  127. package/src/src/models/DeleteDomainResponse.ts +1 -1
  128. package/src/src/models/DeleteDomainResponseData.ts +1 -1
  129. package/src/src/models/DeleteResult.ts +1 -1
  130. package/src/src/models/DeleteResultData.ts +1 -1
  131. package/src/src/models/DeleteWorkflow200Response.ts +1 -1
  132. package/src/src/models/DeleteWorkflow200ResponseData.ts +1 -1
  133. package/src/src/models/DeleteWorkflowStep200Response.ts +1 -1
  134. package/src/src/models/DeleteWorkflowStep200ResponseData.ts +1 -1
  135. package/src/src/models/Device.ts +1 -1
  136. package/src/src/models/DeviceListResponse.ts +1 -1
  137. package/src/src/models/DevicePushTopic.ts +1 -1
  138. package/src/src/models/DevicePushTopicListResponse.ts +1 -1
  139. package/src/src/models/DevicePushTopicListResponseMeta.ts +1 -1
  140. package/src/src/models/DeviceResponse.ts +1 -1
  141. package/src/src/models/DeviceStats.ts +1 -1
  142. package/src/src/models/DeviceStatsResponse.ts +1 -1
  143. package/src/src/models/DnsRecord.ts +1 -1
  144. package/src/src/models/DomainListResponse.ts +1 -1
  145. package/src/src/models/DomainListResponseMeta.ts +1 -1
  146. package/src/src/models/DomainResponse.ts +1 -1
  147. package/src/src/models/EmailAddress.ts +1 -1
  148. package/src/src/models/EmailAttachment.ts +1 -1
  149. package/src/src/models/EmailEvent.ts +1 -1
  150. package/src/src/models/EmailEventsResponse.ts +1 -1
  151. package/src/src/models/EmailListResponse.ts +1 -1
  152. package/src/src/models/EmailMessage.ts +1 -1
  153. package/src/src/models/EmailResponse.ts +1 -1
  154. package/src/src/models/EmailTrackingClickLink.ts +1 -1
  155. package/src/src/models/EmailTrackingClicks.ts +1 -1
  156. package/src/src/models/EmailTrackingData.ts +1 -1
  157. package/src/src/models/EmailTrackingOpens.ts +1 -1
  158. package/src/src/models/EmailTrackingResponse.ts +1 -1
  159. package/src/src/models/EndUserDeleteResponse.ts +1 -1
  160. package/src/src/models/EndUserDeleteResponseData.ts +1 -1
  161. package/src/src/models/ExecutionCancelResponse.ts +1 -1
  162. package/src/src/models/ExecutionCancelResponseData.ts +1 -1
  163. package/src/src/models/ExecutionResponse.ts +1 -1
  164. package/src/src/models/ExecutionRetryResponse.ts +1 -1
  165. package/src/src/models/ExecutionRetryResponseData.ts +1 -1
  166. package/src/src/models/ForgotPasswordRequest.ts +1 -1
  167. package/src/src/models/GenerateSubscriberToken200Response.ts +1 -1
  168. package/src/src/models/GenerateSubscriberToken200ResponseData.ts +1 -1
  169. package/src/src/models/GenerateSubscriberTokenRequest.ts +1 -1
  170. package/src/src/models/GenerateWaaSPortalToken201Response.ts +1 -1
  171. package/src/src/models/GetDomain200Response.ts +1 -1
  172. package/src/src/models/GetDomain200ResponseMeta.ts +1 -1
  173. package/src/src/models/GetEndUserAuthMethods200Response.ts +1 -1
  174. package/src/src/models/GetEndUserById200Response.ts +1 -1
  175. package/src/src/models/GetEndUserClaims200Response.ts +1 -1
  176. package/src/src/models/GetEndUserClaims200ResponseData.ts +1 -1
  177. package/src/src/models/GetSubscriberInboxPreferences200Response.ts +1 -1
  178. package/src/src/models/GetSubscriberInboxPreferences200ResponseData.ts +1 -1
  179. package/src/src/models/GetSubscriberInboxPreferences200ResponseDataCategoriesInner.ts +1 -1
  180. package/src/src/models/GetSubscriberInboxPreferences200ResponseDataCategoriesInnerCategory.ts +1 -1
  181. package/src/src/models/GetSubscriberInboxPreferences200ResponseDataGlobal.ts +1 -1
  182. package/src/src/models/GetSubscriberInboxPreferences200ResponseDataGlobalChannelsInner.ts +1 -1
  183. package/src/src/models/GetSubscriberNotification200Response.ts +1 -1
  184. package/src/src/models/GetSubscriberUnreadCount200Response.ts +1 -1
  185. package/src/src/models/GetWaaSDelivery200Response.ts +1 -1
  186. package/src/src/models/GetWaaSEndpoint200Response.ts +1 -1
  187. package/src/src/models/GetWaaSEndpointCircuit200Response.ts +1 -1
  188. package/src/src/models/GetWaaSEndpointCircuit200ResponseData.ts +1 -1
  189. package/src/src/models/GetWaaSEndpointMetrics200Response.ts +1 -1
  190. package/src/src/models/GetWaaSEndpointMetrics200ResponseData.ts +1 -1
  191. package/src/src/models/GetWaaSEndpointMetrics200ResponseDataHealth.ts +1 -1
  192. package/src/src/models/GetWaaSEndpointMetrics200ResponseDataWindowsValue.ts +1 -1
  193. package/src/src/models/GetWaaSUsage200Response.ts +1 -1
  194. package/src/src/models/InAppNotification.ts +1 -1
  195. package/src/src/models/InboundAttachmentUrlResponse.ts +1 -1
  196. package/src/src/models/InboundAttachmentUrlResponseData.ts +1 -1
  197. package/src/src/models/InboundEmail.ts +1 -1
  198. package/src/src/models/InboundEmailAttachment.ts +1 -1
  199. package/src/src/models/InboundEmailFrom.ts +1 -1
  200. package/src/src/models/InboundEmailListResponse.ts +1 -1
  201. package/src/src/models/InboundEmailListResponseMeta.ts +1 -1
  202. package/src/src/models/InboundEmailResponse.ts +1 -1
  203. package/src/src/models/InboxListMeta.ts +1 -1
  204. package/src/src/models/InboxListResponse.ts +1 -1
  205. package/src/src/models/InboxNotificationResponse.ts +1 -1
  206. package/src/src/models/InviteEndUser200Response.ts +1 -1
  207. package/src/src/models/InviteEndUser200ResponseData.ts +1 -1
  208. package/src/src/models/InviteEndUserRequest.ts +1 -1
  209. package/src/src/models/ListEndUsers200Response.ts +1 -1
  210. package/src/src/models/ListEndUsers200ResponseMeta.ts +1 -1
  211. package/src/src/models/ListWaaSApplications200Response.ts +1 -1
  212. package/src/src/models/ListWaaSEndpointDeliveries200Response.ts +1 -1
  213. package/src/src/models/ListWaaSEndpoints200Response.ts +1 -1
  214. package/src/src/models/ListWaaSEventTypes200Response.ts +1 -1
  215. package/src/src/models/ListWorkflowExecutions200Response.ts +1 -1
  216. package/src/src/models/ListWorkflows200Response.ts +1 -1
  217. package/src/src/models/ListWorkflows200ResponseMeta.ts +1 -1
  218. package/src/src/models/LoginRequest.ts +1 -1
  219. package/src/src/models/MagicLinkSendRequest.ts +1 -1
  220. package/src/src/models/MagicLinkVerifyRequest.ts +1 -1
  221. package/src/src/models/MagicLinkVerifyResponse.ts +1 -1
  222. package/src/src/models/MagicLinkVerifyResponseData.ts +1 -1
  223. package/src/src/models/MarkAllInboxReadRequest.ts +1 -1
  224. package/src/src/models/MarkAllReadData.ts +1 -1
  225. package/src/src/models/MarkAllReadResponse.ts +1 -1
  226. package/src/src/models/MarkAllSubscriberNotificationsRead200Response.ts +1 -1
  227. package/src/src/models/MarkAllSubscriberNotificationsReadRequest.ts +1 -1
  228. package/src/src/models/MarkInboxReadRequest.ts +1 -1
  229. package/src/src/models/MfaBackupCodesResponse.ts +1 -1
  230. package/src/src/models/MfaBackupCodesResponseData.ts +1 -1
  231. package/src/src/models/MfaDisableRequest.ts +1 -1
  232. package/src/src/models/MfaDisableResponse.ts +1 -1
  233. package/src/src/models/MfaDisableResponseData.ts +1 -1
  234. package/src/src/models/MfaEnrollRequest.ts +1 -1
  235. package/src/src/models/MfaEnrollmentResponse.ts +1 -1
  236. package/src/src/models/MfaEnrollmentResponseData.ts +1 -1
  237. package/src/src/models/MfaRegenerateBackupCodesRequest.ts +1 -1
  238. package/src/src/models/MfaStatusResponse.ts +1 -1
  239. package/src/src/models/MfaStatusResponseData.ts +1 -1
  240. package/src/src/models/MfaVerifyBackupRequest.ts +1 -1
  241. package/src/src/models/MfaVerifyBackupResponse.ts +1 -1
  242. package/src/src/models/MfaVerifyBackupResponseData.ts +1 -1
  243. package/src/src/models/MfaVerifyEnrollmentRequest.ts +1 -1
  244. package/src/src/models/MfaVerifyEnrollmentResponse.ts +1 -1
  245. package/src/src/models/MfaVerifyEnrollmentResponseData.ts +1 -1
  246. package/src/src/models/MfaVerifyRequest.ts +1 -1
  247. package/src/src/models/OAuthAuthorizationUrlResponse.ts +1 -1
  248. package/src/src/models/OAuthAuthorizationUrlResponseData.ts +1 -1
  249. package/src/src/models/OAuthAuthorizeResponse.ts +1 -1
  250. package/src/src/models/OAuthAuthorizeResponseData.ts +1 -1
  251. package/src/src/models/OAuthCallbackRequest.ts +1 -1
  252. package/src/src/models/OAuthCallbackResponse.ts +1 -1
  253. package/src/src/models/OAuthCallbackResponseData.ts +1 -1
  254. package/src/src/models/OAuthConnection.ts +1 -1
  255. package/src/src/models/OAuthConnectionInfoResponse.ts +1 -1
  256. package/src/src/models/OAuthConnectionInfoResponseData.ts +1 -1
  257. package/src/src/models/OAuthConnectionsResponse.ts +1 -1
  258. package/src/src/models/OAuthConnectionsResponseData.ts +1 -1
  259. package/src/src/models/OAuthLinkResponse.ts +1 -1
  260. package/src/src/models/OAuthLinkResponseData.ts +1 -1
  261. package/src/src/models/OAuthProvider.ts +1 -1
  262. package/src/src/models/OAuthProviderInfo.ts +1 -1
  263. package/src/src/models/OAuthProviderName.ts +1 -1
  264. package/src/src/models/OAuthProvidersResponse.ts +1 -1
  265. package/src/src/models/OAuthProvidersResponseData.ts +1 -1
  266. package/src/src/models/OAuthTokensRefreshResponse.ts +1 -1
  267. package/src/src/models/OAuthTokensRefreshResponseData.ts +1 -1
  268. package/src/src/models/OAuthTokensResponse.ts +1 -1
  269. package/src/src/models/OAuthTokensResponseData.ts +1 -1
  270. package/src/src/models/Organization.ts +1 -1
  271. package/src/src/models/OrganizationListResponse.ts +1 -1
  272. package/src/src/models/OrganizationListResponseMeta.ts +1 -1
  273. package/src/src/models/OrganizationMembersListResponse.ts +1 -1
  274. package/src/src/models/OrganizationMembership.ts +1 -1
  275. package/src/src/models/OrganizationMembershipResponse.ts +1 -1
  276. package/src/src/models/OrganizationMembershipWithUser.ts +1 -1
  277. package/src/src/models/OrganizationResponse.ts +1 -1
  278. package/src/src/models/PaginationMeta.ts +1 -1
  279. package/src/src/models/PasswordPolicy.ts +1 -1
  280. package/src/src/models/PasswordRequirementsResponse.ts +1 -1
  281. package/src/src/models/PasswordRequirementsResponseData.ts +1 -1
  282. package/src/src/models/PasswordStrength.ts +1 -1
  283. package/src/src/models/PasswordStrengthRequest.ts +1 -1
  284. package/src/src/models/PasswordStrengthResponse.ts +1 -1
  285. package/src/src/models/PayloadTooLargeError.ts +1 -1
  286. package/src/src/models/PayloadTooLargeErrorError.ts +1 -1
  287. package/src/src/models/PayloadTooLargeErrorErrorDetails.ts +1 -1
  288. package/src/src/models/PhoneAuthAvailabilityResponse.ts +1 -1
  289. package/src/src/models/PhoneAuthAvailabilityResponseData.ts +1 -1
  290. package/src/src/models/PhoneLoginVerifyRequest.ts +1 -1
  291. package/src/src/models/PhoneOtpSendRequest.ts +1 -1
  292. package/src/src/models/PhoneOtpSentResponse.ts +1 -1
  293. package/src/src/models/PhoneOtpSentResponseData.ts +1 -1
  294. package/src/src/models/PhoneRegisterVerifyRequest.ts +1 -1
  295. package/src/src/models/PreferenceListResponse.ts +1 -1
  296. package/src/src/models/PublishWaaSEvent201Response.ts +1 -1
  297. package/src/src/models/PushDetailResponse.ts +1 -1
  298. package/src/src/models/PushEvent.ts +1 -1
  299. package/src/src/models/PushListResponse.ts +1 -1
  300. package/src/src/models/PushMessage.ts +1 -1
  301. package/src/src/models/PushMessageDetail.ts +1 -1
  302. package/src/src/models/PushMessageDetailAllOfActionButtons.ts +1 -1
  303. package/src/src/models/PushStatsData.ts +1 -1
  304. package/src/src/models/PushStatsResponse.ts +1 -1
  305. package/src/src/models/PushTopicDevice.ts +1 -1
  306. package/src/src/models/PushTopicDeviceListResponse.ts +1 -1
  307. package/src/src/models/PushTopicSubscribeData.ts +1 -1
  308. package/src/src/models/PushTopicSubscribeResponse.ts +1 -1
  309. package/src/src/models/PushTopicUnsubscribeData.ts +1 -1
  310. package/src/src/models/PushTopicUnsubscribeResponse.ts +1 -1
  311. package/src/src/models/RefreshOAuthTokensRequest.ts +1 -1
  312. package/src/src/models/RefreshSessionRequest.ts +1 -1
  313. package/src/src/models/RefreshTokenResponse.ts +1 -1
  314. package/src/src/models/RefreshTokenResponseData.ts +1 -1
  315. package/src/src/models/RegisterDeviceRequest.ts +1 -1
  316. package/src/src/models/RegisterRequest.ts +1 -1
  317. package/src/src/models/RemoveTopicSubscribersRequest.ts +1 -1
  318. package/src/src/models/RenameWebAuthnCredentialRequest.ts +1 -1
  319. package/src/src/models/RenderTemplateRequest.ts +1 -1
  320. package/src/src/models/ReorderWorkflowStepsRequest.ts +1 -1
  321. package/src/src/models/ReplayWebhookEventsRequest.ts +1 -1
  322. package/src/src/models/RequestMeta.ts +1 -1
  323. package/src/src/models/ResendEmailVerificationRequest.ts +1 -1
  324. package/src/src/models/ResetPasswordRequest.ts +1 -1
  325. package/src/src/models/ResetPasswordResponse.ts +1 -1
  326. package/src/src/models/ResubscribeRequest.ts +1 -1
  327. package/src/src/models/ResubscribeResponse.ts +1 -1
  328. package/src/src/models/RevokeAllSessionsResponse.ts +1 -1
  329. package/src/src/models/RevokeAllSessionsResponseData.ts +1 -1
  330. package/src/src/models/RevokeSessionRequest.ts +1 -1
  331. package/src/src/models/RotateWaaSEndpointSecret200Response.ts +1 -1
  332. package/src/src/models/RotateWaaSEndpointSecret200ResponseData.ts +1 -1
  333. package/src/src/models/SendBatchEmailRequest.ts +1 -1
  334. package/src/src/models/SendBatchEmailResponse.ts +1 -1
  335. package/src/src/models/SendBatchEmailResult.ts +1 -1
  336. package/src/src/models/SendBatchEmailResultItem.ts +1 -1
  337. package/src/src/models/SendBatchInAppMeta.ts +1 -1
  338. package/src/src/models/SendBatchInAppRequest.ts +1 -1
  339. package/src/src/models/SendBatchInAppResponse.ts +1 -1
  340. package/src/src/models/SendBatchSmsData.ts +1 -1
  341. package/src/src/models/SendBatchSmsRequest.ts +1 -1
  342. package/src/src/models/SendBatchSmsResponse.ts +1 -1
  343. package/src/src/models/SendEmailOtpRegistrationRequest.ts +1 -1
  344. package/src/src/models/SendEmailRequest.ts +1 -1
  345. package/src/src/models/SendEmailResponse.ts +1 -1
  346. package/src/src/models/SendEmailResponseData.ts +1 -1
  347. package/src/src/models/SendEmailResponseMeta.ts +1 -1
  348. package/src/src/models/SendEmailVerificationRequest.ts +1 -1
  349. package/src/src/models/SendInAppMeta.ts +1 -1
  350. package/src/src/models/SendInAppRequest.ts +1 -1
  351. package/src/src/models/SendInAppResponse.ts +1 -1
  352. package/src/src/models/SendPushRequest.ts +1 -1
  353. package/src/src/models/SendPushRequestActionButtonsInner.ts +1 -1
  354. package/src/src/models/SendPushResponse.ts +1 -1
  355. package/src/src/models/SendPushResponseData.ts +1 -1
  356. package/src/src/models/SendPushToTopicData.ts +1 -1
  357. package/src/src/models/SendPushToTopicRequest.ts +1 -1
  358. package/src/src/models/SendPushToTopicResponse.ts +1 -1
  359. package/src/src/models/SendSlackMessageRequest.ts +1 -1
  360. package/src/src/models/SendSlackMessageResponse.ts +1 -1
  361. package/src/src/models/SendSlackMessageResult.ts +1 -1
  362. package/src/src/models/SendSmsData.ts +1 -1
  363. package/src/src/models/SendSmsRequest.ts +1 -1
  364. package/src/src/models/SendSmsResponse.ts +1 -1
  365. package/src/src/models/SendTemplateTestEmail202Response.ts +1 -1
  366. package/src/src/models/SendTemplateTestEmail202ResponseData.ts +1 -1
  367. package/src/src/models/SendTemplateTestEmail202ResponseMeta.ts +1 -1
  368. package/src/src/models/SendTemplateTestEmailRequest.ts +1 -1
  369. package/src/src/models/SendTestSmsData.ts +1 -1
  370. package/src/src/models/SendTestSmsRequest.ts +1 -1
  371. package/src/src/models/SendTestSmsResponse.ts +1 -1
  372. package/src/src/models/SendWebhookTestEventRequest.ts +1 -1
  373. package/src/src/models/SessionListResponse.ts +1 -1
  374. package/src/src/models/SessionListResponseData.ts +1 -1
  375. package/src/src/models/SessionListResponseDataSessionInfo.ts +1 -1
  376. package/src/src/models/SetDomainInboundRequest.ts +1 -1
  377. package/src/src/models/SetEndUserClaims200Response.ts +1 -1
  378. package/src/src/models/SetEndUserClaims200ResponseData.ts +1 -1
  379. package/src/src/models/SetEndUserClaimsRequest.ts +1 -1
  380. package/src/src/models/SetPreferencesRequest.ts +1 -1
  381. package/src/src/models/SetPreferencesRequestPreferencesInner.ts +1 -1
  382. package/src/src/models/SetSelfApplicationTestRecipientsRequest.ts +1 -1
  383. package/src/src/models/SignInAnonymouslyRequest.ts +1 -1
  384. package/src/src/models/SignInWithGameCenterRequest.ts +1 -1
  385. package/src/src/models/SignInWithGooglePlayGamesRequest.ts +1 -1
  386. package/src/src/models/SlackMessage.ts +1 -1
  387. package/src/src/models/SlackMessageListResponse.ts +1 -1
  388. package/src/src/models/SlackMessageListResponseMeta.ts +1 -1
  389. package/src/src/models/SlackMessageResponse.ts +1 -1
  390. package/src/src/models/SlackMessageStatus.ts +1 -1
  391. package/src/src/models/SlackMessageSummary.ts +1 -1
  392. package/src/src/models/SmsBatchResultMessage.ts +1 -1
  393. package/src/src/models/SmsBatchResultSummary.ts +1 -1
  394. package/src/src/models/SmsConfig.ts +1 -1
  395. package/src/src/models/SmsConfigDeleteResponse.ts +1 -1
  396. package/src/src/models/SmsConfigDeleteResponseData.ts +1 -1
  397. package/src/src/models/SmsConfigResponse.ts +1 -1
  398. package/src/src/models/SmsDetailResponse.ts +1 -1
  399. package/src/src/models/SmsListResponse.ts +1 -1
  400. package/src/src/models/SmsMessage.ts +1 -1
  401. package/src/src/models/SmsMessageDetail.ts +1 -1
  402. package/src/src/models/SubscribePushTopicRequest.ts +1 -1
  403. package/src/src/models/Subscriber.ts +1 -1
  404. package/src/src/models/SubscriberListResponse.ts +1 -1
  405. package/src/src/models/SubscriberPreference.ts +1 -1
  406. package/src/src/models/SubscriberResponse.ts +1 -1
  407. package/src/src/models/SuccessResult.ts +1 -1
  408. package/src/src/models/SwitchOrganizationRequest.ts +1 -1
  409. package/src/src/models/SwitchOrganizationResponse.ts +1 -1
  410. package/src/src/models/SwitchOrganizationResponseData.ts +1 -1
  411. package/src/src/models/SwitchOrganizationResponseDataTokens.ts +1 -1
  412. package/src/src/models/SwitchOrganizationResponseDataUser.ts +1 -1
  413. package/src/src/models/Template.ts +1 -1
  414. package/src/src/models/TemplateListResponse.ts +1 -1
  415. package/src/src/models/TemplateRenderResponse.ts +1 -1
  416. package/src/src/models/TemplateRenderedContent.ts +1 -1
  417. package/src/src/models/TemplateResponse.ts +1 -1
  418. package/src/src/models/TestWebhookTransformRequest.ts +1 -1
  419. package/src/src/models/Topic.ts +1 -1
  420. package/src/src/models/TopicDeleteResponse.ts +1 -1
  421. package/src/src/models/TopicListResponse.ts +1 -1
  422. package/src/src/models/TopicResponse.ts +1 -1
  423. package/src/src/models/TopicStatsData.ts +1 -1
  424. package/src/src/models/TopicStatsDataTopicsBySubscriberCountInner.ts +1 -1
  425. package/src/src/models/TopicStatsResponse.ts +1 -1
  426. package/src/src/models/TopicSubscriber.ts +1 -1
  427. package/src/src/models/TopicSubscriberListResponse.ts +1 -1
  428. package/src/src/models/TopicSubscribersAddResponse.ts +1 -1
  429. package/src/src/models/TopicSubscribersAddResult.ts +1 -1
  430. package/src/src/models/TopicSubscribersRemoveResponse.ts +1 -1
  431. package/src/src/models/TopicSubscribersRemoveResult.ts +1 -1
  432. package/src/src/models/TriggerWorkflow202Response.ts +1 -1
  433. package/src/src/models/TriggerWorkflow202ResponseData.ts +1 -1
  434. package/src/src/models/TriggerWorkflowRequest.ts +1 -1
  435. package/src/src/models/UnreadCountData.ts +1 -1
  436. package/src/src/models/UnreadCountResponse.ts +1 -1
  437. package/src/src/models/Unsubscribe.ts +1 -1
  438. package/src/src/models/UnsubscribeListResponse.ts +1 -1
  439. package/src/src/models/UnsubscribeRequest.ts +1 -1
  440. package/src/src/models/UnsubscribeResponse.ts +1 -1
  441. package/src/src/models/UpdateCategoryRequest.ts +1 -1
  442. package/src/src/models/UpdateEndUserByApplicationRequest.ts +1 -1
  443. package/src/src/models/UpdateEndUserRequest.ts +1 -1
  444. package/src/src/models/UpdateOrganizationMemberRoleRequest.ts +1 -1
  445. package/src/src/models/UpdateOrganizationRequest.ts +1 -1
  446. package/src/src/models/UpdateSubscriberPreferences200Response.ts +1 -1
  447. package/src/src/models/UpdateSubscriberPreferences200ResponseData.ts +1 -1
  448. package/src/src/models/UpdateSubscriberPreferences200ResponseDataPreferencesInner.ts +1 -1
  449. package/src/src/models/UpdateSubscriberPreferencesRequest.ts +1 -1
  450. package/src/src/models/UpdateSubscriberPreferencesRequestPreferencesInner.ts +1 -1
  451. package/src/src/models/UpdateSubscriberRequest.ts +1 -1
  452. package/src/src/models/UpdateTemplateRequest.ts +1 -1
  453. package/src/src/models/UpdateTopicRequest.ts +1 -1
  454. package/src/src/models/UpdateWaaSApplicationRequest.ts +1 -1
  455. package/src/src/models/UpdateWaaSEndpoint200Response.ts +1 -1
  456. package/src/src/models/UpdateWaaSEndpointRequest.ts +1 -1
  457. package/src/src/models/UpdateWaaSEventType200Response.ts +1 -1
  458. package/src/src/models/UpdateWaaSEventTypeRequest.ts +1 -1
  459. package/src/src/models/UpdateWebhookRequest.ts +1 -1
  460. package/src/src/models/UpdateWorkflowRequest.ts +1 -1
  461. package/src/src/models/UpdateWorkflowStatusRequest.ts +1 -1
  462. package/src/src/models/UpdateWorkflowStepRequest.ts +1 -1
  463. package/src/src/models/UpsertAuthEmailTemplateRequest.ts +1 -1
  464. package/src/src/models/UpsertSmsConfigRequest.ts +1 -1
  465. package/src/src/models/UserDevicesDeleteResponse.ts +1 -1
  466. package/src/src/models/UserDevicesDeleteResponseData.ts +1 -1
  467. package/src/src/models/ValidateResetTokenRequest.ts +1 -1
  468. package/src/src/models/ValidateResetTokenResponse.ts +1 -1
  469. package/src/src/models/ValidateResetTokenResponseData.ts +1 -1
  470. package/src/src/models/VerificationStatusResponse.ts +1 -1
  471. package/src/src/models/VerificationStatusResponseData.ts +1 -1
  472. package/src/src/models/VerifyDomainResponse.ts +1 -1
  473. package/src/src/models/VerifyDomainResponseData.ts +1 -1
  474. package/src/src/models/VerifyEmailOtpLoginRequest.ts +1 -1
  475. package/src/src/models/VerifyEmailOtpRegistrationRequest.ts +1 -1
  476. package/src/src/models/VerifySmsConfigData.ts +1 -1
  477. package/src/src/models/VerifySmsConfigResponse.ts +1 -1
  478. package/src/src/models/WaaSApplication.ts +1 -1
  479. package/src/src/models/WaaSBatchPublishRequest.ts +1 -1
  480. package/src/src/models/WaaSBatchPublishResponse.ts +25 -9
  481. package/src/src/models/WaaSBatchPublishResult.ts +129 -0
  482. package/src/src/models/WaaSDelivery.ts +1 -1
  483. package/src/src/models/WaaSEndpoint.ts +1 -1
  484. package/src/src/models/WaaSEventType.ts +1 -1
  485. package/src/src/models/WaaSPortalTokenRequest.ts +1 -1
  486. package/src/src/models/WaaSPortalTokenRequestTheme.ts +1 -1
  487. package/src/src/models/WaaSPortalTokenResponse.ts +1 -1
  488. package/src/src/models/WaaSPublishEventRequest.ts +1 -1
  489. package/src/src/models/WaaSPublishEventResponse.ts +18 -2
  490. package/src/src/models/WaaSUsageResponse.ts +1 -1
  491. package/src/src/models/WebAuthnChallengeOptions.ts +1 -1
  492. package/src/src/models/WebAuthnCredential.ts +1 -1
  493. package/src/src/models/WebAuthnCredentialListResponse.ts +1 -1
  494. package/src/src/models/WebAuthnCredentialListResponseData.ts +1 -1
  495. package/src/src/models/WebAuthnCredentialResponse.ts +1 -1
  496. package/src/src/models/WebAuthnStartAuthRequest.ts +1 -1
  497. package/src/src/models/WebAuthnStartAuthResponse.ts +1 -1
  498. package/src/src/models/WebAuthnStartRegistrationRequest.ts +1 -1
  499. package/src/src/models/WebAuthnStartRegistrationResponse.ts +1 -1
  500. package/src/src/models/WebAuthnStatusResponse.ts +1 -1
  501. package/src/src/models/WebAuthnStatusResponseData.ts +1 -1
  502. package/src/src/models/WebAuthnVerifyAuthRequest.ts +1 -1
  503. package/src/src/models/WebAuthnVerifyRegistrationRequest.ts +1 -1
  504. package/src/src/models/WebAuthnVerifyRegistrationResponse.ts +1 -1
  505. package/src/src/models/WebAuthnVerifyRegistrationResponseData.ts +1 -1
  506. package/src/src/models/Webhook.ts +1 -1
  507. package/src/src/models/WebhookAccountMetricsResponse.ts +1 -1
  508. package/src/src/models/WebhookBulkRetryResponse.ts +1 -1
  509. package/src/src/models/WebhookCircuitState.ts +1 -1
  510. package/src/src/models/WebhookCircuitStateResponse.ts +1 -1
  511. package/src/src/models/WebhookCreateResponse.ts +1 -1
  512. package/src/src/models/WebhookCreateResponseData.ts +1 -1
  513. package/src/src/models/WebhookDeleteResponse.ts +1 -1
  514. package/src/src/models/WebhookDeleteResponseData.ts +1 -1
  515. package/src/src/models/WebhookDelivery.ts +1 -1
  516. package/src/src/models/WebhookDeliveryDetail.ts +1 -1
  517. package/src/src/models/WebhookDeliveryListResponse.ts +1 -1
  518. package/src/src/models/WebhookDeliveryResponse.ts +1 -1
  519. package/src/src/models/WebhookDeliveryRetryResponse.ts +1 -1
  520. package/src/src/models/WebhookDeliveryRetryResponseData.ts +1 -1
  521. package/src/src/models/WebhookEventType.ts +1 -1
  522. package/src/src/models/WebhookEventTypesResponse.ts +1 -1
  523. package/src/src/models/WebhookEventTypesResponseData.ts +1 -1
  524. package/src/src/models/WebhookIpsResponse.ts +1 -1
  525. package/src/src/models/WebhookIpsResponseData.ts +1 -1
  526. package/src/src/models/WebhookJobResponse.ts +1 -1
  527. package/src/src/models/WebhookListResponse.ts +1 -1
  528. package/src/src/models/WebhookMetricsResponse.ts +1 -1
  529. package/src/src/models/WebhookReplayResponse.ts +1 -1
  530. package/src/src/models/WebhookResponse.ts +1 -1
  531. package/src/src/models/WebhookSecretRotateResponse.ts +1 -1
  532. package/src/src/models/WebhookSecretRotateResponseData.ts +1 -1
  533. package/src/src/models/WebhookTestEventResponse.ts +1 -1
  534. package/src/src/models/WebhookTestEventResponseData.ts +1 -1
  535. package/src/src/models/WebhookTransformTestResponse.ts +1 -1
  536. package/src/src/models/WebhookUsageResponse.ts +1 -1
  537. package/src/src/models/WebhookVersion.ts +1 -1
  538. package/src/src/models/WebhookVersionsResponse.ts +1 -1
  539. package/src/src/models/WebhookVersionsResponseData.ts +1 -1
  540. package/src/src/models/WithdrawSubscriberConsentRequest.ts +1 -1
  541. package/src/src/models/Workflow.ts +1 -1
  542. package/src/src/models/WorkflowExecution.ts +1 -1
  543. package/src/src/models/WorkflowExecutionStatus.ts +1 -1
  544. package/src/src/models/WorkflowStatus.ts +1 -1
  545. package/src/src/models/WorkflowStep.ts +1 -1
  546. package/src/src/models/WorkflowStepExecution.ts +1 -1
  547. package/src/src/models/WorkflowStepExecutionStatus.ts +1 -1
  548. package/src/src/models/WorkflowStepType.ts +1 -1
  549. package/src/src/models/index.ts +1 -0
  550. package/src/src/runtime.ts +1 -1
@@ -0,0 +1,129 @@
1
+ /* tslint:disable */
2
+ /* eslint-disable */
3
+ /**
4
+ * Zyphr API
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
+ *
7
+ * The version of the OpenAPI document: 1.0.0
8
+ * Contact: support@zyphr.dev
9
+ *
10
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
11
+ * https://openapi-generator.tech
12
+ * Do not edit the class manually.
13
+ */
14
+
15
+ import { mapValues } from '../runtime';
16
+ /**
17
+ *
18
+ * @export
19
+ * @interface WaaSBatchPublishResult
20
+ */
21
+ export interface WaaSBatchPublishResult {
22
+ /**
23
+ * Set when the event was published
24
+ * @type {string}
25
+ * @memberof WaaSBatchPublishResult
26
+ */
27
+ eventId?: string;
28
+ /**
29
+ *
30
+ * @type {string}
31
+ * @memberof WaaSBatchPublishResult
32
+ */
33
+ eventType?: string;
34
+ /**
35
+ *
36
+ * @type {string}
37
+ * @memberof WaaSBatchPublishResult
38
+ */
39
+ tenantId?: string;
40
+ /**
41
+ * Set when the event was published
42
+ * @type {number}
43
+ * @memberof WaaSBatchPublishResult
44
+ */
45
+ endpointsMatched?: number;
46
+ /**
47
+ * Set when the event was published
48
+ * @type {number}
49
+ * @memberof WaaSBatchPublishResult
50
+ */
51
+ deliveriesCreated?: number;
52
+ /**
53
+ * Set when the event was published
54
+ * @type {Date}
55
+ * @memberof WaaSBatchPublishResult
56
+ */
57
+ createdAt?: Date;
58
+ /**
59
+ * True when the idempotency key matched an earlier publish
60
+ * @type {boolean}
61
+ * @memberof WaaSBatchPublishResult
62
+ */
63
+ deduplicated?: boolean;
64
+ /**
65
+ * Set when the event was not published
66
+ * @type {string}
67
+ * @memberof WaaSBatchPublishResult
68
+ */
69
+ error?: string;
70
+ /**
71
+ * Set when the event was not published, e.g. `usage_limit_exceeded` (monthly event limit reached), `event_type_not_found`, `event_type_deprecated`, `internal_error`
72
+ * @type {string}
73
+ * @memberof WaaSBatchPublishResult
74
+ */
75
+ code?: string;
76
+ }
77
+
78
+ /**
79
+ * Check if a given object implements the WaaSBatchPublishResult interface.
80
+ */
81
+ export function instanceOfWaaSBatchPublishResult(value: object): value is WaaSBatchPublishResult {
82
+ return true;
83
+ }
84
+
85
+ export function WaaSBatchPublishResultFromJSON(json: any): WaaSBatchPublishResult {
86
+ return WaaSBatchPublishResultFromJSONTyped(json, false);
87
+ }
88
+
89
+ export function WaaSBatchPublishResultFromJSONTyped(json: any, ignoreDiscriminator: boolean): WaaSBatchPublishResult {
90
+ if (json == null) {
91
+ return json;
92
+ }
93
+ return {
94
+
95
+ 'eventId': json['event_id'] == null ? undefined : json['event_id'],
96
+ 'eventType': json['event_type'] == null ? undefined : json['event_type'],
97
+ 'tenantId': json['tenant_id'] == null ? undefined : json['tenant_id'],
98
+ 'endpointsMatched': json['endpoints_matched'] == null ? undefined : json['endpoints_matched'],
99
+ 'deliveriesCreated': json['deliveries_created'] == null ? undefined : json['deliveries_created'],
100
+ 'createdAt': json['created_at'] == null ? undefined : (new Date(json['created_at'])),
101
+ 'deduplicated': json['deduplicated'] == null ? undefined : json['deduplicated'],
102
+ 'error': json['error'] == null ? undefined : json['error'],
103
+ 'code': json['code'] == null ? undefined : json['code'],
104
+ };
105
+ }
106
+
107
+ export function WaaSBatchPublishResultToJSON(json: any): WaaSBatchPublishResult {
108
+ return WaaSBatchPublishResultToJSONTyped(json, false);
109
+ }
110
+
111
+ export function WaaSBatchPublishResultToJSONTyped(value?: WaaSBatchPublishResult | null, ignoreDiscriminator: boolean = false): any {
112
+ if (value == null) {
113
+ return value;
114
+ }
115
+
116
+ return {
117
+
118
+ 'event_id': value['eventId'],
119
+ 'event_type': value['eventType'],
120
+ 'tenant_id': value['tenantId'],
121
+ 'endpoints_matched': value['endpointsMatched'],
122
+ 'deliveries_created': value['deliveriesCreated'],
123
+ 'created_at': value['createdAt'] == null ? undefined : ((value['createdAt']).toISOString()),
124
+ 'deduplicated': value['deduplicated'],
125
+ 'error': value['error'],
126
+ 'code': value['code'],
127
+ };
128
+ }
129
+
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -20,7 +20,7 @@ import { mapValues } from '../runtime';
20
20
  */
21
21
  export interface WaaSPublishEventResponse {
22
22
  /**
23
- *
23
+ * Prefixed id, not a bare UUID
24
24
  * @type {string}
25
25
  * @memberof WaaSPublishEventResponse
26
26
  */
@@ -49,6 +49,18 @@ export interface WaaSPublishEventResponse {
49
49
  * @memberof WaaSPublishEventResponse
50
50
  */
51
51
  deliveriesCreated?: number;
52
+ /**
53
+ *
54
+ * @type {Date}
55
+ * @memberof WaaSPublishEventResponse
56
+ */
57
+ createdAt?: Date;
58
+ /**
59
+ * Present and true when the idempotency key matched an earlier publish, which is returned instead of publishing again
60
+ * @type {boolean}
61
+ * @memberof WaaSPublishEventResponse
62
+ */
63
+ deduplicated?: boolean;
52
64
  }
53
65
 
54
66
  /**
@@ -73,6 +85,8 @@ export function WaaSPublishEventResponseFromJSONTyped(json: any, ignoreDiscrimin
73
85
  'tenantId': json['tenant_id'] == null ? undefined : json['tenant_id'],
74
86
  'endpointsMatched': json['endpoints_matched'] == null ? undefined : json['endpoints_matched'],
75
87
  'deliveriesCreated': json['deliveries_created'] == null ? undefined : json['deliveries_created'],
88
+ 'createdAt': json['created_at'] == null ? undefined : (new Date(json['created_at'])),
89
+ 'deduplicated': json['deduplicated'] == null ? undefined : json['deduplicated'],
76
90
  };
77
91
  }
78
92
 
@@ -92,6 +106,8 @@ export function WaaSPublishEventResponseToJSONTyped(value?: WaaSPublishEventResp
92
106
  'tenant_id': value['tenantId'],
93
107
  'endpoints_matched': value['endpointsMatched'],
94
108
  'deliveries_created': value['deliveriesCreated'],
109
+ 'created_at': value['createdAt'] == null ? undefined : ((value['createdAt']).toISOString()),
110
+ 'deduplicated': value['deduplicated'],
95
111
  };
96
112
  }
97
113
 
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev
@@ -2,7 +2,7 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * Zyphr API
5
- * 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\" } } ```
5
+ * 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. > **Test keys are being retired.** `zy_test_*` keys are no longer issued, and existing ones stop working on **21 October 2026**. They never delivered mail — sends were mocked and marked sent without reaching a provider, so they could not verify domain authentication, rendering, or deliverability. To test your integration, use a `zy_live_*` key against a verified domain and send to an address you control. ## 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\" } } ```
6
6
  *
7
7
  * The version of the OpenAPI document: 1.0.0
8
8
  * Contact: support@zyphr.dev