@giveitsmaller/contracts 0.87.0 → 0.89.0

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 (562) hide show
  1. package/README.md +2 -2
  2. package/accepted-options/accepted-options.json +1 -1
  3. package/accepted-options/image-output-routes.json +1 -1
  4. package/asyncapi/events.yaml +7 -4
  5. package/availability/availability.json +20 -13
  6. package/code-builder/code-builder-metadata.json +17 -10
  7. package/dist/openapi/models/AccountLimitEntry.d.ts +1 -1
  8. package/dist/openapi/models/AccountLimitEntry.js +1 -1
  9. package/dist/openapi/models/AccountLimits.d.ts +1 -1
  10. package/dist/openapi/models/AccountLimits.js +1 -1
  11. package/dist/openapi/models/AccountLimitsLimits.d.ts +1 -1
  12. package/dist/openapi/models/AccountLimitsLimits.js +1 -1
  13. package/dist/openapi/models/AccountLimitsSuccessEnvelope.d.ts +1 -1
  14. package/dist/openapi/models/AccountLimitsSuccessEnvelope.js +1 -1
  15. package/dist/openapi/models/AnonymousLimitExceededResponse.d.ts +1 -1
  16. package/dist/openapi/models/AnonymousLimitExceededResponse.js +1 -1
  17. package/dist/openapi/models/AnonymousOperationNotAllowedResponse.d.ts +1 -1
  18. package/dist/openapi/models/AnonymousOperationNotAllowedResponse.js +1 -1
  19. package/dist/openapi/models/AnonymousQuotaExhaustedResponse.d.ts +1 -1
  20. package/dist/openapi/models/AnonymousQuotaExhaustedResponse.js +1 -1
  21. package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +1 -1
  22. package/dist/openapi/models/AudioWatermarkDecodeRequest.js +1 -1
  23. package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +1 -1
  24. package/dist/openapi/models/AudioWatermarkDecodeResponse.js +1 -1
  25. package/dist/openapi/models/AuthErrorResponse.d.ts +1 -1
  26. package/dist/openapi/models/AuthErrorResponse.js +1 -1
  27. package/dist/openapi/models/AuthErrorType.d.ts +1 -1
  28. package/dist/openapi/models/AuthErrorType.js +1 -1
  29. package/dist/openapi/models/AuthRejectionEnvelope.d.ts +1 -1
  30. package/dist/openapi/models/AuthRejectionEnvelope.js +1 -1
  31. package/dist/openapi/models/AuthenticatedIdentity.d.ts +1 -1
  32. package/dist/openapi/models/AuthenticatedIdentity.js +1 -1
  33. package/dist/openapi/models/AvailabilityValue.d.ts +1 -1
  34. package/dist/openapi/models/AvailabilityValue.js +1 -1
  35. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +1 -1
  36. package/dist/openapi/models/BalanceExhaustedResponse.js +1 -1
  37. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +1 -1
  38. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +1 -1
  39. package/dist/openapi/models/BillingCheckoutRequest.d.ts +1 -1
  40. package/dist/openapi/models/BillingCheckoutRequest.js +1 -1
  41. package/dist/openapi/models/BillingCheckoutSession.d.ts +1 -1
  42. package/dist/openapi/models/BillingCheckoutSession.js +1 -1
  43. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.d.ts +1 -1
  44. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.js +1 -1
  45. package/dist/openapi/models/CallbackEventType.d.ts +1 -1
  46. package/dist/openapi/models/CallbackEventType.js +1 -1
  47. package/dist/openapi/models/CancelAccountDeletion200Response.d.ts +1 -1
  48. package/dist/openapi/models/CancelAccountDeletion200Response.js +1 -1
  49. package/dist/openapi/models/CancelAccountDeletion200ResponseData.d.ts +1 -1
  50. package/dist/openapi/models/CancelAccountDeletion200ResponseData.js +1 -1
  51. package/dist/openapi/models/CapabilityCondition.d.ts +1 -1
  52. package/dist/openapi/models/CapabilityCondition.js +3 -2
  53. package/dist/openapi/models/CapabilityConditionOneOf.d.ts +1 -1
  54. package/dist/openapi/models/CapabilityConditionOneOf.js +1 -1
  55. package/dist/openapi/models/CapabilityConditionOneOf1.d.ts +1 -1
  56. package/dist/openapi/models/CapabilityConditionOneOf1.js +1 -1
  57. package/dist/openapi/models/CapabilityConditionOneOf2.d.ts +1 -1
  58. package/dist/openapi/models/CapabilityConditionOneOf2.js +1 -1
  59. package/dist/openapi/models/CapabilityConditionOneOf3.d.ts +1 -1
  60. package/dist/openapi/models/CapabilityConditionOneOf3.js +1 -1
  61. package/dist/openapi/models/CapabilityConditionOneOf4.d.ts +1 -1
  62. package/dist/openapi/models/CapabilityConditionOneOf4.js +1 -1
  63. package/dist/openapi/models/CapabilityConditionOneOf5.d.ts +1 -1
  64. package/dist/openapi/models/CapabilityConditionOneOf5.js +1 -1
  65. package/dist/openapi/models/CapabilityConditionOneOf6.d.ts +1 -1
  66. package/dist/openapi/models/CapabilityConditionOneOf6.js +1 -1
  67. package/dist/openapi/models/CapabilityConditionOneOf7.d.ts +1 -1
  68. package/dist/openapi/models/CapabilityConditionOneOf7.js +1 -1
  69. package/dist/openapi/models/CapabilityConstraint.d.ts +1 -1
  70. package/dist/openapi/models/CapabilityConstraint.js +1 -1
  71. package/dist/openapi/models/CapabilityInputSpec.d.ts +1 -1
  72. package/dist/openapi/models/CapabilityInputSpec.js +1 -1
  73. package/dist/openapi/models/CapabilityProduces.d.ts +1 -1
  74. package/dist/openapi/models/CapabilityProduces.js +5 -3
  75. package/dist/openapi/models/CapabilityProducesOneOf.d.ts +1 -1
  76. package/dist/openapi/models/CapabilityProducesOneOf.js +1 -1
  77. package/dist/openapi/models/CapabilityProducesOneOf1.d.ts +1 -1
  78. package/dist/openapi/models/CapabilityProducesOneOf1.js +1 -1
  79. package/dist/openapi/models/CapabilityProducesOneOf2.d.ts +1 -1
  80. package/dist/openapi/models/CapabilityProducesOneOf2.js +1 -1
  81. package/dist/openapi/models/CeilingBasisValue.d.ts +1 -1
  82. package/dist/openapi/models/CeilingBasisValue.js +1 -1
  83. package/dist/openapi/models/ChangePasswordRequest.d.ts +1 -1
  84. package/dist/openapi/models/ChangePasswordRequest.js +1 -1
  85. package/dist/openapi/models/CheckoutSessionStatusResponse.d.ts +1 -1
  86. package/dist/openapi/models/CheckoutSessionStatusResponse.js +1 -1
  87. package/dist/openapi/models/CheckoutSessionStatusResponseData.d.ts +1 -1
  88. package/dist/openapi/models/CheckoutSessionStatusResponseData.js +1 -1
  89. package/dist/openapi/models/CodegenSource.d.ts +1 -1
  90. package/dist/openapi/models/CodegenSource.js +1 -1
  91. package/dist/openapi/models/CodegenSourceInput.d.ts +1 -1
  92. package/dist/openapi/models/CodegenSourceInput.js +1 -1
  93. package/dist/openapi/models/CodegenSourceJob.d.ts +1 -1
  94. package/dist/openapi/models/CodegenSourceJob.js +1 -1
  95. package/dist/openapi/models/CodegenSourceJobSource.d.ts +1 -1
  96. package/dist/openapi/models/CodegenSourceJobSource.js +5 -3
  97. package/dist/openapi/models/CodegenSourceOperation.d.ts +1 -1
  98. package/dist/openapi/models/CodegenSourceOperation.js +1 -1
  99. package/dist/openapi/models/CodegenUploadPlaceholder.d.ts +1 -1
  100. package/dist/openapi/models/CodegenUploadPlaceholder.js +1 -1
  101. package/dist/openapi/models/CompositionPlan.d.ts +1 -1
  102. package/dist/openapi/models/CompositionPlan.js +1 -1
  103. package/dist/openapi/models/CompositionPlanJob.d.ts +1 -1
  104. package/dist/openapi/models/CompositionPlanJob.js +1 -1
  105. package/dist/openapi/models/CompositionPlanOperation.d.ts +1 -1
  106. package/dist/openapi/models/CompositionPlanOperation.js +1 -1
  107. package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +1 -1
  108. package/dist/openapi/models/ConfirmEmailChange200Response.js +1 -1
  109. package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +1 -1
  110. package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +1 -1
  111. package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +1 -1
  112. package/dist/openapi/models/ConfirmEmailChangeRequest.js +1 -1
  113. package/dist/openapi/models/ConnectionSource.d.ts +1 -1
  114. package/dist/openapi/models/ConnectionSource.js +1 -1
  115. package/dist/openapi/models/ContactRequest.d.ts +1 -1
  116. package/dist/openapi/models/ContactRequest.js +1 -1
  117. package/dist/openapi/models/ContactSubject.d.ts +1 -1
  118. package/dist/openapi/models/ContactSubject.js +1 -1
  119. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +1 -1
  120. package/dist/openapi/models/ContactValidationErrorResponse.js +1 -1
  121. package/dist/openapi/models/CreateApiKey201Response.d.ts +1 -1
  122. package/dist/openapi/models/CreateApiKey201Response.js +1 -1
  123. package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +1 -1
  124. package/dist/openapi/models/CreateApiKey201ResponseData.js +1 -1
  125. package/dist/openapi/models/CreateApiKeyRequest.d.ts +1 -1
  126. package/dist/openapi/models/CreateApiKeyRequest.js +1 -1
  127. package/dist/openapi/models/CreateBillingCheckoutSession422Response.d.ts +1 -1
  128. package/dist/openapi/models/CreateBillingCheckoutSession422Response.js +7 -4
  129. package/dist/openapi/models/CreateExternalImport403Response.d.ts +1 -1
  130. package/dist/openapi/models/CreateExternalImport403Response.js +10 -6
  131. package/dist/openapi/models/CreateExternalImport422Response.d.ts +1 -1
  132. package/dist/openapi/models/CreateExternalImport422Response.js +1 -1
  133. package/dist/openapi/models/CreateWorkflow401Response.d.ts +1 -1
  134. package/dist/openapi/models/CreateWorkflow401Response.js +1 -1
  135. package/dist/openapi/models/CreateWorkflow403Response.d.ts +1 -1
  136. package/dist/openapi/models/CreateWorkflow403Response.js +1 -1
  137. package/dist/openapi/models/CreateWorkflow422Response.d.ts +1 -1
  138. package/dist/openapi/models/CreateWorkflow422Response.js +1 -1
  139. package/dist/openapi/models/CreditTransaction.d.ts +1 -1
  140. package/dist/openapi/models/CreditTransaction.js +1 -1
  141. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +1 -1
  142. package/dist/openapi/models/CreditTransactionSourceBucket.js +1 -1
  143. package/dist/openapi/models/CreditsBalanceResponse.d.ts +1 -1
  144. package/dist/openapi/models/CreditsBalanceResponse.js +1 -1
  145. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +1 -1
  146. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +1 -1
  147. package/dist/openapi/models/CreditsUsageResponse.d.ts +1 -1
  148. package/dist/openapi/models/CreditsUsageResponse.js +1 -1
  149. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +1 -1
  150. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +1 -1
  151. package/dist/openapi/models/Delivery.d.ts +1 -1
  152. package/dist/openapi/models/Delivery.js +1 -1
  153. package/dist/openapi/models/DeliveryOutputRef.d.ts +1 -1
  154. package/dist/openapi/models/DeliveryOutputRef.js +1 -1
  155. package/dist/openapi/models/DeliveryPlan.d.ts +1 -1
  156. package/dist/openapi/models/DeliveryPlan.js +1 -1
  157. package/dist/openapi/models/DeliveryPlanOutput.d.ts +1 -1
  158. package/dist/openapi/models/DeliveryPlanOutput.js +1 -1
  159. package/dist/openapi/models/DeliveryPlanReason.d.ts +1 -1
  160. package/dist/openapi/models/DeliveryPlanReason.js +1 -1
  161. package/dist/openapi/models/DeliverySelection.d.ts +1 -1
  162. package/dist/openapi/models/DeliverySelection.js +1 -1
  163. package/dist/openapi/models/DownloadBundle.d.ts +1 -1
  164. package/dist/openapi/models/DownloadBundle.js +1 -1
  165. package/dist/openapi/models/DroppedOption.d.ts +1 -1
  166. package/dist/openapi/models/DroppedOption.js +1 -1
  167. package/dist/openapi/models/EmailNotify.d.ts +1 -1
  168. package/dist/openapi/models/EmailNotify.js +1 -1
  169. package/dist/openapi/models/EmptySuccessEnvelope.d.ts +1 -1
  170. package/dist/openapi/models/EmptySuccessEnvelope.js +1 -1
  171. package/dist/openapi/models/EndpointProjection.d.ts +1 -1
  172. package/dist/openapi/models/EndpointProjection.js +1 -1
  173. package/dist/openapi/models/EndpointProjectionServersInner.d.ts +1 -1
  174. package/dist/openapi/models/EndpointProjectionServersInner.js +1 -1
  175. package/dist/openapi/models/ErrorEnvelope.d.ts +1 -1
  176. package/dist/openapi/models/ErrorEnvelope.js +1 -1
  177. package/dist/openapi/models/EstimateQuality.d.ts +1 -1
  178. package/dist/openapi/models/EstimateQuality.js +1 -1
  179. package/dist/openapi/models/EstimateRange.d.ts +1 -1
  180. package/dist/openapi/models/EstimateRange.js +1 -1
  181. package/dist/openapi/models/ExportAccountData200Response.d.ts +1 -1
  182. package/dist/openapi/models/ExportAccountData200Response.js +1 -1
  183. package/dist/openapi/models/ExportAccountData200ResponseData.d.ts +1 -1
  184. package/dist/openapi/models/ExportAccountData200ResponseData.js +1 -1
  185. package/dist/openapi/models/ExportAccountData200ResponseDataBilling.d.ts +1 -1
  186. package/dist/openapi/models/ExportAccountData200ResponseDataBilling.js +1 -1
  187. package/dist/openapi/models/ExportAccountData200ResponseDataBillingCheckoutSessionsInner.d.ts +1 -1
  188. package/dist/openapi/models/ExportAccountData200ResponseDataBillingCheckoutSessionsInner.js +1 -1
  189. package/dist/openapi/models/ExternalDestination.d.ts +1 -1
  190. package/dist/openapi/models/ExternalDestination.js +1 -1
  191. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +1 -1
  192. package/dist/openapi/models/ExternalImportCreatedResponse.js +1 -1
  193. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +1 -1
  194. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +1 -1
  195. package/dist/openapi/models/ExternalImportRequest.d.ts +1 -1
  196. package/dist/openapi/models/ExternalImportRequest.js +1 -1
  197. package/dist/openapi/models/ExternalImportToken.d.ts +1 -1
  198. package/dist/openapi/models/ExternalImportToken.js +1 -1
  199. package/dist/openapi/models/ExternalSource.d.ts +1 -1
  200. package/dist/openapi/models/ExternalSource.js +1 -1
  201. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +1 -1
  202. package/dist/openapi/models/FeatureNotAvailableResponse.js +1 -1
  203. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +1 -1
  204. package/dist/openapi/models/FeatureTierRestrictedResponse.js +1 -1
  205. package/dist/openapi/models/FeatureViolation.d.ts +1 -1
  206. package/dist/openapi/models/FeatureViolation.js +1 -1
  207. package/dist/openapi/models/GetProfile200Response.d.ts +1 -1
  208. package/dist/openapi/models/GetProfile200Response.js +1 -1
  209. package/dist/openapi/models/GetProfile200ResponseData.d.ts +1 -1
  210. package/dist/openapi/models/GetProfile200ResponseData.js +1 -1
  211. package/dist/openapi/models/ImageEncodeCapabilities.d.ts +1 -1
  212. package/dist/openapi/models/ImageEncodeCapabilities.js +1 -1
  213. package/dist/openapi/models/JobDefinition.d.ts +1 -1
  214. package/dist/openapi/models/JobDefinition.js +1 -1
  215. package/dist/openapi/models/JobDownload.d.ts +1 -1
  216. package/dist/openapi/models/JobDownload.js +1 -1
  217. package/dist/openapi/models/JobInputV2.d.ts +1 -1
  218. package/dist/openapi/models/JobInputV2.js +1 -1
  219. package/dist/openapi/models/JobMediaClass.d.ts +1 -1
  220. package/dist/openapi/models/JobMediaClass.js +1 -1
  221. package/dist/openapi/models/JobOutputSource.d.ts +1 -1
  222. package/dist/openapi/models/JobOutputSource.js +1 -1
  223. package/dist/openapi/models/JobResponse.d.ts +1 -1
  224. package/dist/openapi/models/JobResponse.js +1 -1
  225. package/dist/openapi/models/JobStatus.d.ts +1 -1
  226. package/dist/openapi/models/JobStatus.js +1 -1
  227. package/dist/openapi/models/JobType.d.ts +1 -1
  228. package/dist/openapi/models/JobType.js +1 -1
  229. package/dist/openapi/models/LivenessResponse.d.ts +1 -1
  230. package/dist/openapi/models/LivenessResponse.js +1 -1
  231. package/dist/openapi/models/LoginUser200Response.d.ts +1 -1
  232. package/dist/openapi/models/LoginUser200Response.js +1 -1
  233. package/dist/openapi/models/LoginUser200ResponseData.d.ts +1 -1
  234. package/dist/openapi/models/LoginUser200ResponseData.js +1 -1
  235. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +1 -1
  236. package/dist/openapi/models/LoginUser200ResponseDataUser.js +1 -1
  237. package/dist/openapi/models/LoginUser401Response.d.ts +1 -1
  238. package/dist/openapi/models/LoginUser401Response.js +1 -1
  239. package/dist/openapi/models/LoginUserRequest.d.ts +1 -1
  240. package/dist/openapi/models/LoginUserRequest.js +1 -1
  241. package/dist/openapi/models/LongFormConcurrencyLimitResponse.d.ts +1 -1
  242. package/dist/openapi/models/LongFormConcurrencyLimitResponse.js +1 -1
  243. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.d.ts +1 -1
  244. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.js +1 -1
  245. package/dist/openapi/models/MetadataResponse.d.ts +1 -1
  246. package/dist/openapi/models/MetadataResponse.js +1 -1
  247. package/dist/openapi/models/MetadataResponseDimensions.d.ts +1 -1
  248. package/dist/openapi/models/MetadataResponseDimensions.js +1 -1
  249. package/dist/openapi/models/MetadataResponseExif.d.ts +1 -1
  250. package/dist/openapi/models/MetadataResponseExif.js +1 -1
  251. package/dist/openapi/models/MetadataResponseExifGps.d.ts +1 -1
  252. package/dist/openapi/models/MetadataResponseExifGps.js +1 -1
  253. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +1 -1
  254. package/dist/openapi/models/MetadataSuccessEnvelope.js +1 -1
  255. package/dist/openapi/models/MimeGroupSchema.d.ts +1 -1
  256. package/dist/openapi/models/MimeGroupSchema.js +1 -1
  257. package/dist/openapi/models/MultiInputSource.d.ts +1 -1
  258. package/dist/openapi/models/MultiInputSource.js +1 -1
  259. package/dist/openapi/models/MultipartCompleteRequest.d.ts +1 -1
  260. package/dist/openapi/models/MultipartCompleteRequest.js +1 -1
  261. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +1 -1
  262. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +1 -1
  263. package/dist/openapi/models/MultipartCompleteResponse.d.ts +1 -1
  264. package/dist/openapi/models/MultipartCompleteResponse.js +1 -1
  265. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +1 -1
  266. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +1 -1
  267. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +1 -1
  268. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +1 -1
  269. package/dist/openapi/models/MultipartInitiateResponse.d.ts +1 -1
  270. package/dist/openapi/models/MultipartInitiateResponse.js +1 -1
  271. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +1 -1
  272. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +1 -1
  273. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +1 -1
  274. package/dist/openapi/models/MultipartKeepaliveResponse.js +1 -1
  275. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +1 -1
  276. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +1 -1
  277. package/dist/openapi/models/MultipartPartListing.d.ts +1 -1
  278. package/dist/openapi/models/MultipartPartListing.js +1 -1
  279. package/dist/openapi/models/MultipartPresignRequest.d.ts +1 -1
  280. package/dist/openapi/models/MultipartPresignRequest.js +1 -1
  281. package/dist/openapi/models/MultipartPresignResponse.d.ts +1 -1
  282. package/dist/openapi/models/MultipartPresignResponse.js +1 -1
  283. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +1 -1
  284. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +1 -1
  285. package/dist/openapi/models/MultipartStatusResponse.d.ts +1 -1
  286. package/dist/openapi/models/MultipartStatusResponse.js +1 -1
  287. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +1 -1
  288. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +1 -1
  289. package/dist/openapi/models/NotifyConfig.d.ts +1 -1
  290. package/dist/openapi/models/NotifyConfig.js +1 -1
  291. package/dist/openapi/models/OperationCapability.d.ts +1 -1
  292. package/dist/openapi/models/OperationCapability.js +1 -1
  293. package/dist/openapi/models/OperationDefinition.d.ts +1 -1
  294. package/dist/openapi/models/OperationDefinition.js +1 -1
  295. package/dist/openapi/models/OperationDownload.d.ts +1 -1
  296. package/dist/openapi/models/OperationDownload.js +1 -1
  297. package/dist/openapi/models/OperationInputModel.d.ts +1 -1
  298. package/dist/openapi/models/OperationInputModel.js +1 -1
  299. package/dist/openapi/models/OperationMessageParamsValue.d.ts +1 -1
  300. package/dist/openapi/models/OperationMessageParamsValue.js +1 -1
  301. package/dist/openapi/models/OperationResponse.d.ts +1 -1
  302. package/dist/openapi/models/OperationResponse.js +1 -1
  303. package/dist/openapi/models/OperationResult.d.ts +1 -1
  304. package/dist/openapi/models/OperationResult.js +1 -1
  305. package/dist/openapi/models/OperationResultMetadata.d.ts +1 -1
  306. package/dist/openapi/models/OperationResultMetadata.js +1 -1
  307. package/dist/openapi/models/OperationResultMetrics.d.ts +1 -1
  308. package/dist/openapi/models/OperationResultMetrics.js +1 -1
  309. package/dist/openapi/models/OperationSchemaDefinition.d.ts +1 -1
  310. package/dist/openapi/models/OperationSchemaDefinition.js +1 -1
  311. package/dist/openapi/models/OperationStatus.d.ts +1 -1
  312. package/dist/openapi/models/OperationStatus.js +1 -1
  313. package/dist/openapi/models/OperationType.d.ts +1 -1
  314. package/dist/openapi/models/OperationType.js +1 -1
  315. package/dist/openapi/models/OperationsSchemaResponse.d.ts +1 -1
  316. package/dist/openapi/models/OperationsSchemaResponse.js +1 -1
  317. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +1 -1
  318. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +1 -1
  319. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +1 -1
  320. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +1 -1
  321. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +1 -1
  322. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +1 -1
  323. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +1 -1
  324. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +1 -1
  325. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.d.ts +1 -1
  326. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.js +1 -1
  327. package/dist/openapi/models/OptionSchema.d.ts +1 -1
  328. package/dist/openapi/models/OptionSchema.js +1 -1
  329. package/dist/openapi/models/OutputProperties.d.ts +1 -1
  330. package/dist/openapi/models/OutputProperties.js +1 -1
  331. package/dist/openapi/models/OutputPropertiesIsAnimated.d.ts +1 -1
  332. package/dist/openapi/models/OutputPropertiesIsAnimated.js +1 -1
  333. package/dist/openapi/models/PerClassAvailabilityEntry.d.ts +1 -1
  334. package/dist/openapi/models/PerClassAvailabilityEntry.js +1 -1
  335. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +1 -1
  336. package/dist/openapi/models/PerRoleCardinalityEntry.js +1 -1
  337. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +1 -1
  338. package/dist/openapi/models/PerValueAvailabilityEntry.js +1 -1
  339. package/dist/openapi/models/PresignedUrlPart.d.ts +1 -1
  340. package/dist/openapi/models/PresignedUrlPart.js +1 -1
  341. package/dist/openapi/models/ProbePendingResponse.d.ts +1 -1
  342. package/dist/openapi/models/ProbePendingResponse.js +1 -1
  343. package/dist/openapi/models/ProbeUpload422Response.d.ts +1 -1
  344. package/dist/openapi/models/ProbeUpload422Response.js +1 -1
  345. package/dist/openapi/models/ProcessingClass.d.ts +1 -1
  346. package/dist/openapi/models/ProcessingClass.js +1 -1
  347. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +1 -1
  348. package/dist/openapi/models/ProcessingClassBandViolation.js +1 -1
  349. package/dist/openapi/models/ProcessingClassConstraints.d.ts +1 -1
  350. package/dist/openapi/models/ProcessingClassConstraints.js +1 -1
  351. package/dist/openapi/models/ProcessingClassEntry.d.ts +1 -1
  352. package/dist/openapi/models/ProcessingClassEntry.js +1 -1
  353. package/dist/openapi/models/ProcessingClassEntryInputUniformity.d.ts +9 -6
  354. package/dist/openapi/models/ProcessingClassEntryInputUniformity.js +1 -1
  355. package/dist/openapi/models/ProcessingClassEntryResolutionBands.d.ts +1 -1
  356. package/dist/openapi/models/ProcessingClassEntryResolutionBands.js +1 -1
  357. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +1 -1
  358. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +1 -1
  359. package/dist/openapi/models/ProcessingClassHint.d.ts +1 -1
  360. package/dist/openapi/models/ProcessingClassHint.js +1 -1
  361. package/dist/openapi/models/ProcessingClassReason.d.ts +13 -1
  362. package/dist/openapi/models/ProcessingClassReason.js +13 -1
  363. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +1 -1
  364. package/dist/openapi/models/ProcessingClassRejectReason.js +1 -1
  365. package/dist/openapi/models/ProcessingPlan.d.ts +1 -1
  366. package/dist/openapi/models/ProcessingPlan.js +1 -1
  367. package/dist/openapi/models/ProcessingPlanJob.d.ts +1 -1
  368. package/dist/openapi/models/ProcessingPlanJob.js +1 -1
  369. package/dist/openapi/models/ReEncodeDecision.d.ts +1 -1
  370. package/dist/openapi/models/ReEncodeDecision.js +1 -1
  371. package/dist/openapi/models/ReadinessResponse.d.ts +1 -1
  372. package/dist/openapi/models/ReadinessResponse.js +1 -1
  373. package/dist/openapi/models/RegisterUser422Response.d.ts +1 -1
  374. package/dist/openapi/models/RegisterUser422Response.js +1 -1
  375. package/dist/openapi/models/RegisterUserRequest.d.ts +1 -1
  376. package/dist/openapi/models/RegisterUserRequest.js +1 -1
  377. package/dist/openapi/models/RequestAccountDeletion200Response.d.ts +1 -1
  378. package/dist/openapi/models/RequestAccountDeletion200Response.js +1 -1
  379. package/dist/openapi/models/RequestAccountDeletion200ResponseData.d.ts +1 -1
  380. package/dist/openapi/models/RequestAccountDeletion200ResponseData.js +1 -1
  381. package/dist/openapi/models/RequestAccountDeletionRequest.d.ts +1 -1
  382. package/dist/openapi/models/RequestAccountDeletionRequest.js +1 -1
  383. package/dist/openapi/models/ResendVerificationEmailRequest.d.ts +1 -1
  384. package/dist/openapi/models/ResendVerificationEmailRequest.js +1 -1
  385. package/dist/openapi/models/ResetPasswordRequest.d.ts +1 -1
  386. package/dist/openapi/models/ResetPasswordRequest.js +1 -1
  387. package/dist/openapi/models/ResolutionBand.d.ts +1 -1
  388. package/dist/openapi/models/ResolutionBand.js +1 -1
  389. package/dist/openapi/models/ResolutionBandCeiling.d.ts +1 -1
  390. package/dist/openapi/models/ResolutionBandCeiling.js +1 -1
  391. package/dist/openapi/models/ResolutionBandCeilingConstraints.d.ts +1 -1
  392. package/dist/openapi/models/ResolutionBandCeilingConstraints.js +1 -1
  393. package/dist/openapi/models/ResolutionBandCeilingDerivation.d.ts +1 -1
  394. package/dist/openapi/models/ResolutionBandCeilingDerivation.js +1 -1
  395. package/dist/openapi/models/ResponseEnvelope.d.ts +1 -1
  396. package/dist/openapi/models/ResponseEnvelope.js +1 -1
  397. package/dist/openapi/models/RetryResponse.d.ts +1 -1
  398. package/dist/openapi/models/RetryResponse.js +1 -1
  399. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +1 -1
  400. package/dist/openapi/models/RetrySuccessEnvelope.js +1 -1
  401. package/dist/openapi/models/SseCompletionBase.d.ts +1 -1
  402. package/dist/openapi/models/SseCompletionBase.js +1 -1
  403. package/dist/openapi/models/SseConnectionLimitResponse.d.ts +1 -1
  404. package/dist/openapi/models/SseConnectionLimitResponse.js +1 -1
  405. package/dist/openapi/models/SseEventType.d.ts +1 -1
  406. package/dist/openapi/models/SseEventType.js +1 -1
  407. package/dist/openapi/models/SseJobCompletedData.d.ts +1 -1
  408. package/dist/openapi/models/SseJobCompletedData.js +1 -1
  409. package/dist/openapi/models/SseJobFailedData.d.ts +1 -1
  410. package/dist/openapi/models/SseJobFailedData.js +1 -1
  411. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +1 -1
  412. package/dist/openapi/models/SseMultiOutputCompletion.js +1 -1
  413. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +1 -1
  414. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +1 -1
  415. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +1 -1
  416. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +1 -1
  417. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +1 -1
  418. package/dist/openapi/models/SseMultiOutputResultEntry.js +1 -1
  419. package/dist/openapi/models/SseOperationCompletedData.d.ts +1 -1
  420. package/dist/openapi/models/SseOperationCompletedData.js +1 -1
  421. package/dist/openapi/models/SseOperationCompletionResult.d.ts +1 -1
  422. package/dist/openapi/models/SseOperationCompletionResult.js +1 -1
  423. package/dist/openapi/models/SseOperationFailedData.d.ts +1 -1
  424. package/dist/openapi/models/SseOperationFailedData.js +1 -1
  425. package/dist/openapi/models/SseOperationProgressData.d.ts +1 -1
  426. package/dist/openapi/models/SseOperationProgressData.js +1 -1
  427. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +1 -1
  428. package/dist/openapi/models/SseSingleOutputCompletion.js +1 -1
  429. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +1 -1
  430. package/dist/openapi/models/SseWorkflowTerminalData.js +1 -1
  431. package/dist/openapi/models/TierRestrictionKind.d.ts +1 -1
  432. package/dist/openapi/models/TierRestrictionKind.js +1 -1
  433. package/dist/openapi/models/TierRestrictionResponse.d.ts +1 -1
  434. package/dist/openapi/models/TierRestrictionResponse.js +1 -1
  435. package/dist/openapi/models/UpdateProfile200Response.d.ts +1 -1
  436. package/dist/openapi/models/UpdateProfile200Response.js +1 -1
  437. package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +1 -1
  438. package/dist/openapi/models/UpdateProfile200ResponseData.js +1 -1
  439. package/dist/openapi/models/UpdateProfile422Response.d.ts +1 -1
  440. package/dist/openapi/models/UpdateProfile422Response.js +1 -1
  441. package/dist/openapi/models/UpdateProfileRequest.d.ts +1 -1
  442. package/dist/openapi/models/UpdateProfileRequest.js +1 -1
  443. package/dist/openapi/models/UploadConstraintsApplied.d.ts +1 -1
  444. package/dist/openapi/models/UploadConstraintsApplied.js +1 -1
  445. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +1 -1
  446. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +1 -1
  447. package/dist/openapi/models/UploadFile403Response.d.ts +1 -1
  448. package/dist/openapi/models/UploadFile403Response.js +1 -1
  449. package/dist/openapi/models/UploadFile422Response.d.ts +1 -1
  450. package/dist/openapi/models/UploadFile422Response.js +1 -1
  451. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +1 -1
  452. package/dist/openapi/models/UploadProbeMediaMetadata.js +1 -1
  453. package/dist/openapi/models/UploadProbeNotApplicableResponse.d.ts +1 -1
  454. package/dist/openapi/models/UploadProbeNotApplicableResponse.js +1 -1
  455. package/dist/openapi/models/UploadProbeNotReadyResponse.d.ts +1 -1
  456. package/dist/openapi/models/UploadProbeNotReadyResponse.js +1 -1
  457. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +1 -1
  458. package/dist/openapi/models/UploadProbeProcessingClass.js +1 -1
  459. package/dist/openapi/models/UploadProbeResponse.d.ts +1 -1
  460. package/dist/openapi/models/UploadProbeResponse.js +1 -1
  461. package/dist/openapi/models/UploadProbeStatus.d.ts +1 -1
  462. package/dist/openapi/models/UploadProbeStatus.js +1 -1
  463. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +1 -1
  464. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +1 -1
  465. package/dist/openapi/models/UploadResponse.d.ts +1 -1
  466. package/dist/openapi/models/UploadResponse.js +1 -1
  467. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +1 -1
  468. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +1 -1
  469. package/dist/openapi/models/UploadSource.d.ts +1 -1
  470. package/dist/openapi/models/UploadSource.js +1 -1
  471. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +1 -1
  472. package/dist/openapi/models/UploadSuccessEnvelope.js +1 -1
  473. package/dist/openapi/models/UploadThresholds.d.ts +1 -1
  474. package/dist/openapi/models/UploadThresholds.js +1 -1
  475. package/dist/openapi/models/UserTier.d.ts +1 -1
  476. package/dist/openapi/models/UserTier.js +1 -1
  477. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +1 -1
  478. package/dist/openapi/models/ValidationErrorEnvelope.js +1 -1
  479. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +1 -1
  480. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +1 -1
  481. package/dist/openapi/models/VerifyEmailRequest.d.ts +1 -1
  482. package/dist/openapi/models/VerifyEmailRequest.js +1 -1
  483. package/dist/openapi/models/WarningType.d.ts +1 -1
  484. package/dist/openapi/models/WarningType.js +1 -1
  485. package/dist/openapi/models/WebhookOperationContext.d.ts +1 -1
  486. package/dist/openapi/models/WebhookOperationContext.js +1 -1
  487. package/dist/openapi/models/WebhookPayload.d.ts +1 -1
  488. package/dist/openapi/models/WebhookPayload.js +1 -1
  489. package/dist/openapi/models/WorkflowArchiveResponse.d.ts +1 -1
  490. package/dist/openapi/models/WorkflowArchiveResponse.js +1 -1
  491. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.d.ts +1 -1
  492. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.js +1 -1
  493. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +1 -1
  494. package/dist/openapi/models/WorkflowCancelBillingEffect.js +1 -1
  495. package/dist/openapi/models/WorkflowCancelResponse.d.ts +1 -1
  496. package/dist/openapi/models/WorkflowCancelResponse.js +1 -1
  497. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +1 -1
  498. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +1 -1
  499. package/dist/openapi/models/WorkflowCreateRequest.d.ts +1 -1
  500. package/dist/openapi/models/WorkflowCreateRequest.js +1 -1
  501. package/dist/openapi/models/WorkflowCreateResponse.d.ts +1 -1
  502. package/dist/openapi/models/WorkflowCreateResponse.js +1 -1
  503. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +1 -1
  504. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +1 -1
  505. package/dist/openapi/models/WorkflowCreditSummary.d.ts +1 -1
  506. package/dist/openapi/models/WorkflowCreditSummary.js +1 -1
  507. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +1 -1
  508. package/dist/openapi/models/WorkflowDownloadResponse.js +1 -1
  509. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +1 -1
  510. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +1 -1
  511. package/dist/openapi/models/WorkflowEdge.d.ts +1 -1
  512. package/dist/openapi/models/WorkflowEdge.js +1 -1
  513. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +1 -1
  514. package/dist/openapi/models/WorkflowExpiredResponse.js +1 -1
  515. package/dist/openapi/models/WorkflowListResponse.d.ts +1 -1
  516. package/dist/openapi/models/WorkflowListResponse.js +1 -1
  517. package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +1 -1
  518. package/dist/openapi/models/WorkflowListSuccessEnvelope.js +1 -1
  519. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +1 -1
  520. package/dist/openapi/models/WorkflowPauseRequiredAction.js +1 -1
  521. package/dist/openapi/models/WorkflowPausedDetail.d.ts +1 -1
  522. package/dist/openapi/models/WorkflowPausedDetail.js +1 -1
  523. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +1 -1
  524. package/dist/openapi/models/WorkflowPausedDetailLinks.js +1 -1
  525. package/dist/openapi/models/WorkflowProcessing.d.ts +1 -1
  526. package/dist/openapi/models/WorkflowProcessing.js +1 -1
  527. package/dist/openapi/models/WorkflowRestoreResponse.d.ts +1 -1
  528. package/dist/openapi/models/WorkflowRestoreResponse.js +1 -1
  529. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.d.ts +1 -1
  530. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.js +1 -1
  531. package/dist/openapi/models/WorkflowResumeResponse.d.ts +1 -1
  532. package/dist/openapi/models/WorkflowResumeResponse.js +1 -1
  533. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +1 -1
  534. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +1 -1
  535. package/dist/openapi/models/WorkflowSource.d.ts +1 -1
  536. package/dist/openapi/models/WorkflowSource.js +1 -1
  537. package/dist/openapi/models/WorkflowStatus.d.ts +1 -1
  538. package/dist/openapi/models/WorkflowStatus.js +1 -1
  539. package/dist/openapi/models/WorkflowStatusResponse.d.ts +1 -1
  540. package/dist/openapi/models/WorkflowStatusResponse.js +1 -1
  541. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +1 -1
  542. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +1 -1
  543. package/dist/openapi/models/WorkflowSummary.d.ts +1 -1
  544. package/dist/openapi/models/WorkflowSummary.js +1 -1
  545. package/dist/openapi/models/WorkflowSummaryJob.d.ts +1 -1
  546. package/dist/openapi/models/WorkflowSummaryJob.js +1 -1
  547. package/dist/openapi/models/WorkflowWarning.d.ts +1 -1
  548. package/dist/openapi/models/WorkflowWarning.js +1 -1
  549. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +1 -1
  550. package/dist/openapi/models/WorkflowWarningSeverity.js +1 -1
  551. package/dist/openapi/runtime.d.ts +1 -1
  552. package/dist/openapi/runtime.js +1 -1
  553. package/dist/operations/audio_to_video.metadata.js +1 -1
  554. package/dist/operations/thumbnail.metadata.js +1 -1
  555. package/openapi/api.yaml +71 -17
  556. package/operation-capabilities/operation-capabilities.json +69 -10
  557. package/operations/schemas/audio_to_video.yaml +11 -15
  558. package/operations/schemas/compress.yaml +27 -2
  559. package/operations/schemas/convert.yaml +13 -4
  560. package/operations/schemas/merge.yaml +24 -1
  561. package/operations/schemas/thumbnail.yaml +15 -5
  562. package/package.json +3 -3
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.223.0
5
+ * The version of the OpenAPI document: 2.225.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.223.0
5
+ * The version of the OpenAPI document: 2.225.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.223.0
5
+ * The version of the OpenAPI document: 2.225.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.223.0
5
+ * The version of the OpenAPI document: 2.225.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.223.0
5
+ * The version of the OpenAPI document: 2.225.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.223.0
5
+ * The version of the OpenAPI document: 2.225.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.223.0
5
+ * The version of the OpenAPI document: 2.225.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.223.0
5
+ * The version of the OpenAPI document: 2.225.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.223.0
5
+ * The version of the OpenAPI document: 2.225.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.223.0
7
+ * The version of the OpenAPI document: 2.225.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -9,7 +9,7 @@ export const audioToVideoMetadata = {
9
9
  short_form: {
10
10
  availability: 'planned',
11
11
  constraints: {
12
- max_input_duration: 'PT11M35S',
12
+ max_input_duration: 'PT29M43S',
13
13
  },
14
14
  },
15
15
  long_form: {
@@ -33,7 +33,7 @@ export const thumbnailMetadata = {
33
33
  availability: 'stable',
34
34
  constraints: {
35
35
  max_input_duration: 'PT30M',
36
- max_input_size_bytes: 950000000,
36
+ max_input_size_bytes: 2000000000,
37
37
  },
38
38
  },
39
39
  long_form: {
package/openapi/api.yaml CHANGED
@@ -103,7 +103,7 @@ info:
103
103
  of truth instead of hardcoding magic numbers. A runtime
104
104
  `GET /api/uploads/limits` endpoint for dynamic discovery
105
105
  (per-tier / per-environment overrides) is a deferred follow-up.
106
- version: 2.223.0
106
+ version: 2.225.0
107
107
  contact:
108
108
  name: API Support
109
109
 
@@ -1228,11 +1228,21 @@ paths:
1228
1228
  - `probe_not_ready` → `UploadProbeNotReadyResponse`: the probe
1229
1229
  has not landed YET. **Retry** (`Retry-After` when present).
1230
1230
  - `probe_not_applicable` → `UploadProbeNotApplicableResponse`:
1231
- this upload's type is never probed (e.g. an image, whose
1232
- metadata is read inline at upload). **Terminal — do not
1231
+ this upload's type is never probed. **Terminal — do not
1233
1232
  retry**; no result will ever exist.
1233
+
1234
+ **Which uploads are probed:** every `video/*`, every `audio/*`,
1235
+ and the documents PDF, EPUB, DOCX, XLSX, PPTX, ODT, ODS, ODP.
1236
+ **Images are never probed** (their metadata is read inline at
1237
+ upload), so for an image NO answer will ever become a result:
1238
+ `probe_not_applicable`, or the transitional arm below, are both
1239
+ final. A client that knows it uploaded an image stops at the
1240
+ first 422; the transitional arm's "retry with a ceiling" is for a
1241
+ client that cannot tell which case it is in.
1234
1242
  - `feature_not_available` → `FeatureNotAvailableResponse`
1235
- with `violations[].availability: planned`:
1243
+ with `violations[].availability: planned` (the API sends
1244
+ `planned` on this arm; the shared schema does not constrain it,
1245
+ and the arm is removed once the typed arms ship):
1236
1246
  **TRANSITIONAL.** What the server sends today for BOTH
1237
1247
  causes above. It predates this endpoint's move to `beta`
1238
1248
  and does NOT mean the endpoint is unavailable. Retry it
@@ -2086,8 +2096,9 @@ paths:
2086
2096
  server-side and deliberately opaque per plan v5 §F8.2.
2087
2097
  - Inputs not concat-uniform (ticket `MjzzPCWt`). Returned for a
2088
2098
  job that routes to a processing class declaring
2089
- `input_uniformity` (today `merge.video.long_form_re_encode`)
2090
- when its inputs differ in stream layout or in a listed
2099
+ `input_uniformity` (today `merge.video.long_form_re_encode`,
2100
+ and `merge.video.short_form_concat` for mixed audio topology
2101
+ only) when its inputs differ in stream layout or in a listed
2091
2102
  attribute. `ValidationErrorEnvelope` with `error:
2092
2103
  "INPUTS_NOT_CONCAT_UNIFORM"`; `details[]` entries are shaped
2093
2104
  `{operation: "merge", field: "inputs[i].<attribute> vs
@@ -2939,11 +2950,22 @@ paths:
2939
2950
  if added later it will be a separate, explicitly-specified feature.
2940
2951
 
2941
2952
  **`id:` field (SSE event id):** emitted **only on operation frames**
2942
- (`operation.progress` / `operation.completed` / `operation.failed`),
2943
- where it carries the underlying stream's event id. **Transition frames**
2944
- (`job.completed` / `job.failed`, `workflow.*`) carry **no `id:`**.
2945
- Because there is no `Last-Event-ID` resume, any emitted `id:` is
2946
- informational only — clients cannot use it to resume a stream.
2953
+ (`operation.progress` / `operation.completed` / `operation.failed`)
2954
+ read from a JOB's event stream (one stream per job, shared by that
2955
+ job's operations) — NOT on the long-form fan-out's
2956
+ public-row frames, which carry none (§"LONG-FORM FAN-OUT" below). Where
2957
+ a frame has an `id:`, it is **that frame's own** event id in the
2958
+ underlying stream — never another entry's. So within ONE job's stream
2959
+ every `id:` is **distinct** and the ids **increase** in the order its
2960
+ frames are sent (a replayed history keeps the ids its events had). Ids
2961
+ come from SEPARATE per-job streams, so across jobs they are neither
2962
+ ordered nor guaranteed distinct. An operation belongs to exactly one
2963
+ job, so the identity of a frame is **`operation_id` + `id:`**.
2964
+ **Transition frames** (`job.completed` / `job.failed`, `workflow.*`)
2965
+ carry **no `id:`**. Because there is no `Last-Event-ID` resume, an
2966
+ emitted `id:` is still informational — a client may dedupe frames
2967
+ across reconnects by `operation_id` + `id:`, but cannot use it to
2968
+ resume a stream.
2947
2969
 
2948
2970
  **Framing vs payload:** the `Sse*Data` component schemas describe only
2949
2971
  the `data:` JSON payload of each event. The SSE envelope framing itself
@@ -6779,7 +6801,15 @@ paths:
6779
6801
  # Flipping this back to `stable` is an UPGRADE and is covered by the
6780
6802
  # standing freeze (hub, 2026-08-11): no availability upgrade to `stable`
6781
6803
  # before launch without an explicit per-flip ruling.
6782
- x-availability: planned
6804
+ #
6805
+ # planned -> BETA 2026-10-06 (lU4Dh9b8) on prod evidence (prod log row
6806
+ # `endpoints/POST /api/billing/checkout`): a real-card payment was
6807
+ # fulfilled on prod 2026-09-10 (credits granted the same second), and
6808
+ # api v1.17.0 created a live session on 2026-10-06. NOT `stable` yet:
6809
+ # the 09-10 fulfilment predates api's checkout_sessions ledger
6810
+ # (v1.14.0), so no paid checkout has completed on the CURRENT
6811
+ # fulfilment path. Stable needs one, evidenced.
6812
+ x-availability: beta
6783
6813
  tags:
6784
6814
  - Billing
6785
6815
  requestBody:
@@ -12511,6 +12541,17 @@ components:
12511
12541
  - `input_size_exceeds_short_form` /
12512
12542
  `input_duration_exceeds_short_form`: input-driven escalation
12513
12543
  to `long_form`.
12544
+ - `resolution_band_exceeds_short_form`: escalation to `long_form` because
12545
+ the input's resolution band is one `short_form` does not serve
12546
+ (`processing_class.short_form.resolution_bands`, a band marked not
12547
+ served), whatever its duration or size. A band that IS served but
12548
+ whose duration or size is exceeded still reports
12549
+ `input_duration_exceeds_short_form` / `input_size_exceeds_short_form`.
12550
+ Emitted only once an operation pairs banded `short_form` with an
12551
+ enterable `long_form` (api `W6Y0dbg7`). Deliberately NOT spelled
12552
+ `resolution_band_not_served`: that is the REJECT reason
12553
+ (`ProcessingClassRejectReason`, no long_form to escalate to), and the
12554
+ two enums are kept disjoint.
12514
12555
  - `merge_re_encode_long_form` / `requires_reencode`: merge
12515
12556
  inputs require re-encoding so concat-fast-path is
12516
12557
  unavailable; `requires_reencode` cross-references ticket
@@ -12605,6 +12646,7 @@ components:
12605
12646
  - within_short_form_limits
12606
12647
  - input_size_exceeds_short_form
12607
12648
  - input_duration_exceeds_short_form
12649
+ - resolution_band_exceeds_short_form
12608
12650
  - merge_re_encode_long_form
12609
12651
  - requires_reencode
12610
12652
  - tier_policy
@@ -12616,6 +12658,15 @@ components:
12616
12658
  Per-job entry in the workflow's `processing_plan`. Server
12617
12659
  emits one entry per job in the workflow (including jobs that
12618
12660
  run on `short_form`).
12661
+ # A band-driven escalation names the band it escalated on (codex #687),
12662
+ # as the reject envelope does for resolution_band_not_served.
12663
+ if:
12664
+ properties:
12665
+ reason:
12666
+ const: resolution_band_exceeds_short_form
12667
+ required: [reason]
12668
+ then:
12669
+ required: [resolution_band]
12619
12670
  required:
12620
12671
  - job_id
12621
12672
  - processing_class
@@ -17032,11 +17083,14 @@ components:
17032
17083
  type: object
17033
17084
  additionalProperties: false
17034
17085
  description: |
17035
- Present on a class that CONCATENATES inputs without normalising
17036
- them (today `merge.video.long_form_re_encode`, ticket `MjzzPCWt`):
17037
- every input must share its stream layout (`structural`, a
17038
- permanent requirement) and its stream attributes (`attributes`,
17039
- until the heterogeneous re-encode ships). The names are the
17086
+ Present on a class whose worker refuses some input combinations
17087
+ it cannot concatenate: `merge.video.long_form_re_encode` (ticket
17088
+ `MjzzPCWt`) needs every input to share its stream layout
17089
+ (`structural`, a permanent requirement) and its stream attributes
17090
+ (`attributes`, until the heterogeneous re-encode ships);
17091
+ `merge.video.short_form_concat` (ticket `zO6vH8Ow`) re-encodes
17092
+ differing attributes but cannot mix inputs with and without audio
17093
+ (`structural` only, `attributes` empty). The names are the
17040
17094
  worker gate's reason vocabulary. A request that breaks it is
17041
17095
  refused at create with the `refusal` code where the API's upload
17042
17096
  probe can see the difference; the worker gate refuses the rest.