zyphr 0.1.36 → 0.1.38

data/lib/zyphr/api/auth_registration_api.rb

@@ -1,7 +1,7 @@
 =begin
 #Zyphr API
 
-#Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
+#Zyphr is a multi-channel notification platform that enables developers to send emails, push notifications, SMS, and in-app messages through a unified API.  ## Authentication  All API requests require authentication using an API key. Include your API key in the `X-API-Key` header:  ``` X-API-Key: zy_live_xxxxxxxxxxxx ```  API keys can be created in the Zyphr Dashboard. Use `zy_test_*` keys for testing and `zy_live_*` keys for production.  ## Rate Limiting  The API implements rate limiting to ensure fair usage. Rate limit information is included in response headers:  - `X-RateLimit-Limit`: Maximum requests per window - `X-RateLimit-Remaining`: Remaining requests in current window - `X-RateLimit-Reset`: Unix timestamp when the window resets  ## Account Sending Status  Every authenticated response carries the account's current sending state so you can surface it in your own tooling without a separate call:  - `X-Account-Sending-Status`: `active`, `throttled`, or `frozen` - `X-Account-Sending-Status-Reason`: human-readable reason (present only when the status is `throttled` or `frozen`)  This header is informational and non-blocking on non-send endpoints (reads, billing, and deliverability stay available). Send-capable endpoints additionally enforce the state: a frozen account receives `403 account_frozen` and a throttled account receives `429 account_throttled`, both with the reason in the error message.  ## Errors  All errors follow a consistent format:  ```json {   \"error\": {     \"code\": \"error_code\",     \"message\": \"Human readable message\",     \"details\": {}   },   \"meta\": {     \"request_id\": \"req_xxxx\"   } } ```
 
 The version of the OpenAPI document: 1.0.0
 Contact: support@zyphr.dev
@@ -156,7 +156,7 @@ module Zyphr
     end
 
     # Sign in anonymously
-    # Issue an end-user identity to a device without email, password, OAuth, or any other credential. Idempotent per (application, environment, device_id): repeated calls with the same device_id return the same user but a fresh token pair. Prior sessions for the user remain valid until natural expiry.  Anonymous users do not count toward MAU quota until their first authenticated request after sign-in (excluding /v1/auth/refresh).  Convert an anonymous user to a full account via POST /v1/auth/users/convert. 
+    # Issue an end-user identity to a device without email, password, OAuth, or any other credential. Idempotent per (application, environment, device_id): repeated calls with the same device_id return the same user but a fresh token pair. Prior sessions for the user remain valid until natural expiry.  Anonymous users do not count toward MAU quota until their first authenticated request after sign-in (excluding /v1/auth/refresh).  Convert an anonymous user to a full account via POST /v1/auth/users/convert.  Pass an optional `organization_id` to create the anonymous user directly in an organization; the returned access token then carries `org_id` (and `orgs`), matching the org-scoped register/login flow. 
     # @param sign_in_anonymously_request [SignInAnonymouslyRequest] 
     # @param [Hash] opts the optional parameters
     # @return [AuthResultResponse]
@@ -166,7 +166,7 @@ module Zyphr
     end
 
     # Sign in anonymously
-    # Issue an end-user identity to a device without email, password, OAuth, or any other credential. Idempotent per (application, environment, device_id): repeated calls with the same device_id return the same user but a fresh token pair. Prior sessions for the user remain valid until natural expiry.  Anonymous users do not count toward MAU quota until their first authenticated request after sign-in (excluding /v1/auth/refresh).  Convert an anonymous user to a full account via POST /v1/auth/users/convert. 
+    # Issue an end-user identity to a device without email, password, OAuth, or any other credential. Idempotent per (application, environment, device_id): repeated calls with the same device_id return the same user but a fresh token pair. Prior sessions for the user remain valid until natural expiry.  Anonymous users do not count toward MAU quota until their first authenticated request after sign-in (excluding /v1/auth/refresh).  Convert an anonymous user to a full account via POST /v1/auth/users/convert.  Pass an optional `organization_id` to create the anonymous user directly in an organization; the returned access token then carries `org_id` (and `orgs`), matching the org-scoped register/login flow. 
     # @param sign_in_anonymously_request [SignInAnonymouslyRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(AuthResultResponse, Integer, Hash)>] AuthResultResponse data, response status code and response headers
@@ -222,5 +222,73 @@ module Zyphr
       end
       return data, status_code, headers
     end
+
+    # Sign in with Apple Game Center
+    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped `playerId` (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit's `GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)`, which returns `publicKeyURL`, `signature`, `salt`, and `timestamp`; combine those with the local player's `gamePlayerID` and the app's bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer's own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque `401` `invalid_assertion` — the specific control that failed is never disclosed. 
+    # @param sign_in_with_game_center_request [SignInWithGameCenterRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [AuthResultResponse]
+    def sign_in_with_game_center(sign_in_with_game_center_request, opts = {})
+      data, _status_code, _headers = sign_in_with_game_center_with_http_info(sign_in_with_game_center_request, opts)
+      data
+    end
+
+    # Sign in with Apple Game Center
+    # Exchange an Apple Game Center identity-verification assertion for a Zyphr end-user session. Zyphr independently re-verifies the assertion server-side (Apple certificate chain, RSA-SHA256 signature, timestamp freshness, single-use replay guard, and bundle-id binding) before provisioning-or-looking-up the user and minting tokens. The user is keyed on the modern scoped &#x60;playerId&#x60; (gamePlayerID).  ## Producing the assertion (Integration)  The assertion is produced **on-device by the iOS app** — there is no server-side way to mint it. The app calls GameKit&#39;s &#x60;GKLocalPlayer.fetchItems(forIdentityVerificationSignature:)&#x60;, which returns &#x60;publicKeyURL&#x60;, &#x60;signature&#x60;, &#x60;salt&#x60;, and &#x60;timestamp&#x60;; combine those with the local player&#39;s &#x60;gamePlayerID&#x60; and the app&#39;s bundle identifier and submit them here.  Two integration shapes are supported:   - **client-direct** — the iOS app holds the Zyphr application public     key and calls this endpoint itself.   - **backend-relayed** — the app forwards the fetched assertion fields     to the customer&#39;s own backend, which relays them to this endpoint;     the app never holds Zyphr keys. (This is the common shape for games.)  On any verification failure the response is a single opaque &#x60;401&#x60; &#x60;invalid_assertion&#x60; — the specific control that failed is never disclosed. 
+    # @param sign_in_with_game_center_request [SignInWithGameCenterRequest] 
+    # @param [Hash] opts the optional parameters
+    # @return [Array<(AuthResultResponse, Integer, Hash)>] AuthResultResponse data, response status code and response headers
+    def sign_in_with_game_center_with_http_info(sign_in_with_game_center_request, opts = {})
+      if @api_client.config.debugging
+        @api_client.config.logger.debug 'Calling API: AuthRegistrationApi.sign_in_with_game_center ...'
+      end
+      # verify the required parameter 'sign_in_with_game_center_request' is set
+      if @api_client.config.client_side_validation && sign_in_with_game_center_request.nil?
+        fail ArgumentError, "Missing the required parameter 'sign_in_with_game_center_request' when calling AuthRegistrationApi.sign_in_with_game_center"
+      end
+      # resource path
+      local_var_path = '/auth/game-center'
+
+      # query parameters
+      query_params = opts[:query_params] || {}
+
+      # header parameters
+      header_params = opts[:header_params] || {}
+      # HTTP header 'Accept' (if needed)
+      header_params['Accept'] = @api_client.select_header_accept(['application/json']) unless header_params['Accept']
+      # HTTP header 'Content-Type'
+      content_type = @api_client.select_header_content_type(['application/json'])
+      if !content_type.nil?
+          header_params['Content-Type'] = content_type
+      end
+
+      # form parameters
+      form_params = opts[:form_params] || {}
+
+      # http body (model)
+      post_body = opts[:debug_body] || @api_client.object_to_http_body(sign_in_with_game_center_request)
+
+      # return_type
+      return_type = opts[:debug_return_type] || 'AuthResultResponse'
+
+      # auth_names
+      auth_names = opts[:debug_auth_names] || ['ApplicationPublicKey']
+
+      new_options = opts.merge(
+        :operation => :"AuthRegistrationApi.sign_in_with_game_center",
+        :header_params => header_params,
+        :query_params => query_params,
+        :form_params => form_params,
+        :body => post_body,
+        :auth_names => auth_names,
+        :return_type => return_type
+      )
+
+      data, status_code, headers = @api_client.call_api(:POST, local_var_path, new_options)
+      if @api_client.config.debugging
+        @api_client.config.logger.debug "API called: AuthRegistrationApi#sign_in_with_game_center\nData: #{data.inspect}\nStatus code: #{status_code}\nHeaders: #{headers}"
+      end
+      return data, status_code, headers
+    end
   end
 end

data/lib/zyphr/api/auth_sessions_api.rb

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