@giveitsmaller/contracts 0.72.0 → 0.76.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 (558) hide show
  1. package/README.md +2 -2
  2. package/accepted-options/accepted-options.json +1 -1
  3. package/accepted-options/image-output-routes.json +1 -1
  4. package/asyncapi/events.yaml +209 -67
  5. package/availability/availability.json +93 -73
  6. package/code-builder/code-builder-metadata.json +155 -71
  7. package/dist/asyncapi/ErrorCode.d.ts +1 -0
  8. package/dist/asyncapi/ErrorCode.js +1 -0
  9. package/dist/asyncapi/Failure.d.ts +2 -0
  10. package/dist/asyncapi/LongFormJobMessage.d.ts +1 -0
  11. package/dist/asyncapi/MultiOutputCompletion.d.ts +2 -0
  12. package/dist/asyncapi/OperationMetrics.d.ts +2 -0
  13. package/dist/asyncapi/SingleOutputCompletion.d.ts +2 -0
  14. package/dist/openapi/models/AccountLimitEntry.d.ts +2 -2
  15. package/dist/openapi/models/AccountLimitEntry.js +2 -2
  16. package/dist/openapi/models/AccountLimits.d.ts +2 -2
  17. package/dist/openapi/models/AccountLimits.js +2 -2
  18. package/dist/openapi/models/AccountLimitsLimits.d.ts +14 -2
  19. package/dist/openapi/models/AccountLimitsLimits.js +6 -2
  20. package/dist/openapi/models/AccountLimitsSuccessEnvelope.d.ts +2 -2
  21. package/dist/openapi/models/AccountLimitsSuccessEnvelope.js +2 -2
  22. package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +2 -2
  23. package/dist/openapi/models/AudioWatermarkDecodeRequest.js +2 -2
  24. package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +2 -2
  25. package/dist/openapi/models/AudioWatermarkDecodeResponse.js +2 -2
  26. package/dist/openapi/models/AuthErrorResponse.d.ts +16 -6
  27. package/dist/openapi/models/AuthErrorResponse.js +2 -2
  28. package/dist/openapi/models/AuthErrorType.d.ts +2 -2
  29. package/dist/openapi/models/AuthErrorType.js +2 -2
  30. package/dist/openapi/models/AuthRejectionEnvelope.d.ts +2 -2
  31. package/dist/openapi/models/AuthRejectionEnvelope.js +2 -2
  32. package/dist/openapi/models/AuthenticatedIdentity.d.ts +2 -2
  33. package/dist/openapi/models/AuthenticatedIdentity.js +2 -2
  34. package/dist/openapi/models/AvailabilityValue.d.ts +2 -2
  35. package/dist/openapi/models/AvailabilityValue.js +2 -2
  36. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +16 -6
  37. package/dist/openapi/models/BalanceExhaustedResponse.js +2 -2
  38. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +2 -2
  39. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +2 -2
  40. package/dist/openapi/models/BillingCheckoutRequest.d.ts +2 -2
  41. package/dist/openapi/models/BillingCheckoutRequest.js +2 -2
  42. package/dist/openapi/models/BillingCheckoutSession.d.ts +2 -2
  43. package/dist/openapi/models/BillingCheckoutSession.js +2 -2
  44. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.d.ts +2 -2
  45. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.js +2 -2
  46. package/dist/openapi/models/CallbackEventType.d.ts +2 -2
  47. package/dist/openapi/models/CallbackEventType.js +2 -2
  48. package/dist/openapi/models/CancelAccountDeletion200Response.d.ts +2 -2
  49. package/dist/openapi/models/CancelAccountDeletion200Response.js +2 -2
  50. package/dist/openapi/models/CancelAccountDeletion200ResponseData.d.ts +2 -2
  51. package/dist/openapi/models/CancelAccountDeletion200ResponseData.js +2 -2
  52. package/dist/openapi/models/CapabilityCondition.d.ts +2 -2
  53. package/dist/openapi/models/CapabilityCondition.js +2 -2
  54. package/dist/openapi/models/CapabilityConditionOneOf.d.ts +2 -2
  55. package/dist/openapi/models/CapabilityConditionOneOf.js +2 -2
  56. package/dist/openapi/models/CapabilityConditionOneOf1.d.ts +2 -2
  57. package/dist/openapi/models/CapabilityConditionOneOf1.js +2 -2
  58. package/dist/openapi/models/CapabilityConditionOneOf2.d.ts +2 -2
  59. package/dist/openapi/models/CapabilityConditionOneOf2.js +2 -2
  60. package/dist/openapi/models/CapabilityConditionOneOf3.d.ts +2 -2
  61. package/dist/openapi/models/CapabilityConditionOneOf3.js +2 -2
  62. package/dist/openapi/models/CapabilityConditionOneOf4.d.ts +2 -2
  63. package/dist/openapi/models/CapabilityConditionOneOf4.js +2 -2
  64. package/dist/openapi/models/CapabilityConditionOneOf5.d.ts +2 -2
  65. package/dist/openapi/models/CapabilityConditionOneOf5.js +2 -2
  66. package/dist/openapi/models/CapabilityConditionOneOf6.d.ts +2 -2
  67. package/dist/openapi/models/CapabilityConditionOneOf6.js +2 -2
  68. package/dist/openapi/models/CapabilityConstraint.d.ts +2 -2
  69. package/dist/openapi/models/CapabilityConstraint.js +2 -2
  70. package/dist/openapi/models/CapabilityInputSpec.d.ts +2 -2
  71. package/dist/openapi/models/CapabilityInputSpec.js +2 -2
  72. package/dist/openapi/models/CapabilityProduces.d.ts +2 -2
  73. package/dist/openapi/models/CapabilityProduces.js +2 -2
  74. package/dist/openapi/models/CapabilityProducesOneOf.d.ts +2 -2
  75. package/dist/openapi/models/CapabilityProducesOneOf.js +2 -2
  76. package/dist/openapi/models/CapabilityProducesOneOf1.d.ts +2 -2
  77. package/dist/openapi/models/CapabilityProducesOneOf1.js +2 -2
  78. package/dist/openapi/models/CapabilityProducesOneOf2.d.ts +2 -2
  79. package/dist/openapi/models/CapabilityProducesOneOf2.js +2 -2
  80. package/dist/openapi/models/ChangePasswordRequest.d.ts +2 -2
  81. package/dist/openapi/models/ChangePasswordRequest.js +2 -2
  82. package/dist/openapi/models/CheckoutSessionStatusResponse.d.ts +46 -0
  83. package/dist/openapi/models/CheckoutSessionStatusResponse.js +54 -0
  84. package/dist/openapi/models/CheckoutSessionStatusResponseData.d.ts +50 -0
  85. package/dist/openapi/models/CheckoutSessionStatusResponseData.js +55 -0
  86. package/dist/openapi/models/CodegenSource.d.ts +5 -4
  87. package/dist/openapi/models/CodegenSource.js +2 -2
  88. package/dist/openapi/models/CodegenSourceInput.d.ts +2 -2
  89. package/dist/openapi/models/CodegenSourceInput.js +2 -2
  90. package/dist/openapi/models/CodegenSourceJob.d.ts +2 -2
  91. package/dist/openapi/models/CodegenSourceJob.js +2 -2
  92. package/dist/openapi/models/CodegenSourceJobSource.d.ts +2 -2
  93. package/dist/openapi/models/CodegenSourceJobSource.js +2 -2
  94. package/dist/openapi/models/CodegenSourceOperation.d.ts +2 -2
  95. package/dist/openapi/models/CodegenSourceOperation.js +2 -2
  96. package/dist/openapi/models/CodegenUploadPlaceholder.d.ts +2 -2
  97. package/dist/openapi/models/CodegenUploadPlaceholder.js +2 -2
  98. package/dist/openapi/models/CompositionPlan.d.ts +2 -2
  99. package/dist/openapi/models/CompositionPlan.js +2 -2
  100. package/dist/openapi/models/CompositionPlanJob.d.ts +2 -2
  101. package/dist/openapi/models/CompositionPlanJob.js +2 -2
  102. package/dist/openapi/models/CompositionPlanOperation.d.ts +2 -2
  103. package/dist/openapi/models/CompositionPlanOperation.js +2 -2
  104. package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +2 -2
  105. package/dist/openapi/models/ConfirmEmailChange200Response.js +2 -2
  106. package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +2 -2
  107. package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +2 -2
  108. package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +2 -2
  109. package/dist/openapi/models/ConfirmEmailChangeRequest.js +2 -2
  110. package/dist/openapi/models/ConnectionSource.d.ts +2 -2
  111. package/dist/openapi/models/ConnectionSource.js +2 -2
  112. package/dist/openapi/models/ContactRequest.d.ts +2 -2
  113. package/dist/openapi/models/ContactRequest.js +2 -2
  114. package/dist/openapi/models/ContactSubject.d.ts +2 -2
  115. package/dist/openapi/models/ContactSubject.js +2 -2
  116. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +2 -2
  117. package/dist/openapi/models/ContactValidationErrorResponse.js +2 -2
  118. package/dist/openapi/models/CreateApiKey201Response.d.ts +2 -2
  119. package/dist/openapi/models/CreateApiKey201Response.js +2 -2
  120. package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +2 -2
  121. package/dist/openapi/models/CreateApiKey201ResponseData.js +2 -2
  122. package/dist/openapi/models/CreateApiKeyRequest.d.ts +2 -2
  123. package/dist/openapi/models/CreateApiKeyRequest.js +2 -2
  124. package/dist/openapi/models/CreateBillingCheckoutSession422Response.d.ts +2 -2
  125. package/dist/openapi/models/CreateBillingCheckoutSession422Response.js +2 -2
  126. package/dist/openapi/models/CreateExternalImport403Response.d.ts +2 -2
  127. package/dist/openapi/models/CreateExternalImport403Response.js +2 -2
  128. package/dist/openapi/models/CreateExternalImport422Response.d.ts +2 -2
  129. package/dist/openapi/models/CreateExternalImport422Response.js +2 -2
  130. package/dist/openapi/models/CreateWorkflow401Response.d.ts +16 -6
  131. package/dist/openapi/models/CreateWorkflow401Response.js +2 -2
  132. package/dist/openapi/models/CreateWorkflow422Response.d.ts +2 -2
  133. package/dist/openapi/models/CreateWorkflow422Response.js +2 -2
  134. package/dist/openapi/models/CreditTransaction.d.ts +22 -12
  135. package/dist/openapi/models/CreditTransaction.js +2 -2
  136. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +2 -2
  137. package/dist/openapi/models/CreditTransactionSourceBucket.js +2 -2
  138. package/dist/openapi/models/CreditsBalanceResponse.d.ts +2 -2
  139. package/dist/openapi/models/CreditsBalanceResponse.js +2 -2
  140. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +2 -2
  141. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +2 -2
  142. package/dist/openapi/models/CreditsUsageResponse.d.ts +2 -2
  143. package/dist/openapi/models/CreditsUsageResponse.js +2 -2
  144. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +2 -2
  145. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +2 -2
  146. package/dist/openapi/models/Delivery.d.ts +2 -2
  147. package/dist/openapi/models/Delivery.js +2 -2
  148. package/dist/openapi/models/DeliveryOutputRef.d.ts +2 -2
  149. package/dist/openapi/models/DeliveryOutputRef.js +2 -2
  150. package/dist/openapi/models/DeliveryPlan.d.ts +2 -2
  151. package/dist/openapi/models/DeliveryPlan.js +2 -2
  152. package/dist/openapi/models/DeliveryPlanOutput.d.ts +2 -2
  153. package/dist/openapi/models/DeliveryPlanOutput.js +2 -2
  154. package/dist/openapi/models/DeliveryPlanReason.d.ts +2 -2
  155. package/dist/openapi/models/DeliveryPlanReason.js +2 -2
  156. package/dist/openapi/models/DeliverySelection.d.ts +2 -2
  157. package/dist/openapi/models/DeliverySelection.js +2 -2
  158. package/dist/openapi/models/DownloadBundle.d.ts +2 -2
  159. package/dist/openapi/models/DownloadBundle.js +2 -2
  160. package/dist/openapi/models/DroppedOption.d.ts +2 -2
  161. package/dist/openapi/models/DroppedOption.js +2 -2
  162. package/dist/openapi/models/EmailNotify.d.ts +2 -2
  163. package/dist/openapi/models/EmailNotify.js +2 -2
  164. package/dist/openapi/models/EmptySuccessEnvelope.d.ts +2 -2
  165. package/dist/openapi/models/EmptySuccessEnvelope.js +2 -2
  166. package/dist/openapi/models/EndpointProjection.d.ts +2 -2
  167. package/dist/openapi/models/EndpointProjection.js +2 -2
  168. package/dist/openapi/models/EndpointProjectionServersInner.d.ts +2 -2
  169. package/dist/openapi/models/EndpointProjectionServersInner.js +2 -2
  170. package/dist/openapi/models/ErrorEnvelope.d.ts +16 -6
  171. package/dist/openapi/models/ErrorEnvelope.js +2 -2
  172. package/dist/openapi/models/EstimateQuality.d.ts +2 -2
  173. package/dist/openapi/models/EstimateQuality.js +2 -2
  174. package/dist/openapi/models/EstimateRange.d.ts +2 -2
  175. package/dist/openapi/models/EstimateRange.js +2 -2
  176. package/dist/openapi/models/ExportAccountData200Response.d.ts +2 -2
  177. package/dist/openapi/models/ExportAccountData200Response.js +2 -2
  178. package/dist/openapi/models/ExportAccountData200ResponseData.d.ts +2 -2
  179. package/dist/openapi/models/ExportAccountData200ResponseData.js +2 -2
  180. package/dist/openapi/models/ExternalDestination.d.ts +2 -2
  181. package/dist/openapi/models/ExternalDestination.js +2 -2
  182. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +2 -2
  183. package/dist/openapi/models/ExternalImportCreatedResponse.js +2 -2
  184. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +2 -2
  185. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +2 -2
  186. package/dist/openapi/models/ExternalImportRequest.d.ts +2 -2
  187. package/dist/openapi/models/ExternalImportRequest.js +2 -2
  188. package/dist/openapi/models/ExternalImportToken.d.ts +2 -2
  189. package/dist/openapi/models/ExternalImportToken.js +2 -2
  190. package/dist/openapi/models/ExternalSource.d.ts +2 -2
  191. package/dist/openapi/models/ExternalSource.js +2 -2
  192. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +16 -6
  193. package/dist/openapi/models/FeatureNotAvailableResponse.js +2 -2
  194. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +16 -6
  195. package/dist/openapi/models/FeatureTierRestrictedResponse.js +2 -2
  196. package/dist/openapi/models/FeatureViolation.d.ts +2 -2
  197. package/dist/openapi/models/FeatureViolation.js +2 -2
  198. package/dist/openapi/models/GetProfile200Response.d.ts +2 -2
  199. package/dist/openapi/models/GetProfile200Response.js +2 -2
  200. package/dist/openapi/models/GetProfile200ResponseData.d.ts +2 -2
  201. package/dist/openapi/models/GetProfile200ResponseData.js +2 -2
  202. package/dist/openapi/models/ImageEncodeCapabilities.d.ts +2 -2
  203. package/dist/openapi/models/ImageEncodeCapabilities.js +2 -2
  204. package/dist/openapi/models/JobDefinition.d.ts +2 -2
  205. package/dist/openapi/models/JobDefinition.js +2 -2
  206. package/dist/openapi/models/JobDownload.d.ts +2 -2
  207. package/dist/openapi/models/JobDownload.js +2 -2
  208. package/dist/openapi/models/JobInputV2.d.ts +2 -2
  209. package/dist/openapi/models/JobInputV2.js +2 -2
  210. package/dist/openapi/models/JobMediaClass.d.ts +2 -2
  211. package/dist/openapi/models/JobMediaClass.js +2 -2
  212. package/dist/openapi/models/JobOutputSource.d.ts +2 -2
  213. package/dist/openapi/models/JobOutputSource.js +2 -2
  214. package/dist/openapi/models/JobResponse.d.ts +2 -2
  215. package/dist/openapi/models/JobResponse.js +2 -2
  216. package/dist/openapi/models/JobStatus.d.ts +2 -2
  217. package/dist/openapi/models/JobStatus.js +2 -2
  218. package/dist/openapi/models/JobType.d.ts +2 -2
  219. package/dist/openapi/models/JobType.js +2 -2
  220. package/dist/openapi/models/LivenessResponse.d.ts +2 -2
  221. package/dist/openapi/models/LivenessResponse.js +2 -2
  222. package/dist/openapi/models/LoginUser200Response.d.ts +2 -2
  223. package/dist/openapi/models/LoginUser200Response.js +2 -2
  224. package/dist/openapi/models/LoginUser200ResponseData.d.ts +2 -2
  225. package/dist/openapi/models/LoginUser200ResponseData.js +2 -2
  226. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +2 -2
  227. package/dist/openapi/models/LoginUser200ResponseDataUser.js +2 -2
  228. package/dist/openapi/models/LoginUser401Response.d.ts +16 -6
  229. package/dist/openapi/models/LoginUser401Response.js +2 -2
  230. package/dist/openapi/models/LoginUserRequest.d.ts +2 -2
  231. package/dist/openapi/models/LoginUserRequest.js +2 -2
  232. package/dist/openapi/models/LongFormConcurrencyLimitResponse.d.ts +21 -8
  233. package/dist/openapi/models/LongFormConcurrencyLimitResponse.js +2 -2
  234. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.d.ts +2 -2
  235. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.js +2 -2
  236. package/dist/openapi/models/MetadataResponse.d.ts +2 -2
  237. package/dist/openapi/models/MetadataResponse.js +2 -2
  238. package/dist/openapi/models/MetadataResponseDimensions.d.ts +2 -2
  239. package/dist/openapi/models/MetadataResponseDimensions.js +2 -2
  240. package/dist/openapi/models/MetadataResponseExif.d.ts +2 -2
  241. package/dist/openapi/models/MetadataResponseExif.js +2 -2
  242. package/dist/openapi/models/MetadataResponseExifGps.d.ts +2 -2
  243. package/dist/openapi/models/MetadataResponseExifGps.js +2 -2
  244. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +2 -2
  245. package/dist/openapi/models/MetadataSuccessEnvelope.js +2 -2
  246. package/dist/openapi/models/MimeGroupSchema.d.ts +64 -15
  247. package/dist/openapi/models/MimeGroupSchema.js +12 -2
  248. package/dist/openapi/models/MultiInputSource.d.ts +2 -2
  249. package/dist/openapi/models/MultiInputSource.js +2 -2
  250. package/dist/openapi/models/MultipartCompleteRequest.d.ts +2 -2
  251. package/dist/openapi/models/MultipartCompleteRequest.js +2 -2
  252. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +2 -2
  253. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +2 -2
  254. package/dist/openapi/models/MultipartCompleteResponse.d.ts +2 -2
  255. package/dist/openapi/models/MultipartCompleteResponse.js +2 -2
  256. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +2 -2
  257. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +2 -2
  258. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +2 -2
  259. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +2 -2
  260. package/dist/openapi/models/MultipartInitiateResponse.d.ts +2 -2
  261. package/dist/openapi/models/MultipartInitiateResponse.js +2 -2
  262. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +2 -2
  263. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +2 -2
  264. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +2 -2
  265. package/dist/openapi/models/MultipartKeepaliveResponse.js +2 -2
  266. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +2 -2
  267. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +2 -2
  268. package/dist/openapi/models/MultipartPartListing.d.ts +2 -2
  269. package/dist/openapi/models/MultipartPartListing.js +2 -2
  270. package/dist/openapi/models/MultipartPresignRequest.d.ts +2 -2
  271. package/dist/openapi/models/MultipartPresignRequest.js +2 -2
  272. package/dist/openapi/models/MultipartPresignResponse.d.ts +2 -2
  273. package/dist/openapi/models/MultipartPresignResponse.js +2 -2
  274. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +2 -2
  275. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +2 -2
  276. package/dist/openapi/models/MultipartStatusResponse.d.ts +2 -2
  277. package/dist/openapi/models/MultipartStatusResponse.js +2 -2
  278. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +2 -2
  279. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +2 -2
  280. package/dist/openapi/models/NotifyConfig.d.ts +9 -5
  281. package/dist/openapi/models/NotifyConfig.js +2 -2
  282. package/dist/openapi/models/OperationCapability.d.ts +2 -2
  283. package/dist/openapi/models/OperationCapability.js +2 -2
  284. package/dist/openapi/models/OperationDefinition.d.ts +2 -2
  285. package/dist/openapi/models/OperationDefinition.js +2 -2
  286. package/dist/openapi/models/OperationDownload.d.ts +2 -2
  287. package/dist/openapi/models/OperationDownload.js +2 -2
  288. package/dist/openapi/models/OperationInputModel.d.ts +2 -2
  289. package/dist/openapi/models/OperationInputModel.js +2 -2
  290. package/dist/openapi/models/OperationMessageParamsValue.d.ts +25 -0
  291. package/dist/openapi/models/OperationMessageParamsValue.js +31 -0
  292. package/dist/openapi/models/OperationResponse.d.ts +36 -2
  293. package/dist/openapi/models/OperationResponse.js +8 -2
  294. package/dist/openapi/models/OperationResult.d.ts +2 -2
  295. package/dist/openapi/models/OperationResult.js +2 -2
  296. package/dist/openapi/models/OperationResultMetadata.d.ts +29 -3
  297. package/dist/openapi/models/OperationResultMetadata.js +6 -2
  298. package/dist/openapi/models/OperationResultMetrics.d.ts +2 -2
  299. package/dist/openapi/models/OperationResultMetrics.js +2 -2
  300. package/dist/openapi/models/OperationSchemaDefinition.d.ts +8 -8
  301. package/dist/openapi/models/OperationSchemaDefinition.js +2 -2
  302. package/dist/openapi/models/OperationStatus.d.ts +2 -2
  303. package/dist/openapi/models/OperationStatus.js +2 -2
  304. package/dist/openapi/models/OperationType.d.ts +11 -5
  305. package/dist/openapi/models/OperationType.js +11 -5
  306. package/dist/openapi/models/OperationsSchemaResponse.d.ts +2 -2
  307. package/dist/openapi/models/OperationsSchemaResponse.js +2 -2
  308. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +2 -2
  309. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +2 -2
  310. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +2 -2
  311. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +2 -2
  312. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +2 -2
  313. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +2 -2
  314. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +2 -2
  315. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +2 -2
  316. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.d.ts +2 -2
  317. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.js +2 -2
  318. package/dist/openapi/models/OptionSchema.d.ts +36 -2
  319. package/dist/openapi/models/OptionSchema.js +10 -2
  320. package/dist/openapi/models/OutputProperties.d.ts +2 -2
  321. package/dist/openapi/models/OutputProperties.js +2 -2
  322. package/dist/openapi/models/OutputPropertiesIsAnimated.d.ts +2 -2
  323. package/dist/openapi/models/OutputPropertiesIsAnimated.js +2 -2
  324. package/dist/openapi/models/PerClassAvailabilityEntry.d.ts +2 -2
  325. package/dist/openapi/models/PerClassAvailabilityEntry.js +2 -2
  326. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +2 -2
  327. package/dist/openapi/models/PerRoleCardinalityEntry.js +2 -2
  328. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +2 -2
  329. package/dist/openapi/models/PerValueAvailabilityEntry.js +2 -2
  330. package/dist/openapi/models/PresignedUrlPart.d.ts +2 -2
  331. package/dist/openapi/models/PresignedUrlPart.js +2 -2
  332. package/dist/openapi/models/ProbePendingResponse.d.ts +16 -6
  333. package/dist/openapi/models/ProbePendingResponse.js +2 -2
  334. package/dist/openapi/models/ProcessingClass.d.ts +2 -2
  335. package/dist/openapi/models/ProcessingClass.js +2 -2
  336. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +2 -2
  337. package/dist/openapi/models/ProcessingClassBandViolation.js +2 -2
  338. package/dist/openapi/models/ProcessingClassConstraints.d.ts +2 -2
  339. package/dist/openapi/models/ProcessingClassConstraints.js +2 -2
  340. package/dist/openapi/models/ProcessingClassEntry.d.ts +2 -2
  341. package/dist/openapi/models/ProcessingClassEntry.js +2 -2
  342. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +16 -6
  343. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +2 -2
  344. package/dist/openapi/models/ProcessingClassHint.d.ts +2 -2
  345. package/dist/openapi/models/ProcessingClassHint.js +2 -2
  346. package/dist/openapi/models/ProcessingClassReason.d.ts +2 -2
  347. package/dist/openapi/models/ProcessingClassReason.js +2 -2
  348. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +2 -2
  349. package/dist/openapi/models/ProcessingClassRejectReason.js +2 -2
  350. package/dist/openapi/models/ProcessingPlan.d.ts +2 -2
  351. package/dist/openapi/models/ProcessingPlan.js +2 -2
  352. package/dist/openapi/models/ProcessingPlanJob.d.ts +2 -2
  353. package/dist/openapi/models/ProcessingPlanJob.js +2 -2
  354. package/dist/openapi/models/ReEncodeDecision.d.ts +2 -2
  355. package/dist/openapi/models/ReEncodeDecision.js +2 -2
  356. package/dist/openapi/models/ReadinessResponse.d.ts +2 -2
  357. package/dist/openapi/models/ReadinessResponse.js +2 -2
  358. package/dist/openapi/models/RegisterUser422Response.d.ts +2 -2
  359. package/dist/openapi/models/RegisterUser422Response.js +2 -2
  360. package/dist/openapi/models/RegisterUserRequest.d.ts +2 -2
  361. package/dist/openapi/models/RegisterUserRequest.js +2 -2
  362. package/dist/openapi/models/RequestAccountDeletion200Response.d.ts +2 -2
  363. package/dist/openapi/models/RequestAccountDeletion200Response.js +2 -2
  364. package/dist/openapi/models/RequestAccountDeletion200ResponseData.d.ts +2 -2
  365. package/dist/openapi/models/RequestAccountDeletion200ResponseData.js +2 -2
  366. package/dist/openapi/models/RequestAccountDeletionRequest.d.ts +2 -2
  367. package/dist/openapi/models/RequestAccountDeletionRequest.js +2 -2
  368. package/dist/openapi/models/ResendVerificationEmailRequest.d.ts +2 -2
  369. package/dist/openapi/models/ResendVerificationEmailRequest.js +2 -2
  370. package/dist/openapi/models/ResetPasswordRequest.d.ts +2 -2
  371. package/dist/openapi/models/ResetPasswordRequest.js +2 -2
  372. package/dist/openapi/models/ResponseEnvelope.d.ts +2 -2
  373. package/dist/openapi/models/ResponseEnvelope.js +2 -2
  374. package/dist/openapi/models/RetryResponse.d.ts +2 -2
  375. package/dist/openapi/models/RetryResponse.js +2 -2
  376. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +2 -2
  377. package/dist/openapi/models/RetrySuccessEnvelope.js +2 -2
  378. package/dist/openapi/models/SseCompletionBase.d.ts +2 -2
  379. package/dist/openapi/models/SseCompletionBase.js +2 -2
  380. package/dist/openapi/models/SseConnectionLimitResponse.d.ts +183 -0
  381. package/dist/openapi/models/SseConnectionLimitResponse.js +65 -0
  382. package/dist/openapi/models/SseEventType.d.ts +2 -2
  383. package/dist/openapi/models/SseEventType.js +2 -2
  384. package/dist/openapi/models/SseJobCompletedData.d.ts +2 -2
  385. package/dist/openapi/models/SseJobCompletedData.js +2 -2
  386. package/dist/openapi/models/SseJobFailedData.d.ts +2 -2
  387. package/dist/openapi/models/SseJobFailedData.js +2 -2
  388. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +2 -2
  389. package/dist/openapi/models/SseMultiOutputCompletion.js +2 -2
  390. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +2 -2
  391. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +2 -2
  392. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +2 -2
  393. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +2 -2
  394. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +2 -2
  395. package/dist/openapi/models/SseMultiOutputResultEntry.js +2 -2
  396. package/dist/openapi/models/SseOperationCompletedData.d.ts +2 -2
  397. package/dist/openapi/models/SseOperationCompletedData.js +2 -2
  398. package/dist/openapi/models/SseOperationCompletionResult.d.ts +2 -2
  399. package/dist/openapi/models/SseOperationCompletionResult.js +2 -2
  400. package/dist/openapi/models/SseOperationFailedData.d.ts +33 -2
  401. package/dist/openapi/models/SseOperationFailedData.js +8 -2
  402. package/dist/openapi/models/SseOperationProgressData.d.ts +2 -2
  403. package/dist/openapi/models/SseOperationProgressData.js +2 -2
  404. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +2 -2
  405. package/dist/openapi/models/SseSingleOutputCompletion.js +2 -2
  406. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +2 -2
  407. package/dist/openapi/models/SseWorkflowTerminalData.js +2 -2
  408. package/dist/openapi/models/TierRestrictionKind.d.ts +2 -2
  409. package/dist/openapi/models/TierRestrictionKind.js +2 -2
  410. package/dist/openapi/models/TierRestrictionResponse.d.ts +16 -6
  411. package/dist/openapi/models/TierRestrictionResponse.js +2 -2
  412. package/dist/openapi/models/UpdateProfile200Response.d.ts +2 -2
  413. package/dist/openapi/models/UpdateProfile200Response.js +2 -2
  414. package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +2 -2
  415. package/dist/openapi/models/UpdateProfile200ResponseData.js +2 -2
  416. package/dist/openapi/models/UpdateProfile422Response.d.ts +2 -2
  417. package/dist/openapi/models/UpdateProfile422Response.js +2 -2
  418. package/dist/openapi/models/UpdateProfileRequest.d.ts +2 -2
  419. package/dist/openapi/models/UpdateProfileRequest.js +2 -2
  420. package/dist/openapi/models/UploadConstraintsApplied.d.ts +2 -2
  421. package/dist/openapi/models/UploadConstraintsApplied.js +2 -2
  422. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +16 -6
  423. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +2 -2
  424. package/dist/openapi/models/UploadFile403Response.d.ts +2 -2
  425. package/dist/openapi/models/UploadFile403Response.js +2 -2
  426. package/dist/openapi/models/UploadFile422Response.d.ts +2 -2
  427. package/dist/openapi/models/UploadFile422Response.js +2 -2
  428. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +2 -2
  429. package/dist/openapi/models/UploadProbeMediaMetadata.js +2 -2
  430. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +6 -5
  431. package/dist/openapi/models/UploadProbeProcessingClass.js +6 -5
  432. package/dist/openapi/models/UploadProbeResponse.d.ts +2 -2
  433. package/dist/openapi/models/UploadProbeResponse.js +2 -2
  434. package/dist/openapi/models/UploadProbeStatus.d.ts +2 -2
  435. package/dist/openapi/models/UploadProbeStatus.js +2 -2
  436. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +2 -2
  437. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +2 -2
  438. package/dist/openapi/models/UploadResponse.d.ts +2 -2
  439. package/dist/openapi/models/UploadResponse.js +2 -2
  440. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +16 -6
  441. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +2 -2
  442. package/dist/openapi/models/UploadSource.d.ts +2 -2
  443. package/dist/openapi/models/UploadSource.js +2 -2
  444. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +2 -2
  445. package/dist/openapi/models/UploadSuccessEnvelope.js +2 -2
  446. package/dist/openapi/models/UploadThresholds.d.ts +2 -2
  447. package/dist/openapi/models/UploadThresholds.js +2 -2
  448. package/dist/openapi/models/UserTier.d.ts +2 -2
  449. package/dist/openapi/models/UserTier.js +2 -2
  450. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +19 -8
  451. package/dist/openapi/models/ValidationErrorEnvelope.js +2 -2
  452. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +2 -2
  453. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +2 -2
  454. package/dist/openapi/models/VerifyEmailRequest.d.ts +2 -2
  455. package/dist/openapi/models/VerifyEmailRequest.js +2 -2
  456. package/dist/openapi/models/WarningType.d.ts +2 -2
  457. package/dist/openapi/models/WarningType.js +2 -2
  458. package/dist/openapi/models/WebhookOperationContext.d.ts +2 -2
  459. package/dist/openapi/models/WebhookOperationContext.js +2 -2
  460. package/dist/openapi/models/WebhookPayload.d.ts +2 -2
  461. package/dist/openapi/models/WebhookPayload.js +2 -2
  462. package/dist/openapi/models/WorkflowArchiveResponse.d.ts +2 -2
  463. package/dist/openapi/models/WorkflowArchiveResponse.js +2 -2
  464. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.d.ts +2 -2
  465. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.js +2 -2
  466. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +7 -6
  467. package/dist/openapi/models/WorkflowCancelBillingEffect.js +7 -6
  468. package/dist/openapi/models/WorkflowCancelResponse.d.ts +2 -2
  469. package/dist/openapi/models/WorkflowCancelResponse.js +2 -2
  470. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +2 -2
  471. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +2 -2
  472. package/dist/openapi/models/WorkflowCreateRequest.d.ts +11 -14
  473. package/dist/openapi/models/WorkflowCreateRequest.js +2 -2
  474. package/dist/openapi/models/WorkflowCreateResponse.d.ts +2 -2
  475. package/dist/openapi/models/WorkflowCreateResponse.js +2 -2
  476. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +2 -2
  477. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +2 -2
  478. package/dist/openapi/models/WorkflowCreditSummary.d.ts +2 -2
  479. package/dist/openapi/models/WorkflowCreditSummary.js +2 -2
  480. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +2 -2
  481. package/dist/openapi/models/WorkflowDownloadResponse.js +2 -2
  482. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +2 -2
  483. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +2 -2
  484. package/dist/openapi/models/WorkflowEdge.d.ts +2 -2
  485. package/dist/openapi/models/WorkflowEdge.js +2 -2
  486. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +16 -6
  487. package/dist/openapi/models/WorkflowExpiredResponse.js +2 -2
  488. package/dist/openapi/models/WorkflowListResponse.d.ts +2 -2
  489. package/dist/openapi/models/WorkflowListResponse.js +2 -2
  490. package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +2 -2
  491. package/dist/openapi/models/WorkflowListSuccessEnvelope.js +2 -2
  492. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +2 -2
  493. package/dist/openapi/models/WorkflowPauseRequiredAction.js +2 -2
  494. package/dist/openapi/models/WorkflowPausedDetail.d.ts +2 -2
  495. package/dist/openapi/models/WorkflowPausedDetail.js +2 -2
  496. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +2 -2
  497. package/dist/openapi/models/WorkflowPausedDetailLinks.js +2 -2
  498. package/dist/openapi/models/WorkflowProcessing.d.ts +2 -2
  499. package/dist/openapi/models/WorkflowProcessing.js +2 -2
  500. package/dist/openapi/models/WorkflowRestoreResponse.d.ts +2 -2
  501. package/dist/openapi/models/WorkflowRestoreResponse.js +2 -2
  502. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.d.ts +2 -2
  503. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.js +2 -2
  504. package/dist/openapi/models/WorkflowResumeResponse.d.ts +2 -2
  505. package/dist/openapi/models/WorkflowResumeResponse.js +2 -2
  506. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +2 -2
  507. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +2 -2
  508. package/dist/openapi/models/WorkflowSource.d.ts +2 -2
  509. package/dist/openapi/models/WorkflowSource.js +2 -2
  510. package/dist/openapi/models/WorkflowStatus.d.ts +2 -2
  511. package/dist/openapi/models/WorkflowStatus.js +2 -2
  512. package/dist/openapi/models/WorkflowStatusResponse.d.ts +5 -3
  513. package/dist/openapi/models/WorkflowStatusResponse.js +2 -2
  514. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +2 -2
  515. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +2 -2
  516. package/dist/openapi/models/WorkflowSummary.d.ts +2 -2
  517. package/dist/openapi/models/WorkflowSummary.js +2 -2
  518. package/dist/openapi/models/WorkflowSummaryJob.d.ts +2 -2
  519. package/dist/openapi/models/WorkflowSummaryJob.js +2 -2
  520. package/dist/openapi/models/WorkflowWarning.d.ts +2 -2
  521. package/dist/openapi/models/WorkflowWarning.js +2 -2
  522. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +2 -2
  523. package/dist/openapi/models/WorkflowWarningSeverity.js +2 -2
  524. package/dist/openapi/models/index.d.ts +4 -0
  525. package/dist/openapi/models/index.js +4 -0
  526. package/dist/openapi/runtime.d.ts +2 -2
  527. package/dist/openapi/runtime.js +2 -2
  528. package/dist/operations/archive.metadata.js +1 -0
  529. package/dist/operations/audio_overlay.metadata.js +1 -2
  530. package/dist/operations/audio_to_video.metadata.js +1 -0
  531. package/dist/operations/audio_watermark.metadata.js +4 -9
  532. package/dist/operations/compress.metadata.js +0 -1
  533. package/dist/operations/convert.metadata.js +0 -1
  534. package/dist/operations/custom_luma.metadata.js +1 -3
  535. package/dist/operations/image_watermark.metadata.js +1 -0
  536. package/dist/operations/merge.metadata.js +1 -1
  537. package/dist/operations/metadata-types.d.ts +2 -0
  538. package/dist/operations/split.metadata.js +12 -4
  539. package/dist/operations/text_watermark.metadata.js +1 -0
  540. package/dist/operations/thumbnail.metadata.js +0 -1
  541. package/dist/operations/transform.metadata.js +0 -1
  542. package/dist/operations/video_text_watermark.metadata.js +2 -1
  543. package/dist/operations/video_watermark.metadata.js +1 -1
  544. package/openapi/README.md +1 -1
  545. package/openapi/api.yaml +743 -189
  546. package/operation-capabilities/operation-capabilities.json +1 -1
  547. package/operations/schemas/audio_overlay.yaml +2 -4
  548. package/operations/schemas/audio_watermark.yaml +34 -33
  549. package/operations/schemas/compress.yaml +265 -165
  550. package/operations/schemas/convert.yaml +12 -2
  551. package/operations/schemas/custom_luma.yaml +5 -7
  552. package/operations/schemas/merge.yaml +8 -3
  553. package/operations/schemas/split.yaml +223 -21
  554. package/operations/schemas/thumbnail.yaml +35 -28
  555. package/operations/schemas/transform.yaml +1 -2
  556. package/operations/schemas/video_text_watermark.yaml +75 -18
  557. package/operations/schemas/video_watermark.yaml +50 -15
  558. package/package.json +3 -3
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
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). **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.
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.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
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). **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.
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.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
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). **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.
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.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
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). **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.
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.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
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). **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.
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.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
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). **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.
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.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
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). **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.
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.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
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). **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.
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.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -48,18 +48,31 @@ export interface MimeGroupSchema {
48
48
  */
49
49
  requiredTier?: UserTier;
50
50
  /**
51
- * Optional per-MIME availability map per ticket
52
- * [`YXYOo6gg`](https://trello.com/c/YXYOo6gg). Keys MUST be
53
- * a subset of `mimes[]` (CI-checked by
54
- * `scripts/check-per-mime-availability.py`); absent keys
55
- * default to `availability: stable`. Use this when
56
- * individual MIMEs within an otherwise-homogeneous mime
57
- * list ship at different availability levels (e.g.
58
- * `image/avif: beta, image/heic: planned` alongside
59
- * `image/jpeg: stable`). Runtime emission lands with
60
- * [I3](https://trello.com/c/eCWIpug8); until then the
61
- * contract advertises the field shape but the endpoint
62
- * does not yet surface the field.
51
+ * CLOSED TO NEW DECLARATIONS since 2026-09-18, ticket
52
+ * [`DquOfy7f`](https://trello.com/c/DquOfy7f). No mime_group
53
+ * declares this field and none may:
54
+ * `scripts/check-per-mime-availability.py` REFUSES any
55
+ * declaration, anywhere, at any depth. Expect this map to be
56
+ * absent or empty on every group.
57
+ *
58
+ * USE A PARALLEL `mime_group` INSTEAD. A group-level
59
+ * `planned` is enforced at create by the API's 422 gate;
60
+ * this map is NOT enforced anywhere. `compression_api`
61
+ * round-trips it raw; the SDK generators parse and publish
62
+ * it but nothing gates on it (`sdk_exposure` composes
63
+ * op/group/option/value and has no per-MIME level); only the
64
+ * frontend UI resolves it. So a declared value would be
65
+ * served by the API, published to SDK consumers as metadata
66
+ * their own gating ignores, and honoured only in one UI.
67
+ *
68
+ * The field itself is RETAINED, not removed: the shape is
69
+ * already published and deleting it would break the four
70
+ * consuming repos. Keys, if any were ever present, MUST be a
71
+ * subset of `mimes[]`, and absent keys mean
72
+ * `availability: stable`. Runtime emission was to land with
73
+ * [I3](https://trello.com/c/eCWIpug8); that roadmap is
74
+ * closed. See `schemas/FORMAT.md`
75
+ * §`per_mime_availability`.
63
76
  *
64
77
  * @type {{ [key: string]: PerValueAvailabilityEntry; }}
65
78
  * @memberof MimeGroupSchema
@@ -70,7 +83,7 @@ export interface MimeGroupSchema {
70
83
  /**
71
84
  * Optional mime-group-level INPUT-file size ceiling in BYTES
72
85
  * (ticket [`uKsFzORi`](https://trello.com/c/uKsFzORi)). Sibling of
73
- * `max_output_pixels`. **Applies to the enclosing operation's input**, and
86
+ * `max_output_pixels` (declared below). **Applies to the enclosing operation's input**, and
74
87
  * a consumer MUST scope it to the operation whose schema carries it —
75
88
  * **the same MIME can carry different ceilings under different
76
89
  * operations, because different workers process it.** ⚠️ This line
@@ -98,6 +111,35 @@ export interface MimeGroupSchema {
98
111
  * @memberof MimeGroupSchema
99
112
  */
100
113
  maxInputSizeBytes?: number;
114
+ /**
115
+ * Optional mime-group-level OUTPUT area cap: a request is valid on
116
+ * this axis iff `width × height <= max_output_pixels`, read from the
117
+ * two option values. Declared here since 2026-09-23 (`gACSVjiK`): it
118
+ * was named as a "sibling" of `max_input_size_bytes` while existing
119
+ * only in the operation schemas and the availability sidecar, and a
120
+ * consumer diffing the served schema reported it as a missing key.
121
+ * ⚠️ **Optional, and not yet round-tripped by `GET
122
+ * /api/operations/schema`** — the operation schemas under `schemas/`
123
+ * and `availability/availability.json` carry it today. See
124
+ * `schemas/FORMAT.md` §`max_output_pixels`.
125
+ *
126
+ * @type {number}
127
+ * @memberof MimeGroupSchema
128
+ */
129
+ maxOutputPixels?: number;
130
+ /**
131
+ * Declares that the group has **no byte ceiling on purpose**: the
132
+ * worker is bounded by processing time instead. XOR with
133
+ * `max_input_size_bytes` — exactly one is present when either is, so
134
+ * an absent pair means "nothing declared", never "unlimited".
135
+ * Declared here since 2026-09-23 (`gACSVjiK`) for the same reason as
136
+ * `max_output_pixels`, with the same round-trip caveat. See
137
+ * `schemas/FORMAT.md` §`input_size_bound`.
138
+ *
139
+ * @type {MimeGroupSchemaInputSizeBoundEnum}
140
+ * @memberof MimeGroupSchema
141
+ */
142
+ inputSizeBound?: MimeGroupSchemaInputSizeBoundEnum;
101
143
  /**
102
144
  * Optional mime-group-level INPUT duration ceiling as an ISO-8601
103
145
  * duration string (ticket [`KzrquIX7`](https://trello.com/c/KzrquIX7)) —
@@ -164,6 +206,13 @@ export interface MimeGroupSchema {
164
206
  [key: string]: OptionSchema;
165
207
  };
166
208
  }
209
+ /**
210
+ * @export
211
+ */
212
+ export declare const MimeGroupSchemaInputSizeBoundEnum: {
213
+ readonly processing_time: "processing_time";
214
+ };
215
+ export type MimeGroupSchemaInputSizeBoundEnum = typeof MimeGroupSchemaInputSizeBoundEnum[keyof typeof MimeGroupSchemaInputSizeBoundEnum];
167
216
  /**
168
217
  * Check if a given object implements the MimeGroupSchema interface.
169
218
  */
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
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). **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.
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.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -17,6 +17,12 @@ import { ProcessingClassEntryFromJSON, ProcessingClassEntryToJSON, } from './Pro
17
17
  import { UserTierFromJSON, UserTierToJSON, } from './UserTier.js';
18
18
  import { OptionSchemaFromJSON, OptionSchemaToJSON, } from './OptionSchema.js';
19
19
  import { AvailabilityValueFromJSON, AvailabilityValueToJSON, } from './AvailabilityValue.js';
20
+ /**
21
+ * @export
22
+ */
23
+ export const MimeGroupSchemaInputSizeBoundEnum = {
24
+ processing_time: 'processing_time'
25
+ };
20
26
  /**
21
27
  * Check if a given object implements the MimeGroupSchema interface.
22
28
  */
@@ -40,6 +46,8 @@ export function MimeGroupSchemaFromJSONTyped(json, ignoreDiscriminator) {
40
46
  'requiredTier': json['required_tier'] == null ? undefined : UserTierFromJSON(json['required_tier']),
41
47
  'perMimeAvailability': json['per_mime_availability'] == null ? undefined : (mapValues(json['per_mime_availability'], PerValueAvailabilityEntryFromJSON)),
42
48
  'maxInputSizeBytes': json['max_input_size_bytes'] == null ? undefined : json['max_input_size_bytes'],
49
+ 'maxOutputPixels': json['max_output_pixels'] == null ? undefined : json['max_output_pixels'],
50
+ 'inputSizeBound': json['input_size_bound'] == null ? undefined : json['input_size_bound'],
43
51
  'maxInputDuration': json['max_input_duration'] == null ? undefined : json['max_input_duration'],
44
52
  'processingClass': json['processing_class'] == null ? undefined : (mapValues(json['processing_class'], ProcessingClassEntryFromJSON)),
45
53
  'options': (mapValues(json['options'], OptionSchemaFromJSON)),
@@ -59,6 +67,8 @@ export function MimeGroupSchemaToJSONTyped(value, ignoreDiscriminator = false) {
59
67
  'required_tier': UserTierToJSON(value['requiredTier']),
60
68
  'per_mime_availability': value['perMimeAvailability'] == null ? undefined : (mapValues(value['perMimeAvailability'], PerValueAvailabilityEntryToJSON)),
61
69
  'max_input_size_bytes': value['maxInputSizeBytes'],
70
+ 'max_output_pixels': value['maxOutputPixels'],
71
+ 'input_size_bound': value['inputSizeBound'],
62
72
  'max_input_duration': value['maxInputDuration'],
63
73
  'processing_class': value['processingClass'] == null ? undefined : (mapValues(value['processingClass'], ProcessingClassEntryToJSON)),
64
74
  'options': (mapValues(value['options'], OptionSchemaToJSON)),
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
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). **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.
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.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
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). **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.
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.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
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). **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.
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.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
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). **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.
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.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).