late-sdk 0.0.815 → 0.0.816

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 041bcf4624710e18b46bafa4fffc72ca5a6abbca5c7f558b6eba76aff7478d4c
-  data.tar.gz: 65ae0ed2304e4b20029879dc14e6ace1173fe34d51994d51977e59cd2b031f90
+  metadata.gz: 3525f01a2062dc2131d0647fdcc7562a2774796b17c10d53066211d8b552a953
+  data.tar.gz: 3e9107679f37470121ddbd7b81ae7daf90a200f608ac0f33d0e662908db87a54
 SHA512:
-  metadata.gz: d81c5be5ef439bcf522d41566a5d16e1656a8d0ec15b2289bb125f1ce89a44a7aac9e00ae3ffa5e649cfe241ad43b5ff80ed478cfc06269e3aa6112d6a1a9e6a
-  data.tar.gz: 73b2bbca6f986fbd45c2dc3fda4071c5563357e1185f6f654b5b5c0d7888d10b7fa23f30bed63b8e37090bc11c7d46a1fc985d61aeefa76fee73000b53696d8f
+  metadata.gz: e99fdffbd77b99c0a73bbb49050510b21195597e76137daad38700e7b1fb29056ee1849c21dab534a845cff16af5c7826dce3c1ea04a19bbefe7043c6c2f64c9
+  data.tar.gz: 6f38e29b952c553f6f6272bcc53424591a32599d8ff7566cafd10e6c18d4f106183143b4dc7a30dfbdd0a15b064d169521b628afca0d4141bf4b702f69b69dc2

data/docs/WebhooksApi.md

@@ -304,7 +304,7 @@ This endpoint does not need any parameter.
 
 Redeliver a webhook event
 
-Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 500. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
+Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 422. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
 
 ### Examples
 

data/lib/zernio-sdk/api/webhooks_api.rb

@@ -333,7 +333,7 @@ module Zernio
     end
 
     # Redeliver a webhook event
-    # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 500. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
+    # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 422. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
     # @param redeliver_webhook_event_request [RedeliverWebhookEventRequest] 
     # @param [Hash] opts the optional parameters
     # @return [UnpublishPost200Response]
@@ -343,7 +343,7 @@ module Zernio
     end
 
     # Redeliver a webhook event
-    # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 500. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
+    # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 422. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
     # @param redeliver_webhook_event_request [RedeliverWebhookEventRequest] 
     # @param [Hash] opts the optional parameters
     # @return [Array<(UnpublishPost200Response, Integer, Hash)>] UnpublishPost200Response data, response status code and response headers

data/lib/zernio-sdk/models/update_ad_request_creative.rb

@@ -14,7 +14,7 @@ require 'date'
 require 'time'
 
 module Zernio
-  # Replace or patch the ad's creative. Meta, TikTok, and LinkedIn.  - **Meta**: patch-style. Pass any subset — fields you omit are preserved from the   live creative, including media (`image_hash`/`video_id` are reused, no re-upload)   and `url_tags`. Sending the full set (`headline`, `body`, `callToAction`,   `linkUrl`, `imageUrl`) rebuilds the creative from scratch instead. Partial   patching reads the live `object_story_spec`, which Meta strips on SHARE /   page-post / dark / asset_feed creatives — those return 422 asking for the full   set. A `videoUrl`/`videoId` on an image creative is a type change and also   needs the full set. `existingCreativeId` repoints the ad at a creative from   GET /v1/ads/creatives and ignores every other field. Meta creatives are   immutable, so any change creates a new creative and repoints the ad; the old   creative is retained on the ad account for historical reporting. - **TikTok**: patch-style. Pass any subset; `headline` is ignored (TikTok creatives   have no headline slot). `body` becomes the in-feed `ad_text`; `linkUrl` becomes   `landing_page_url`; `videoUrl` triggers a fresh upload. `description`, `videoId`   and `existingCreativeId` are Meta-only and return 400. - **LinkedIn**: uploads new media (image via `imageUrl` or video via `videoUrl`),   creates a new inline media creative on the same campaign, and pauses the old   creative (best-effort). The old creative is retained for historical reporting.   `videoId` and `existingCreativeId` are Meta-only and return 400. 
+  # Replace or patch the ad's creative. Meta, TikTok, and LinkedIn.  - **Meta**: patch-style. Pass any subset — fields you omit are preserved from the   live creative, including media (`image_hash`/`video_id` are reused, no re-upload)   and `url_tags`. Sending the full set (`headline`, `body`, `callToAction`,   `linkUrl`, `imageUrl`) rebuilds the creative from scratch instead. Partial   patching reads the live `object_story_spec`, which Meta strips on SHARE /   page-post / dark / asset_feed creatives — those return 422 asking for the full   set. A `videoUrl`/`videoId` on an image creative is a type change and also   needs the full set. `existingCreativeId` repoints the ad at a creative from   GET /v1/ads/creatives and ignores every other field. Meta creatives are   immutable, so any change creates a new creative and repoints the ad; the old   creative is retained on the ad account for historical reporting. - **TikTok**: patch-style. Pass any subset; `headline` is ignored (TikTok creatives   have no headline slot). `body` becomes the in-feed `ad_text`; `linkUrl` becomes   `landing_page_url`; `videoUrl` triggers a fresh upload. `description`, `videoId`   and `existingCreativeId` are Meta-only and return 400. - **LinkedIn**: requires new media (image via `imageUrl` or video via `videoUrl`);   a text-only creative update returns 400. Uploads the media, creates a new inline   media creative on the same campaign, and pauses the old creative (best-effort).   The old creative is retained for historical reporting. `videoId` and   `existingCreativeId` are Meta-only and return 400. 
   class UpdateAdRequestCreative < ApiModelBase
     # Meta and LinkedIn (TikTok has no headline slot)
     attr_accessor :headline

data/lib/zernio-sdk/version.rb

@@ -11,5 +11,5 @@ Generator version: 7.19.0
 =end
 
 module Zernio
-  VERSION = '0.0.815'
+  VERSION = '0.0.816'
 end

data/openapi.yaml

@@ -25697,7 +25697,7 @@ paths:
         emitted, not the current state of the resource.
 
         Only deliveries inside the 30-day log retention window can be replayed; past that
-        the payload is gone and the request fails with a 500. Replays run the same
+        the payload is gone and the request fails with a 422. Replays run the same
         resource-group checks as live delivery, against both the key's groups and the
         subscription's `disabledResourceGroups`.
       security:
@@ -25736,10 +25736,11 @@ paths:
               example:
                 success: true
                 message: "Webhook re-delivered"
-        '400': { description: 'webhookId or eventId missing or empty' }
+        '400': { description: 'webhookId or eventId missing or empty, or the subscription has no URL configured' }
         '401': { $ref: '#/components/responses/Unauthorized' }
         '403': { $ref: '#/components/responses/ResourceGroupForbidden' }
-        '500': { description: 'Webhook no longer exists, has no URL configured, or the original payload is outside the 30-day retention window' }
+        '404': { description: 'Webhook subscription not found' }
+        '422': { description: 'Original payload not replayable: no delivery matches this event inside the 30-day retention window, or the stored payload is truncated or not valid JSON' }
         '502':
           description: |
             Re-delivery was attempted but your endpoint errored again. The attempt is still
@@ -41662,10 +41663,11 @@ paths:
                       have no headline slot). `body` becomes the in-feed `ad_text`; `linkUrl` becomes
                       `landing_page_url`; `videoUrl` triggers a fresh upload. `description`, `videoId`
                       and `existingCreativeId` are Meta-only and return 400.
-                    - **LinkedIn**: uploads new media (image via `imageUrl` or video via `videoUrl`),
-                      creates a new inline media creative on the same campaign, and pauses the old
-                      creative (best-effort). The old creative is retained for historical reporting.
-                      `videoId` and `existingCreativeId` are Meta-only and return 400.
+                    - **LinkedIn**: requires new media (image via `imageUrl` or video via `videoUrl`);
+                      a text-only creative update returns 400. Uploads the media, creates a new inline
+                      media creative on the same campaign, and pauses the old creative (best-effort).
+                      The old creative is retained for historical reporting. `videoId` and
+                      `existingCreativeId` are Meta-only and return 400.
                   properties:
                     headline: { type: string, description: "Meta and LinkedIn (TikTok has no headline slot)" }
                     body: { type: string }
@@ -41688,7 +41690,7 @@ paths:
                   ad: { $ref: '#/components/schemas/Ad' }
                   message: { type: string }
         '400':
-          description: Invalid status transition or budget below minimum
+          description: 'Invalid status transition, budget below minimum, or a LinkedIn creative update without imageUrl or videoUrl'
         '401': { $ref: '#/components/responses/Unauthorized' }
         '404': { $ref: '#/components/responses/NotFound' }
         '501': { description: "targeting or creative not supported on the platform (supported on Meta, TikTok, and LinkedIn)" }

data/spec/api/webhooks_api_spec.rb

@@ -86,7 +86,7 @@ describe 'WebhooksApi' do
 
   # unit tests for redeliver_webhook_event
   # Redeliver a webhook event
-  # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 500. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
+  # Replay a past delivery: the original payload is re-sent, byte for byte, to the subscription's current URL. The original event ID is preserved so your endpoint can dedupe, and the replay is recorded as a fresh attempt, so it shows up in `GET /v1/webhooks/logs` next to the delivery it replays.  Both `webhookId` and `eventId` come from a row of `GET /v1/webhooks/logs`. Because the stored payload is replayed as-is, a redelivery reflects the event as it was emitted, not the current state of the resource.  Only deliveries inside the 30-day log retention window can be replayed; past that the payload is gone and the request fails with a 422. Replays run the same resource-group checks as live delivery, against both the key's groups and the subscription's `disabledResourceGroups`. 
   # @param redeliver_webhook_event_request 
   # @param [Hash] opts the optional parameters
   # @return [UnpublishPost200Response]

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: late-sdk
 version: !ruby/object:Gem::Version
-  version: 0.0.815
+  version: 0.0.816
 platform: ruby
 authors:
 - OpenAPI-Generator
@@ -5557,7 +5557,7 @@ files:
 - spec/models/you_tube_video_retention_response_retention_curve_inner_spec.rb
 - spec/models/you_tube_video_retention_response_spec.rb
 - spec/spec_helper.rb
-- zernio-sdk-0.0.815.gem
+- zernio-sdk-0.0.816.gem
 - zernio-sdk.gemspec
 homepage: https://openapi-generator.tech
 licenses: