@adcp/sdk 6.6.0 → 6.8.0

package/dist/lib/schemas-data/3.0/bundled/media-buy/get-products-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/get-products-response.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/get-products-response.json",
   "title": "Get Products Response",
   "description": "Response payload for get_products task",
   "type": "object",
@@ -6384,7 +6384,7 @@
           },
           "field": {
             "type": "string",
-            "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+            "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
           },
           "suggestion": {
             "type": "string",
@@ -6396,9 +6396,40 @@
             "minimum": 1,
             "maximum": 3600
           },
+          "issues": {
+            "type": "array",
+            "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+            "items": {
+              "type": "object",
+              "properties": {
+                "pointer": {
+                  "type": "string",
+                  "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                },
+                "message": {
+                  "type": "string",
+                  "description": "Human-readable description of why this specific field was rejected."
+                },
+                "keyword": {
+                  "type": "string",
+                  "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                },
+                "schemaPath": {
+                  "type": "string",
+                  "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                }
+              },
+              "required": [
+                "pointer",
+                "message",
+                "keyword"
+              ],
+              "additionalProperties": true
+            }
+          },
           "details": {
             "type": "object",
-            "description": "Additional task-specific error details",
+            "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
             "additionalProperties": true
           },
           "recovery": {
@@ -6803,7 +6834,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:22.995Z",
+    "generatedAt": "2026-05-02T21:51:30.442Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/list-creative-formats-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/list-creative-formats-request.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/list-creative-formats-request.json",
   "title": "List Creative Formats Request",
   "description": "Request parameters for discovering supported creative formats",
   "type": "object",
@@ -305,7 +305,7 @@
   },
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:22.997Z",
+    "generatedAt": "2026-05-02T21:51:30.444Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/list-creative-formats-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/list-creative-formats-response.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/list-creative-formats-response.json",
   "title": "List Creative Formats Response",
   "description": "Response payload for list_creative_formats task",
   "type": "object",
@@ -952,7 +952,7 @@
                             "viewability_tracker",
                             "third_party_tracker"
                           ],
-                          "description": "Standard role for this URL asset. Use this to constrain which purposes are valid for this URL slot. Complements asset_role (which is a human-readable label) by providing a machine-readable enum."
+                          "description": "Purpose this URL slot serves in the format — distinct from `url_type` on the manifest-side asset (which declares the receiver's invocation mechanism). A slot can be `click_tracker` (purpose) and accept a `tracker_pixel` (mechanism) URL, or `clickthrough` (purpose) and accept a `clickthrough` (mechanism) URL. Complements `asset_role` (human-readable label) by providing a machine-readable enum and serves as the receiver's fallback signal when a manifest URL asset omits `url_type`."
                         },
                         "protocols": {
                           "type": "array",
@@ -1742,7 +1742,7 @@
                                           "viewability_tracker",
                                           "third_party_tracker"
                                         ],
-                                        "description": "Standard role for this URL asset. Use this to constrain which purposes are valid for this URL slot. Complements asset_role (which is a human-readable label) by providing a machine-readable enum."
+                                        "description": "Purpose this URL slot serves in the format — distinct from `url_type` on the manifest-side asset (which declares the receiver's invocation mechanism). A slot can be `click_tracker` (purpose) and accept a `tracker_pixel` (mechanism) URL, or `clickthrough` (purpose) and accept a `clickthrough` (mechanism) URL. Complements `asset_role` (human-readable label) by providing a machine-readable enum and serves as the receiver's fallback signal when a manifest URL asset omits `url_type`."
                                       },
                                       "protocols": {
                                         "type": "array",
@@ -2727,7 +2727,7 @@
                                       "viewability_tracker",
                                       "third_party_tracker"
                                     ],
-                                    "description": "Standard role for this URL asset. Use this to constrain which purposes are valid for this URL slot. Complements asset_role (which is a human-readable label) by providing a machine-readable enum."
+                                    "description": "Purpose this URL slot serves in the format — distinct from `url_type` on the manifest-side asset (which declares the receiver's invocation mechanism). A slot can be `click_tracker` (purpose) and accept a `tracker_pixel` (mechanism) URL, or `clickthrough` (purpose) and accept a `clickthrough` (mechanism) URL. Complements `asset_role` (human-readable label) by providing a machine-readable enum and serves as the receiver's fallback signal when a manifest URL asset omits `url_type`."
                                   },
                                   "protocols": {
                                     "type": "array",
@@ -3606,7 +3606,7 @@
           },
           "field": {
             "type": "string",
-            "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+            "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
           },
           "suggestion": {
             "type": "string",
@@ -3618,9 +3618,40 @@
             "minimum": 1,
             "maximum": 3600
           },
+          "issues": {
+            "type": "array",
+            "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+            "items": {
+              "type": "object",
+              "properties": {
+                "pointer": {
+                  "type": "string",
+                  "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                },
+                "message": {
+                  "type": "string",
+                  "description": "Human-readable description of why this specific field was rejected."
+                },
+                "keyword": {
+                  "type": "string",
+                  "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                },
+                "schemaPath": {
+                  "type": "string",
+                  "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                }
+              },
+              "required": [
+                "pointer",
+                "message",
+                "keyword"
+              ],
+              "additionalProperties": true
+            }
+          },
           "details": {
             "type": "object",
-            "description": "Additional task-specific error details",
+            "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
             "additionalProperties": true
           },
           "recovery": {
@@ -4074,7 +4105,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.000Z",
+    "generatedAt": "2026-05-02T21:51:30.448Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/log-event-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/log-event-request.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/log-event-request.json",
   "title": "Log Event Request",
   "description": "Request parameters for logging marketing events",
   "x-mutates-state": true,
@@ -388,7 +388,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.002Z",
+    "generatedAt": "2026-05-02T21:51:30.450Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/log-event-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/log-event-response.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/log-event-response.json",
   "title": "Log Event Response",
   "description": "Response from event logging operation. Returns either event processing results OR operation-level errors.",
   "type": "object",
@@ -113,7 +113,7 @@
               },
               "field": {
                 "type": "string",
-                "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+                "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
               },
               "suggestion": {
                 "type": "string",
@@ -125,9 +125,40 @@
                 "minimum": 1,
                 "maximum": 3600
               },
+              "issues": {
+                "type": "array",
+                "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+                "items": {
+                  "type": "object",
+                  "properties": {
+                    "pointer": {
+                      "type": "string",
+                      "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                    },
+                    "message": {
+                      "type": "string",
+                      "description": "Human-readable description of why this specific field was rejected."
+                    },
+                    "keyword": {
+                      "type": "string",
+                      "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                    },
+                    "schemaPath": {
+                      "type": "string",
+                      "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                    }
+                  },
+                  "required": [
+                    "pointer",
+                    "message",
+                    "keyword"
+                  ],
+                  "additionalProperties": true
+                }
+              },
               "details": {
                 "type": "object",
-                "description": "Additional task-specific error details",
+                "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
                 "additionalProperties": true
               },
               "recovery": {
@@ -187,7 +218,7 @@
     }
   ],
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.002Z",
+    "generatedAt": "2026-05-02T21:51:30.450Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/package-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/package-request.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/package-request.json",
   "title": "Package Request",
   "description": "Package configuration for media buy creation",
   "type": "object",
@@ -2038,6 +2038,8 @@
             "description": "Assets required by the format, keyed by asset_id. Each asset value carries an `asset_type` discriminator that selects the matching asset schema.",
             "patternProperties": {
               "^[a-z0-9_]+$": {
+                "title": "AssetVariant",
+                "description": "Canonical union of all asset variant schemas. Referenced from creative-asset.json and creative-manifest.json to ensure a single named type is emitted by schema-to-TypeScript tooling. Add new asset types here and to the creative/asset-types registry.",
                 "oneOf": [
                   {
                     "title": "Image Asset",
@@ -3708,7 +3710,8 @@
                   },
                   {
                     "title": "URL Asset",
-                    "description": "URL reference asset",
+                    "$comment": "Fallback table is also rendered in docs/creative/asset-types.mdx (URL Asset section). Keep the two in sync — schema description is the normative source for conformance tools; mdx is the human-readable copy.",
+                    "description": "URL reference asset. `url_type` declares the mechanism a receiver uses to invoke the URL (clickthrough vs. tracker_pixel vs. tracker_script) and is distinct from the URL's purpose, which the format declares in `url-asset-requirements.role` (clickthrough, landing_page, impression_tracker, click_tracker, viewability_tracker, third_party_tracker). Senders SHOULD include `url_type` on every URL asset. When `url_type` is absent, receivers SHOULD fall back to the format's `url-asset-requirements.role` per this mapping: clickthrough/landing_page → `clickthrough`; impression_tracker/click_tracker → `tracker_pixel`; viewability_tracker → `tracker_script` (OMID and equivalent verification SDKs require a <script> tag — firing them as a pixel produces no measurement); third_party_tracker → no safe fallback (mechanism is integration-specific — DV/IAS ship both pixel and script forms — receivers MAY reject or warn). When neither `url_type` nor a format-side `role` is available, receivers MUST NOT silently pick a mechanism; they SHOULD reject the manifest. Note: VAST/DAAST tag URLs are not URL assets — use `asset_type: \"vast\"` (or the dedicated tracker types pending RFC #2915), not `asset_type: \"url\"` with a tracker_pixel mechanism.",
                     "type": "object",
                     "properties": {
                       "asset_type": {
@@ -3723,7 +3726,7 @@
                       },
                       "url_type": {
                         "title": "URL Asset Type",
-                        "description": "Type of URL asset: 'clickthrough' for user click destination (landing page), 'tracker_pixel' for impression/event tracking via HTTP request (fires GET, expects pixel/204 response), 'tracker_script' for measurement SDKs that must load as <script> tag (OMID verification, native event trackers using method:2)",
+                        "description": "Mechanism a receiver uses to invoke this URL (distinct from purpose, which lives in `url-asset-requirements.role`): `clickthrough` for user click destination (landing page), `tracker_pixel` for impression/event tracking via HTTP request (fires GET, expects pixel/204 response), `tracker_script` for measurement SDKs that must load as a <script> tag (OMID verification, native event trackers using method:2). SHOULD be present on every URL asset; senders that omit it force the receiver into the role-based fallback described in this schema's top-level description.",
                         "type": "string",
                         "enum": [
                           "clickthrough",
@@ -6917,7 +6920,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.009Z",
+    "generatedAt": "2026-05-02T21:51:30.457Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/provide-performance-feedback-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/provide-performance-feedback-request.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/provide-performance-feedback-request.json",
   "title": "Provide Performance Feedback Request",
   "description": "Request payload for provide_performance_feedback task",
   "x-mutates-state": true,
@@ -113,7 +113,7 @@
   ],
   "additionalProperties": true,
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.011Z",
+    "generatedAt": "2026-05-02T21:51:30.460Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/provide-performance-feedback-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/provide-performance-feedback-response.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/provide-performance-feedback-response.json",
   "title": "Provide Performance Feedback Response",
   "description": "Response payload for provide_performance_feedback task. Returns either success confirmation OR error information, never both.",
   "type": "object",
@@ -67,7 +67,7 @@
               },
               "field": {
                 "type": "string",
-                "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+                "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
               },
               "suggestion": {
                 "type": "string",
@@ -79,9 +79,40 @@
                 "minimum": 1,
                 "maximum": 3600
               },
+              "issues": {
+                "type": "array",
+                "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+                "items": {
+                  "type": "object",
+                  "properties": {
+                    "pointer": {
+                      "type": "string",
+                      "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                    },
+                    "message": {
+                      "type": "string",
+                      "description": "Human-readable description of why this specific field was rejected."
+                    },
+                    "keyword": {
+                      "type": "string",
+                      "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                    },
+                    "schemaPath": {
+                      "type": "string",
+                      "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                    }
+                  },
+                  "required": [
+                    "pointer",
+                    "message",
+                    "keyword"
+                  ],
+                  "additionalProperties": true
+                }
+              },
               "details": {
                 "type": "object",
-                "description": "Additional task-specific error details",
+                "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
                 "additionalProperties": true
               },
               "recovery": {
@@ -136,7 +167,7 @@
     }
   ],
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.011Z",
+    "generatedAt": "2026-05-02T21:51:30.461Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/sync-audiences-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/sync-audiences-request.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/sync-audiences-request.json",
   "title": "Sync Audiences Request",
   "description": "Request parameters for managing CRM-based audiences on an account with upsert semantics. Existing audiences matched by audience_id are updated, new ones are created. Members are specified as delta operations: add appends new members, remove drops existing ones. Recommend no more than 100,000 members per call; for larger lists, chunk and call incrementally using add/remove deltas. When delete_missing is true, buyer-managed audiences on the account not in this request are removed — do not combine with omitted audiences or all buyer-managed audiences will be deleted. When audiences is omitted, the call is discovery-only: it returns all audiences on the account without modification.",
   "x-mutates-state": true,
@@ -448,7 +448,7 @@
     }
   },
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.011Z",
+    "generatedAt": "2026-05-02T21:51:30.462Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/sync-audiences-response.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/sync-audiences-response.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/sync-audiences-response.json",
   "title": "Sync Audiences Response",
   "description": "Response from audience sync operation. Returns either per-audience results OR operation-level errors.",
   "type": "object",
@@ -166,7 +166,7 @@
                     },
                     "field": {
                       "type": "string",
-                      "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+                      "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
                     },
                     "suggestion": {
                       "type": "string",
@@ -178,9 +178,40 @@
                       "minimum": 1,
                       "maximum": 3600
                     },
+                    "issues": {
+                      "type": "array",
+                      "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+                      "items": {
+                        "type": "object",
+                        "properties": {
+                          "pointer": {
+                            "type": "string",
+                            "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                          },
+                          "message": {
+                            "type": "string",
+                            "description": "Human-readable description of why this specific field was rejected."
+                          },
+                          "keyword": {
+                            "type": "string",
+                            "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                          },
+                          "schemaPath": {
+                            "type": "string",
+                            "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                          }
+                        },
+                        "required": [
+                          "pointer",
+                          "message",
+                          "keyword"
+                        ],
+                        "additionalProperties": true
+                      }
+                    },
                     "details": {
                       "type": "object",
-                      "description": "Additional task-specific error details",
+                      "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
                       "additionalProperties": true
                     },
                     "recovery": {
@@ -260,7 +291,7 @@
               },
               "field": {
                 "type": "string",
-                "description": "Field path associated with the error (e.g., 'packages[0].targeting')"
+                "description": "Field path associated with the error in JSONPath-lite format (e.g., 'packages[0].targeting'). When `issues[]` is also present, sellers MUST set this to `issues[0].pointer` translated from RFC 6901 to JSONPath-lite (e.g., '/packages/0/targeting' → 'packages[0].targeting') so pre-3.1 consumers reading `field` only get deterministic behavior. Will be deprecated in a future major version in favor of `issues[].pointer`."
               },
               "suggestion": {
                 "type": "string",
@@ -272,9 +303,40 @@
                 "minimum": 1,
                 "maximum": 3600
               },
+              "issues": {
+                "type": "array",
+                "description": "Structured list of validation failures. Primary use is `VALIDATION_ERROR`, where multi-field rejections are common and `field` (singular) cannot carry the full pointer map. MAY appear on other error codes that reject multiple fields at once. When `issues` is present, sellers MUST also populate `field` from `issues[0]` for backward compatibility with pre-3.1 consumers that read `field` only — translating the RFC 6901 `pointer` format to the JSONPath-lite format `field` uses (e.g., `/packages/0/targeting` → `packages[0].targeting`). MUST (not SHOULD) so consumers reading `field` get deterministic behavior across sellers — the cost is one line of dual-write per seller; the cost of SHOULD is a long tail of seller-A-vs-seller-B inconsistency. Future major versions will deprecate `field` in favor of `issues[].pointer`.",
+                "items": {
+                  "type": "object",
+                  "properties": {
+                    "pointer": {
+                      "type": "string",
+                      "description": "RFC 6901 JSON Pointer to the offending field in the request payload (e.g., '/packages/0/targeting/geo_countries/2'). Format chosen to match Ajv's native validation output (`instancePath`); standardized and unambiguous on keys containing `/` or `~`. NOTE: this differs from the legacy top-level `field` which uses JSONPath-lite (`packages[0].targeting.geo_countries[2]`). When sellers populate `field` from `issues[0].pointer` for backward compatibility (see `field` description), they MUST translate the format — `/packages/0/x` → `packages[0].x`. Future major versions will deprecate `field` in favor of `issues[].pointer`."
+                    },
+                    "message": {
+                      "type": "string",
+                      "description": "Human-readable description of why this specific field was rejected."
+                    },
+                    "keyword": {
+                      "type": "string",
+                      "description": "Schema keyword that rejected the payload, drawn from the JSON Schema vocabulary (e.g., 'required', 'type', 'format', 'enum', 'pattern', 'minimum', 'maxLength'). Matches the keyword names emitted by JSON Schema validators (Ajv, jsonschema, etc.) so agents can pattern-match on rejection class without parsing message text. Implementers SHOULD use the validator's native keyword name; do not invent custom values here."
+                    },
+                    "schemaPath": {
+                      "type": "string",
+                      "description": "Optional. Path inside the schema that rejected the payload (e.g., '#/properties/packages/items/properties/targeting/oneOf/1'). Sellers SHOULD NOT emit on production-facing endpoints — `schemaPath` leaks which `oneOf` branch the validator selected before semantic rejection, which is a probe oracle for adversarial callers crafting payloads against polymorphic unions. Sellers MAY emit in dev/sandbox modes where the diagnostic value outweighs the fingerprinting risk."
+                    }
+                  },
+                  "required": [
+                    "pointer",
+                    "message",
+                    "keyword"
+                  ],
+                  "additionalProperties": true
+                }
+              },
               "details": {
                 "type": "object",
-                "description": "Additional task-specific error details",
+                "description": "Additional task-specific error details. Sellers MAY mirror `issues[]` here as `details.issues` for backward compatibility with pre-3.1 consumers reading from `details`; new consumers SHOULD prefer the top-level `issues` field.",
                 "additionalProperties": true
               },
               "recovery": {
@@ -329,7 +391,7 @@
     }
   ],
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.012Z",
+    "generatedAt": "2026-05-02T21:51:30.462Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }

package/dist/lib/schemas-data/3.0/bundled/media-buy/sync-catalogs-request.json

@@ -1,6 +1,6 @@
 {
   "$schema": "http://json-schema.org/draft-07/schema#",
-  "$id": "/schemas/3.0.1/bundled/media-buy/sync-catalogs-request.json",
+  "$id": "/schemas/3.0.5/bundled/media-buy/sync-catalogs-request.json",
   "title": "Sync Catalogs Request",
   "description": "Request parameters for syncing catalog feeds with upsert semantics. Supports bulk operations across multiple catalog types (products, inventory, stores, promotions, offerings). Existing catalogs matched by catalog_id are updated, new ones are created. When catalogs is omitted, the call is discovery-only: returns all catalogs on the account without modification.",
   "x-mutates-state": true,
@@ -830,7 +830,7 @@
     }
   ],
   "_bundled": {
-    "generatedAt": "2026-04-28T12:32:23.013Z",
+    "generatedAt": "2026-05-02T21:51:30.464Z",
     "note": "This is a bundled schema with all $ref resolved inline. For the modular version with references, use the parent directory."
   }
 }