@giveitsmaller/contracts 0.81.0 → 0.82.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 (545) 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/anonymous-policy.yaml +41 -0
  5. package/availability/availability.json +20 -14
  6. package/code-builder/code-builder-metadata.json +18 -12
  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/AnonymousOperationNotAllowedResponse.d.ts +8 -6
  16. package/dist/openapi/models/AnonymousOperationNotAllowedResponse.js +1 -1
  17. package/dist/openapi/models/AnonymousQuotaExhaustedResponse.d.ts +1 -1
  18. package/dist/openapi/models/AnonymousQuotaExhaustedResponse.js +1 -1
  19. package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +1 -1
  20. package/dist/openapi/models/AudioWatermarkDecodeRequest.js +1 -1
  21. package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +1 -1
  22. package/dist/openapi/models/AudioWatermarkDecodeResponse.js +1 -1
  23. package/dist/openapi/models/AuthErrorResponse.d.ts +1 -1
  24. package/dist/openapi/models/AuthErrorResponse.js +1 -1
  25. package/dist/openapi/models/AuthErrorType.d.ts +1 -1
  26. package/dist/openapi/models/AuthErrorType.js +1 -1
  27. package/dist/openapi/models/AuthRejectionEnvelope.d.ts +1 -1
  28. package/dist/openapi/models/AuthRejectionEnvelope.js +1 -1
  29. package/dist/openapi/models/AuthenticatedIdentity.d.ts +1 -1
  30. package/dist/openapi/models/AuthenticatedIdentity.js +1 -1
  31. package/dist/openapi/models/AvailabilityValue.d.ts +1 -1
  32. package/dist/openapi/models/AvailabilityValue.js +1 -1
  33. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +1 -1
  34. package/dist/openapi/models/BalanceExhaustedResponse.js +1 -1
  35. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +1 -1
  36. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +1 -1
  37. package/dist/openapi/models/BillingCheckoutRequest.d.ts +1 -1
  38. package/dist/openapi/models/BillingCheckoutRequest.js +1 -1
  39. package/dist/openapi/models/BillingCheckoutSession.d.ts +1 -1
  40. package/dist/openapi/models/BillingCheckoutSession.js +1 -1
  41. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.d.ts +1 -1
  42. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.js +1 -1
  43. package/dist/openapi/models/CallbackEventType.d.ts +1 -1
  44. package/dist/openapi/models/CallbackEventType.js +1 -1
  45. package/dist/openapi/models/CancelAccountDeletion200Response.d.ts +1 -1
  46. package/dist/openapi/models/CancelAccountDeletion200Response.js +1 -1
  47. package/dist/openapi/models/CancelAccountDeletion200ResponseData.d.ts +1 -1
  48. package/dist/openapi/models/CancelAccountDeletion200ResponseData.js +1 -1
  49. package/dist/openapi/models/CapabilityCondition.d.ts +1 -1
  50. package/dist/openapi/models/CapabilityCondition.js +1 -1
  51. package/dist/openapi/models/CapabilityConditionOneOf.d.ts +1 -1
  52. package/dist/openapi/models/CapabilityConditionOneOf.js +1 -1
  53. package/dist/openapi/models/CapabilityConditionOneOf1.d.ts +1 -1
  54. package/dist/openapi/models/CapabilityConditionOneOf1.js +1 -1
  55. package/dist/openapi/models/CapabilityConditionOneOf2.d.ts +1 -1
  56. package/dist/openapi/models/CapabilityConditionOneOf2.js +1 -1
  57. package/dist/openapi/models/CapabilityConditionOneOf3.d.ts +1 -1
  58. package/dist/openapi/models/CapabilityConditionOneOf3.js +1 -1
  59. package/dist/openapi/models/CapabilityConditionOneOf4.d.ts +1 -1
  60. package/dist/openapi/models/CapabilityConditionOneOf4.js +1 -1
  61. package/dist/openapi/models/CapabilityConditionOneOf5.d.ts +1 -1
  62. package/dist/openapi/models/CapabilityConditionOneOf5.js +1 -1
  63. package/dist/openapi/models/CapabilityConditionOneOf6.d.ts +1 -1
  64. package/dist/openapi/models/CapabilityConditionOneOf6.js +1 -1
  65. package/dist/openapi/models/CapabilityConstraint.d.ts +1 -1
  66. package/dist/openapi/models/CapabilityConstraint.js +1 -1
  67. package/dist/openapi/models/CapabilityInputSpec.d.ts +1 -1
  68. package/dist/openapi/models/CapabilityInputSpec.js +1 -1
  69. package/dist/openapi/models/CapabilityProduces.d.ts +1 -1
  70. package/dist/openapi/models/CapabilityProduces.js +1 -1
  71. package/dist/openapi/models/CapabilityProducesOneOf.d.ts +1 -1
  72. package/dist/openapi/models/CapabilityProducesOneOf.js +1 -1
  73. package/dist/openapi/models/CapabilityProducesOneOf1.d.ts +1 -1
  74. package/dist/openapi/models/CapabilityProducesOneOf1.js +1 -1
  75. package/dist/openapi/models/CapabilityProducesOneOf2.d.ts +1 -1
  76. package/dist/openapi/models/CapabilityProducesOneOf2.js +1 -1
  77. package/dist/openapi/models/ChangePasswordRequest.d.ts +1 -1
  78. package/dist/openapi/models/ChangePasswordRequest.js +1 -1
  79. package/dist/openapi/models/CheckoutSessionStatusResponse.d.ts +1 -1
  80. package/dist/openapi/models/CheckoutSessionStatusResponse.js +1 -1
  81. package/dist/openapi/models/CheckoutSessionStatusResponseData.d.ts +1 -1
  82. package/dist/openapi/models/CheckoutSessionStatusResponseData.js +1 -1
  83. package/dist/openapi/models/CodegenSource.d.ts +1 -1
  84. package/dist/openapi/models/CodegenSource.js +1 -1
  85. package/dist/openapi/models/CodegenSourceInput.d.ts +1 -1
  86. package/dist/openapi/models/CodegenSourceInput.js +1 -1
  87. package/dist/openapi/models/CodegenSourceJob.d.ts +1 -1
  88. package/dist/openapi/models/CodegenSourceJob.js +1 -1
  89. package/dist/openapi/models/CodegenSourceJobSource.d.ts +1 -1
  90. package/dist/openapi/models/CodegenSourceJobSource.js +1 -1
  91. package/dist/openapi/models/CodegenSourceOperation.d.ts +1 -1
  92. package/dist/openapi/models/CodegenSourceOperation.js +1 -1
  93. package/dist/openapi/models/CodegenUploadPlaceholder.d.ts +1 -1
  94. package/dist/openapi/models/CodegenUploadPlaceholder.js +1 -1
  95. package/dist/openapi/models/CompositionPlan.d.ts +1 -1
  96. package/dist/openapi/models/CompositionPlan.js +1 -1
  97. package/dist/openapi/models/CompositionPlanJob.d.ts +1 -1
  98. package/dist/openapi/models/CompositionPlanJob.js +1 -1
  99. package/dist/openapi/models/CompositionPlanOperation.d.ts +1 -1
  100. package/dist/openapi/models/CompositionPlanOperation.js +1 -1
  101. package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +1 -1
  102. package/dist/openapi/models/ConfirmEmailChange200Response.js +1 -1
  103. package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +1 -1
  104. package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +1 -1
  105. package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +1 -1
  106. package/dist/openapi/models/ConfirmEmailChangeRequest.js +1 -1
  107. package/dist/openapi/models/ConnectionSource.d.ts +1 -1
  108. package/dist/openapi/models/ConnectionSource.js +1 -1
  109. package/dist/openapi/models/ContactRequest.d.ts +1 -1
  110. package/dist/openapi/models/ContactRequest.js +1 -1
  111. package/dist/openapi/models/ContactSubject.d.ts +1 -1
  112. package/dist/openapi/models/ContactSubject.js +1 -1
  113. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +1 -1
  114. package/dist/openapi/models/ContactValidationErrorResponse.js +1 -1
  115. package/dist/openapi/models/CreateApiKey201Response.d.ts +1 -1
  116. package/dist/openapi/models/CreateApiKey201Response.js +1 -1
  117. package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +1 -1
  118. package/dist/openapi/models/CreateApiKey201ResponseData.js +1 -1
  119. package/dist/openapi/models/CreateApiKeyRequest.d.ts +1 -1
  120. package/dist/openapi/models/CreateApiKeyRequest.js +1 -1
  121. package/dist/openapi/models/CreateBillingCheckoutSession422Response.d.ts +1 -1
  122. package/dist/openapi/models/CreateBillingCheckoutSession422Response.js +1 -1
  123. package/dist/openapi/models/CreateExternalImport403Response.d.ts +1 -1
  124. package/dist/openapi/models/CreateExternalImport403Response.js +1 -1
  125. package/dist/openapi/models/CreateExternalImport422Response.d.ts +1 -1
  126. package/dist/openapi/models/CreateExternalImport422Response.js +1 -1
  127. package/dist/openapi/models/CreateWorkflow401Response.d.ts +1 -1
  128. package/dist/openapi/models/CreateWorkflow401Response.js +1 -1
  129. package/dist/openapi/models/CreateWorkflow403Response.d.ts +1 -1
  130. package/dist/openapi/models/CreateWorkflow403Response.js +1 -1
  131. package/dist/openapi/models/CreateWorkflow422Response.d.ts +1 -1
  132. package/dist/openapi/models/CreateWorkflow422Response.js +1 -1
  133. package/dist/openapi/models/CreditTransaction.d.ts +1 -1
  134. package/dist/openapi/models/CreditTransaction.js +1 -1
  135. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +1 -1
  136. package/dist/openapi/models/CreditTransactionSourceBucket.js +1 -1
  137. package/dist/openapi/models/CreditsBalanceResponse.d.ts +1 -1
  138. package/dist/openapi/models/CreditsBalanceResponse.js +1 -1
  139. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +1 -1
  140. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +1 -1
  141. package/dist/openapi/models/CreditsUsageResponse.d.ts +1 -1
  142. package/dist/openapi/models/CreditsUsageResponse.js +1 -1
  143. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +1 -1
  144. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +1 -1
  145. package/dist/openapi/models/Delivery.d.ts +1 -1
  146. package/dist/openapi/models/Delivery.js +1 -1
  147. package/dist/openapi/models/DeliveryOutputRef.d.ts +1 -1
  148. package/dist/openapi/models/DeliveryOutputRef.js +1 -1
  149. package/dist/openapi/models/DeliveryPlan.d.ts +1 -1
  150. package/dist/openapi/models/DeliveryPlan.js +1 -1
  151. package/dist/openapi/models/DeliveryPlanOutput.d.ts +1 -1
  152. package/dist/openapi/models/DeliveryPlanOutput.js +1 -1
  153. package/dist/openapi/models/DeliveryPlanReason.d.ts +1 -1
  154. package/dist/openapi/models/DeliveryPlanReason.js +1 -1
  155. package/dist/openapi/models/DeliverySelection.d.ts +1 -1
  156. package/dist/openapi/models/DeliverySelection.js +1 -1
  157. package/dist/openapi/models/DownloadBundle.d.ts +1 -1
  158. package/dist/openapi/models/DownloadBundle.js +1 -1
  159. package/dist/openapi/models/DroppedOption.d.ts +1 -1
  160. package/dist/openapi/models/DroppedOption.js +1 -1
  161. package/dist/openapi/models/EmailNotify.d.ts +1 -1
  162. package/dist/openapi/models/EmailNotify.js +1 -1
  163. package/dist/openapi/models/EmptySuccessEnvelope.d.ts +1 -1
  164. package/dist/openapi/models/EmptySuccessEnvelope.js +1 -1
  165. package/dist/openapi/models/EndpointProjection.d.ts +1 -1
  166. package/dist/openapi/models/EndpointProjection.js +1 -1
  167. package/dist/openapi/models/EndpointProjectionServersInner.d.ts +1 -1
  168. package/dist/openapi/models/EndpointProjectionServersInner.js +1 -1
  169. package/dist/openapi/models/ErrorEnvelope.d.ts +1 -1
  170. package/dist/openapi/models/ErrorEnvelope.js +1 -1
  171. package/dist/openapi/models/EstimateQuality.d.ts +1 -1
  172. package/dist/openapi/models/EstimateQuality.js +1 -1
  173. package/dist/openapi/models/EstimateRange.d.ts +1 -1
  174. package/dist/openapi/models/EstimateRange.js +1 -1
  175. package/dist/openapi/models/ExportAccountData200Response.d.ts +1 -1
  176. package/dist/openapi/models/ExportAccountData200Response.js +1 -1
  177. package/dist/openapi/models/ExportAccountData200ResponseData.d.ts +1 -1
  178. package/dist/openapi/models/ExportAccountData200ResponseData.js +1 -1
  179. package/dist/openapi/models/ExportAccountData200ResponseDataBilling.d.ts +1 -1
  180. package/dist/openapi/models/ExportAccountData200ResponseDataBilling.js +1 -1
  181. package/dist/openapi/models/ExportAccountData200ResponseDataBillingCheckoutSessionsInner.d.ts +1 -1
  182. package/dist/openapi/models/ExportAccountData200ResponseDataBillingCheckoutSessionsInner.js +1 -1
  183. package/dist/openapi/models/ExternalDestination.d.ts +1 -1
  184. package/dist/openapi/models/ExternalDestination.js +1 -1
  185. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +1 -1
  186. package/dist/openapi/models/ExternalImportCreatedResponse.js +1 -1
  187. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +1 -1
  188. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +1 -1
  189. package/dist/openapi/models/ExternalImportRequest.d.ts +1 -1
  190. package/dist/openapi/models/ExternalImportRequest.js +1 -1
  191. package/dist/openapi/models/ExternalImportToken.d.ts +1 -1
  192. package/dist/openapi/models/ExternalImportToken.js +1 -1
  193. package/dist/openapi/models/ExternalSource.d.ts +1 -1
  194. package/dist/openapi/models/ExternalSource.js +1 -1
  195. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +1 -1
  196. package/dist/openapi/models/FeatureNotAvailableResponse.js +1 -1
  197. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +1 -1
  198. package/dist/openapi/models/FeatureTierRestrictedResponse.js +1 -1
  199. package/dist/openapi/models/FeatureViolation.d.ts +1 -1
  200. package/dist/openapi/models/FeatureViolation.js +1 -1
  201. package/dist/openapi/models/GetProfile200Response.d.ts +1 -1
  202. package/dist/openapi/models/GetProfile200Response.js +1 -1
  203. package/dist/openapi/models/GetProfile200ResponseData.d.ts +1 -1
  204. package/dist/openapi/models/GetProfile200ResponseData.js +1 -1
  205. package/dist/openapi/models/ImageEncodeCapabilities.d.ts +1 -1
  206. package/dist/openapi/models/ImageEncodeCapabilities.js +1 -1
  207. package/dist/openapi/models/JobDefinition.d.ts +1 -1
  208. package/dist/openapi/models/JobDefinition.js +1 -1
  209. package/dist/openapi/models/JobDownload.d.ts +1 -1
  210. package/dist/openapi/models/JobDownload.js +1 -1
  211. package/dist/openapi/models/JobInputV2.d.ts +1 -1
  212. package/dist/openapi/models/JobInputV2.js +1 -1
  213. package/dist/openapi/models/JobMediaClass.d.ts +1 -1
  214. package/dist/openapi/models/JobMediaClass.js +1 -1
  215. package/dist/openapi/models/JobOutputSource.d.ts +1 -1
  216. package/dist/openapi/models/JobOutputSource.js +1 -1
  217. package/dist/openapi/models/JobResponse.d.ts +1 -1
  218. package/dist/openapi/models/JobResponse.js +1 -1
  219. package/dist/openapi/models/JobStatus.d.ts +1 -1
  220. package/dist/openapi/models/JobStatus.js +1 -1
  221. package/dist/openapi/models/JobType.d.ts +1 -1
  222. package/dist/openapi/models/JobType.js +1 -1
  223. package/dist/openapi/models/LivenessResponse.d.ts +1 -1
  224. package/dist/openapi/models/LivenessResponse.js +1 -1
  225. package/dist/openapi/models/LoginUser200Response.d.ts +1 -1
  226. package/dist/openapi/models/LoginUser200Response.js +1 -1
  227. package/dist/openapi/models/LoginUser200ResponseData.d.ts +1 -1
  228. package/dist/openapi/models/LoginUser200ResponseData.js +1 -1
  229. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +1 -1
  230. package/dist/openapi/models/LoginUser200ResponseDataUser.js +1 -1
  231. package/dist/openapi/models/LoginUser401Response.d.ts +1 -1
  232. package/dist/openapi/models/LoginUser401Response.js +1 -1
  233. package/dist/openapi/models/LoginUserRequest.d.ts +1 -1
  234. package/dist/openapi/models/LoginUserRequest.js +1 -1
  235. package/dist/openapi/models/LongFormConcurrencyLimitResponse.d.ts +1 -1
  236. package/dist/openapi/models/LongFormConcurrencyLimitResponse.js +1 -1
  237. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.d.ts +1 -1
  238. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.js +1 -1
  239. package/dist/openapi/models/MetadataResponse.d.ts +1 -1
  240. package/dist/openapi/models/MetadataResponse.js +1 -1
  241. package/dist/openapi/models/MetadataResponseDimensions.d.ts +1 -1
  242. package/dist/openapi/models/MetadataResponseDimensions.js +1 -1
  243. package/dist/openapi/models/MetadataResponseExif.d.ts +1 -1
  244. package/dist/openapi/models/MetadataResponseExif.js +1 -1
  245. package/dist/openapi/models/MetadataResponseExifGps.d.ts +1 -1
  246. package/dist/openapi/models/MetadataResponseExifGps.js +1 -1
  247. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +1 -1
  248. package/dist/openapi/models/MetadataSuccessEnvelope.js +1 -1
  249. package/dist/openapi/models/MimeGroupSchema.d.ts +38 -1
  250. package/dist/openapi/models/MimeGroupSchema.js +3 -1
  251. package/dist/openapi/models/MultiInputSource.d.ts +1 -1
  252. package/dist/openapi/models/MultiInputSource.js +1 -1
  253. package/dist/openapi/models/MultipartCompleteRequest.d.ts +1 -1
  254. package/dist/openapi/models/MultipartCompleteRequest.js +1 -1
  255. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +1 -1
  256. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +1 -1
  257. package/dist/openapi/models/MultipartCompleteResponse.d.ts +1 -1
  258. package/dist/openapi/models/MultipartCompleteResponse.js +1 -1
  259. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +1 -1
  260. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +1 -1
  261. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +1 -1
  262. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +1 -1
  263. package/dist/openapi/models/MultipartInitiateResponse.d.ts +1 -1
  264. package/dist/openapi/models/MultipartInitiateResponse.js +1 -1
  265. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +1 -1
  266. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +1 -1
  267. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +1 -1
  268. package/dist/openapi/models/MultipartKeepaliveResponse.js +1 -1
  269. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +1 -1
  270. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +1 -1
  271. package/dist/openapi/models/MultipartPartListing.d.ts +1 -1
  272. package/dist/openapi/models/MultipartPartListing.js +1 -1
  273. package/dist/openapi/models/MultipartPresignRequest.d.ts +1 -1
  274. package/dist/openapi/models/MultipartPresignRequest.js +1 -1
  275. package/dist/openapi/models/MultipartPresignResponse.d.ts +1 -1
  276. package/dist/openapi/models/MultipartPresignResponse.js +1 -1
  277. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +1 -1
  278. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +1 -1
  279. package/dist/openapi/models/MultipartStatusResponse.d.ts +1 -1
  280. package/dist/openapi/models/MultipartStatusResponse.js +1 -1
  281. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +1 -1
  282. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +1 -1
  283. package/dist/openapi/models/NotifyConfig.d.ts +1 -1
  284. package/dist/openapi/models/NotifyConfig.js +1 -1
  285. package/dist/openapi/models/OperationCapability.d.ts +1 -1
  286. package/dist/openapi/models/OperationCapability.js +1 -1
  287. package/dist/openapi/models/OperationDefinition.d.ts +1 -1
  288. package/dist/openapi/models/OperationDefinition.js +1 -1
  289. package/dist/openapi/models/OperationDownload.d.ts +1 -1
  290. package/dist/openapi/models/OperationDownload.js +1 -1
  291. package/dist/openapi/models/OperationInputModel.d.ts +1 -1
  292. package/dist/openapi/models/OperationInputModel.js +1 -1
  293. package/dist/openapi/models/OperationMessageParamsValue.d.ts +1 -1
  294. package/dist/openapi/models/OperationMessageParamsValue.js +1 -1
  295. package/dist/openapi/models/OperationResponse.d.ts +1 -1
  296. package/dist/openapi/models/OperationResponse.js +1 -1
  297. package/dist/openapi/models/OperationResult.d.ts +1 -1
  298. package/dist/openapi/models/OperationResult.js +1 -1
  299. package/dist/openapi/models/OperationResultMetadata.d.ts +1 -1
  300. package/dist/openapi/models/OperationResultMetadata.js +1 -1
  301. package/dist/openapi/models/OperationResultMetrics.d.ts +1 -1
  302. package/dist/openapi/models/OperationResultMetrics.js +1 -1
  303. package/dist/openapi/models/OperationSchemaDefinition.d.ts +1 -1
  304. package/dist/openapi/models/OperationSchemaDefinition.js +1 -1
  305. package/dist/openapi/models/OperationStatus.d.ts +1 -1
  306. package/dist/openapi/models/OperationStatus.js +1 -1
  307. package/dist/openapi/models/OperationType.d.ts +1 -1
  308. package/dist/openapi/models/OperationType.js +1 -1
  309. package/dist/openapi/models/OperationsSchemaResponse.d.ts +1 -1
  310. package/dist/openapi/models/OperationsSchemaResponse.js +1 -1
  311. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +1 -1
  312. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +1 -1
  313. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +1 -1
  314. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +1 -1
  315. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +1 -1
  316. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +1 -1
  317. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +1 -1
  318. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +1 -1
  319. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.d.ts +1 -1
  320. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.js +1 -1
  321. package/dist/openapi/models/OptionSchema.d.ts +1 -1
  322. package/dist/openapi/models/OptionSchema.js +1 -1
  323. package/dist/openapi/models/OutputProperties.d.ts +1 -1
  324. package/dist/openapi/models/OutputProperties.js +1 -1
  325. package/dist/openapi/models/OutputPropertiesIsAnimated.d.ts +1 -1
  326. package/dist/openapi/models/OutputPropertiesIsAnimated.js +1 -1
  327. package/dist/openapi/models/PerClassAvailabilityEntry.d.ts +1 -1
  328. package/dist/openapi/models/PerClassAvailabilityEntry.js +1 -1
  329. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +1 -1
  330. package/dist/openapi/models/PerRoleCardinalityEntry.js +1 -1
  331. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +1 -1
  332. package/dist/openapi/models/PerValueAvailabilityEntry.js +1 -1
  333. package/dist/openapi/models/PresignedUrlPart.d.ts +1 -1
  334. package/dist/openapi/models/PresignedUrlPart.js +1 -1
  335. package/dist/openapi/models/ProbePendingResponse.d.ts +1 -1
  336. package/dist/openapi/models/ProbePendingResponse.js +1 -1
  337. package/dist/openapi/models/ProcessingClass.d.ts +1 -1
  338. package/dist/openapi/models/ProcessingClass.js +1 -1
  339. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +1 -1
  340. package/dist/openapi/models/ProcessingClassBandViolation.js +1 -1
  341. package/dist/openapi/models/ProcessingClassConstraints.d.ts +1 -1
  342. package/dist/openapi/models/ProcessingClassConstraints.js +1 -1
  343. package/dist/openapi/models/ProcessingClassEntry.d.ts +1 -1
  344. package/dist/openapi/models/ProcessingClassEntry.js +1 -1
  345. package/dist/openapi/models/ProcessingClassEntryInputUniformity.d.ts +1 -1
  346. package/dist/openapi/models/ProcessingClassEntryInputUniformity.js +1 -1
  347. package/dist/openapi/models/ProcessingClassEntryResolutionBands.d.ts +1 -1
  348. package/dist/openapi/models/ProcessingClassEntryResolutionBands.js +1 -1
  349. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +1 -1
  350. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +1 -1
  351. package/dist/openapi/models/ProcessingClassHint.d.ts +1 -1
  352. package/dist/openapi/models/ProcessingClassHint.js +1 -1
  353. package/dist/openapi/models/ProcessingClassReason.d.ts +1 -1
  354. package/dist/openapi/models/ProcessingClassReason.js +1 -1
  355. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +1 -1
  356. package/dist/openapi/models/ProcessingClassRejectReason.js +1 -1
  357. package/dist/openapi/models/ProcessingPlan.d.ts +1 -1
  358. package/dist/openapi/models/ProcessingPlan.js +1 -1
  359. package/dist/openapi/models/ProcessingPlanJob.d.ts +1 -1
  360. package/dist/openapi/models/ProcessingPlanJob.js +1 -1
  361. package/dist/openapi/models/ReEncodeDecision.d.ts +1 -1
  362. package/dist/openapi/models/ReEncodeDecision.js +1 -1
  363. package/dist/openapi/models/ReadinessResponse.d.ts +1 -1
  364. package/dist/openapi/models/ReadinessResponse.js +1 -1
  365. package/dist/openapi/models/RegisterUser422Response.d.ts +1 -1
  366. package/dist/openapi/models/RegisterUser422Response.js +1 -1
  367. package/dist/openapi/models/RegisterUserRequest.d.ts +1 -1
  368. package/dist/openapi/models/RegisterUserRequest.js +1 -1
  369. package/dist/openapi/models/RequestAccountDeletion200Response.d.ts +1 -1
  370. package/dist/openapi/models/RequestAccountDeletion200Response.js +1 -1
  371. package/dist/openapi/models/RequestAccountDeletion200ResponseData.d.ts +1 -1
  372. package/dist/openapi/models/RequestAccountDeletion200ResponseData.js +1 -1
  373. package/dist/openapi/models/RequestAccountDeletionRequest.d.ts +1 -1
  374. package/dist/openapi/models/RequestAccountDeletionRequest.js +1 -1
  375. package/dist/openapi/models/ResendVerificationEmailRequest.d.ts +1 -1
  376. package/dist/openapi/models/ResendVerificationEmailRequest.js +1 -1
  377. package/dist/openapi/models/ResetPasswordRequest.d.ts +1 -1
  378. package/dist/openapi/models/ResetPasswordRequest.js +1 -1
  379. package/dist/openapi/models/ResolutionBand.d.ts +1 -1
  380. package/dist/openapi/models/ResolutionBand.js +1 -1
  381. package/dist/openapi/models/ResolutionBandCeiling.d.ts +1 -1
  382. package/dist/openapi/models/ResolutionBandCeiling.js +1 -1
  383. package/dist/openapi/models/ResolutionBandCeilingConstraints.d.ts +1 -1
  384. package/dist/openapi/models/ResolutionBandCeilingConstraints.js +1 -1
  385. package/dist/openapi/models/ResolutionBandCeilingDerivation.d.ts +1 -1
  386. package/dist/openapi/models/ResolutionBandCeilingDerivation.js +1 -1
  387. package/dist/openapi/models/ResponseEnvelope.d.ts +1 -1
  388. package/dist/openapi/models/ResponseEnvelope.js +1 -1
  389. package/dist/openapi/models/RetryResponse.d.ts +1 -1
  390. package/dist/openapi/models/RetryResponse.js +1 -1
  391. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +1 -1
  392. package/dist/openapi/models/RetrySuccessEnvelope.js +1 -1
  393. package/dist/openapi/models/SseCompletionBase.d.ts +1 -1
  394. package/dist/openapi/models/SseCompletionBase.js +1 -1
  395. package/dist/openapi/models/SseConnectionLimitResponse.d.ts +1 -1
  396. package/dist/openapi/models/SseConnectionLimitResponse.js +1 -1
  397. package/dist/openapi/models/SseEventType.d.ts +1 -1
  398. package/dist/openapi/models/SseEventType.js +1 -1
  399. package/dist/openapi/models/SseJobCompletedData.d.ts +1 -1
  400. package/dist/openapi/models/SseJobCompletedData.js +1 -1
  401. package/dist/openapi/models/SseJobFailedData.d.ts +1 -1
  402. package/dist/openapi/models/SseJobFailedData.js +1 -1
  403. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +1 -1
  404. package/dist/openapi/models/SseMultiOutputCompletion.js +1 -1
  405. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +1 -1
  406. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +1 -1
  407. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +1 -1
  408. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +1 -1
  409. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +1 -1
  410. package/dist/openapi/models/SseMultiOutputResultEntry.js +1 -1
  411. package/dist/openapi/models/SseOperationCompletedData.d.ts +1 -1
  412. package/dist/openapi/models/SseOperationCompletedData.js +1 -1
  413. package/dist/openapi/models/SseOperationCompletionResult.d.ts +1 -1
  414. package/dist/openapi/models/SseOperationCompletionResult.js +1 -1
  415. package/dist/openapi/models/SseOperationFailedData.d.ts +1 -1
  416. package/dist/openapi/models/SseOperationFailedData.js +1 -1
  417. package/dist/openapi/models/SseOperationProgressData.d.ts +1 -1
  418. package/dist/openapi/models/SseOperationProgressData.js +1 -1
  419. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +1 -1
  420. package/dist/openapi/models/SseSingleOutputCompletion.js +1 -1
  421. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +1 -1
  422. package/dist/openapi/models/SseWorkflowTerminalData.js +1 -1
  423. package/dist/openapi/models/TierRestrictionKind.d.ts +1 -1
  424. package/dist/openapi/models/TierRestrictionKind.js +1 -1
  425. package/dist/openapi/models/TierRestrictionResponse.d.ts +1 -1
  426. package/dist/openapi/models/TierRestrictionResponse.js +1 -1
  427. package/dist/openapi/models/UpdateProfile200Response.d.ts +1 -1
  428. package/dist/openapi/models/UpdateProfile200Response.js +1 -1
  429. package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +1 -1
  430. package/dist/openapi/models/UpdateProfile200ResponseData.js +1 -1
  431. package/dist/openapi/models/UpdateProfile422Response.d.ts +1 -1
  432. package/dist/openapi/models/UpdateProfile422Response.js +1 -1
  433. package/dist/openapi/models/UpdateProfileRequest.d.ts +1 -1
  434. package/dist/openapi/models/UpdateProfileRequest.js +1 -1
  435. package/dist/openapi/models/UploadConstraintsApplied.d.ts +1 -1
  436. package/dist/openapi/models/UploadConstraintsApplied.js +1 -1
  437. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +1 -1
  438. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +1 -1
  439. package/dist/openapi/models/UploadFile403Response.d.ts +1 -1
  440. package/dist/openapi/models/UploadFile403Response.js +1 -1
  441. package/dist/openapi/models/UploadFile422Response.d.ts +1 -1
  442. package/dist/openapi/models/UploadFile422Response.js +1 -1
  443. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +1 -1
  444. package/dist/openapi/models/UploadProbeMediaMetadata.js +1 -1
  445. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +1 -1
  446. package/dist/openapi/models/UploadProbeProcessingClass.js +1 -1
  447. package/dist/openapi/models/UploadProbeResponse.d.ts +1 -1
  448. package/dist/openapi/models/UploadProbeResponse.js +1 -1
  449. package/dist/openapi/models/UploadProbeStatus.d.ts +1 -1
  450. package/dist/openapi/models/UploadProbeStatus.js +1 -1
  451. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +1 -1
  452. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +1 -1
  453. package/dist/openapi/models/UploadResponse.d.ts +1 -1
  454. package/dist/openapi/models/UploadResponse.js +1 -1
  455. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +1 -1
  456. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +1 -1
  457. package/dist/openapi/models/UploadSource.d.ts +1 -1
  458. package/dist/openapi/models/UploadSource.js +1 -1
  459. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +1 -1
  460. package/dist/openapi/models/UploadSuccessEnvelope.js +1 -1
  461. package/dist/openapi/models/UploadThresholds.d.ts +1 -1
  462. package/dist/openapi/models/UploadThresholds.js +1 -1
  463. package/dist/openapi/models/UserTier.d.ts +1 -1
  464. package/dist/openapi/models/UserTier.js +1 -1
  465. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +1 -1
  466. package/dist/openapi/models/ValidationErrorEnvelope.js +1 -1
  467. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +1 -1
  468. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +1 -1
  469. package/dist/openapi/models/VerifyEmailRequest.d.ts +1 -1
  470. package/dist/openapi/models/VerifyEmailRequest.js +1 -1
  471. package/dist/openapi/models/WarningType.d.ts +1 -1
  472. package/dist/openapi/models/WarningType.js +1 -1
  473. package/dist/openapi/models/WebhookOperationContext.d.ts +1 -1
  474. package/dist/openapi/models/WebhookOperationContext.js +1 -1
  475. package/dist/openapi/models/WebhookPayload.d.ts +1 -1
  476. package/dist/openapi/models/WebhookPayload.js +1 -1
  477. package/dist/openapi/models/WorkflowArchiveResponse.d.ts +1 -1
  478. package/dist/openapi/models/WorkflowArchiveResponse.js +1 -1
  479. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.d.ts +1 -1
  480. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.js +1 -1
  481. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +1 -1
  482. package/dist/openapi/models/WorkflowCancelBillingEffect.js +1 -1
  483. package/dist/openapi/models/WorkflowCancelResponse.d.ts +1 -1
  484. package/dist/openapi/models/WorkflowCancelResponse.js +1 -1
  485. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +1 -1
  486. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +1 -1
  487. package/dist/openapi/models/WorkflowCreateRequest.d.ts +1 -1
  488. package/dist/openapi/models/WorkflowCreateRequest.js +1 -1
  489. package/dist/openapi/models/WorkflowCreateResponse.d.ts +1 -1
  490. package/dist/openapi/models/WorkflowCreateResponse.js +1 -1
  491. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +1 -1
  492. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +1 -1
  493. package/dist/openapi/models/WorkflowCreditSummary.d.ts +1 -1
  494. package/dist/openapi/models/WorkflowCreditSummary.js +1 -1
  495. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +1 -1
  496. package/dist/openapi/models/WorkflowDownloadResponse.js +1 -1
  497. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +1 -1
  498. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +1 -1
  499. package/dist/openapi/models/WorkflowEdge.d.ts +1 -1
  500. package/dist/openapi/models/WorkflowEdge.js +1 -1
  501. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +1 -1
  502. package/dist/openapi/models/WorkflowExpiredResponse.js +1 -1
  503. package/dist/openapi/models/WorkflowListResponse.d.ts +1 -1
  504. package/dist/openapi/models/WorkflowListResponse.js +1 -1
  505. package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +1 -1
  506. package/dist/openapi/models/WorkflowListSuccessEnvelope.js +1 -1
  507. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +1 -1
  508. package/dist/openapi/models/WorkflowPauseRequiredAction.js +1 -1
  509. package/dist/openapi/models/WorkflowPausedDetail.d.ts +1 -1
  510. package/dist/openapi/models/WorkflowPausedDetail.js +1 -1
  511. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +1 -1
  512. package/dist/openapi/models/WorkflowPausedDetailLinks.js +1 -1
  513. package/dist/openapi/models/WorkflowProcessing.d.ts +1 -1
  514. package/dist/openapi/models/WorkflowProcessing.js +1 -1
  515. package/dist/openapi/models/WorkflowRestoreResponse.d.ts +1 -1
  516. package/dist/openapi/models/WorkflowRestoreResponse.js +1 -1
  517. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.d.ts +1 -1
  518. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.js +1 -1
  519. package/dist/openapi/models/WorkflowResumeResponse.d.ts +1 -1
  520. package/dist/openapi/models/WorkflowResumeResponse.js +1 -1
  521. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +1 -1
  522. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +1 -1
  523. package/dist/openapi/models/WorkflowSource.d.ts +1 -1
  524. package/dist/openapi/models/WorkflowSource.js +1 -1
  525. package/dist/openapi/models/WorkflowStatus.d.ts +1 -1
  526. package/dist/openapi/models/WorkflowStatus.js +1 -1
  527. package/dist/openapi/models/WorkflowStatusResponse.d.ts +1 -1
  528. package/dist/openapi/models/WorkflowStatusResponse.js +1 -1
  529. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +1 -1
  530. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +1 -1
  531. package/dist/openapi/models/WorkflowSummary.d.ts +1 -1
  532. package/dist/openapi/models/WorkflowSummary.js +1 -1
  533. package/dist/openapi/models/WorkflowSummaryJob.d.ts +1 -1
  534. package/dist/openapi/models/WorkflowSummaryJob.js +1 -1
  535. package/dist/openapi/models/WorkflowWarning.d.ts +1 -1
  536. package/dist/openapi/models/WorkflowWarning.js +1 -1
  537. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +1 -1
  538. package/dist/openapi/models/WorkflowWarningSeverity.js +1 -1
  539. package/dist/openapi/runtime.d.ts +1 -1
  540. package/dist/openapi/runtime.js +1 -1
  541. package/openapi/api.yaml +90 -24
  542. package/operation-capabilities/operation-capabilities.json +1 -1
  543. package/operations/schemas/compress.yaml +54 -26
  544. package/operations/schemas/merge.yaml +22 -1
  545. package/package.json +6 -4
@@ -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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.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.216.0
7
+ * The version of the OpenAPI document: 2.217.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.216.0
5
+ * The version of the OpenAPI document: 2.217.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -103,6 +103,43 @@ export interface MimeGroupSchema {
103
103
  ceilingBasis?: {
104
104
  [key: string]: MimeGroupSchemaCeilingBasisEnum;
105
105
  };
106
+ /**
107
+ * The largest INPUT image, in decoded pixels (width x height), that
108
+ * this group's worker is declared to process (owner decision
109
+ * 607(d), 2026-09-26: decode memory, not bytes, binds for raster
110
+ * images). Present only where it was measured.
111
+ *
112
+ * WHICH PIXEL CEILING BINDS WHEN. There are three, at three stages:
113
+ * 1. UPLOAD, single-shot: `limits.max_upload_image_pixels`
114
+ * (default 16 MP; API setting `UPLOAD_MAX_IMAGE_PIXELS`), 413
115
+ * `IMAGE_DIMENSIONS_TOO_LARGE`.
116
+ * 2. UPLOAD, multipart: `limits.max_multipart_upload_image_pixels`
117
+ * (default 50 MP; admits a 24 MP phone photo), same 413.
118
+ * 3. OPERATION: this field, the worker's declared decode ceiling. The
119
+ * worker refuses above it (`input_too_large`, header-only, before
120
+ * decoding); the API is to check it at workflow create too (api
121
+ * card, co-land), after which it refuses before any job runs.
122
+ * An uploaded image passes its upload gate first, so it meets
123
+ * `min(upload ceiling, this field)`. Every value declared here is at
124
+ * least 75 MP, above both upload defaults, so today the UPLOAD
125
+ * ceiling binds for uploads, and this field binds for inputs that
126
+ * did not come through an upload gate (another job's output, an
127
+ * import), or if an upload ceiling is raised past it. A 24 MP photo
128
+ * passes all three.
129
+ *
130
+ * THE VALUE IS AN UPPER BOUND, NOT A GUARANTEE FOR EVERY IMAGE. Where
131
+ * the worker's real limit is a decode-memory budget, images with more
132
+ * bytes per pixel (alpha, 16-bit channels) hit it at fewer pixels,
133
+ * and the worker refuses them with `input_too_large` (typed, not
134
+ * retryable, before any billed work) below this field. PNG is the
135
+ * measured case: 100 MP is the 8-bit RGBA value; 16-bit RGB reaches
136
+ * the budget near 67 MP and 16-bit RGBA near 50 MP. A pre-flight
137
+ * check against this field therefore cannot promise acceptance.
138
+ *
139
+ * @type {number}
140
+ * @memberof MimeGroupSchema
141
+ */
142
+ maxInputPixels?: number;
106
143
  /**
107
144
  * Optional mime-group-level INPUT-file size ceiling in BYTES
108
145
  * (ticket [`uKsFzORi`](https://trello.com/c/uKsFzORi)). Sibling of
@@ -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.216.0
7
+ * The version of the OpenAPI document: 2.217.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -53,6 +53,7 @@ export function MimeGroupSchemaFromJSONTyped(json, ignoreDiscriminator) {
53
53
  'requiredTier': json['required_tier'] == null ? undefined : UserTierFromJSON(json['required_tier']),
54
54
  'perMimeAvailability': json['per_mime_availability'] == null ? undefined : (mapValues(json['per_mime_availability'], PerValueAvailabilityEntryFromJSON)),
55
55
  'ceilingBasis': json['ceiling_basis'] == null ? undefined : json['ceiling_basis'],
56
+ 'maxInputPixels': json['max_input_pixels'] == null ? undefined : json['max_input_pixels'],
56
57
  'maxInputSizeBytes': json['max_input_size_bytes'] == null ? undefined : json['max_input_size_bytes'],
57
58
  'maxOutputPixels': json['max_output_pixels'] == null ? undefined : json['max_output_pixels'],
58
59
  'inputSizeBound': json['input_size_bound'] == null ? undefined : json['input_size_bound'],
@@ -75,6 +76,7 @@ export function MimeGroupSchemaToJSONTyped(value, ignoreDiscriminator = false) {
75
76
  'required_tier': UserTierToJSON(value['requiredTier']),
76
77
  'per_mime_availability': value['perMimeAvailability'] == null ? undefined : (mapValues(value['perMimeAvailability'], PerValueAvailabilityEntryToJSON)),
77
78
  'ceiling_basis': value['ceilingBasis'],
79
+ 'max_input_pixels': value['maxInputPixels'],
78
80
  'max_input_size_bytes': value['maxInputSizeBytes'],
79
81
  'max_output_pixels': value['maxOutputPixels'],
80
82
  'input_size_bound': value['inputSizeBound'],
@@ -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.216.0
5
+ * The version of the OpenAPI document: 2.217.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).