@giveitsmaller/contracts 0.73.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 (551) 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 +200 -62
  5. package/availability/availability.json +71 -39
  6. package/code-builder/code-builder-metadata.json +134 -39
  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 +14 -5
  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 +14 -5
  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 +14 -5
  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 +14 -5
  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 +14 -5
  193. package/dist/openapi/models/FeatureNotAvailableResponse.js +2 -2
  194. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +14 -5
  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 +14 -5
  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 +14 -5
  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 +39 -3
  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 +5 -6
  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 +10 -4
  305. package/dist/openapi/models/OperationType.js +10 -4
  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 +14 -5
  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 +14 -5
  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 +14 -5
  381. package/dist/openapi/models/SseConnectionLimitResponse.js +2 -2
  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 +14 -5
  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 +14 -5
  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 +4 -6
  431. package/dist/openapi/models/UploadProbeProcessingClass.js +4 -6
  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 +14 -5
  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 +14 -5
  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 +3 -0
  525. package/dist/openapi/models/index.js +3 -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 -0
  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/custom_luma.metadata.js +1 -0
  533. package/dist/operations/image_watermark.metadata.js +1 -0
  534. package/dist/operations/merge.metadata.js +1 -0
  535. package/dist/operations/metadata-types.d.ts +2 -0
  536. package/dist/operations/split.metadata.js +12 -3
  537. package/dist/operations/text_watermark.metadata.js +1 -0
  538. package/dist/operations/video_text_watermark.metadata.js +2 -0
  539. package/dist/operations/video_watermark.metadata.js +1 -0
  540. package/openapi/README.md +1 -1
  541. package/openapi/api.yaml +536 -145
  542. package/operation-capabilities/operation-capabilities.json +1 -1
  543. package/operations/schemas/audio_watermark.yaml +34 -33
  544. package/operations/schemas/compress.yaml +256 -163
  545. package/operations/schemas/convert.yaml +11 -0
  546. package/operations/schemas/merge.yaml +7 -1
  547. package/operations/schemas/split.yaml +133 -83
  548. package/operations/schemas/thumbnail.yaml +34 -26
  549. package/operations/schemas/video_text_watermark.yaml +57 -47
  550. package/operations/schemas/video_watermark.yaml +33 -28
  551. package/package.json +3 -3
@@ -0,0 +1,25 @@
1
+ /**
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). **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
+ *
5
+ * The version of the OpenAPI document: 2.211.0
6
+ *
7
+ *
8
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
9
+ * https://openapi-generator.tech
10
+ * Do not edit the class manually.
11
+ */
12
+ /**
13
+ *
14
+ * @export
15
+ * @interface OperationMessageParamsValue
16
+ */
17
+ export type OperationMessageParamsValue = string | number | boolean;
18
+ /**
19
+ * Check if a given object implements the OperationMessageParamsValue interface.
20
+ */
21
+ export declare function instanceOfOperationMessageParamsValue(value: unknown): value is OperationMessageParamsValue;
22
+ export declare function OperationMessageParamsValueFromJSON(json: any): OperationMessageParamsValue;
23
+ export declare function OperationMessageParamsValueFromJSONTyped(json: any, ignoreDiscriminator: boolean): OperationMessageParamsValue;
24
+ export declare function OperationMessageParamsValueToJSON(json: any): OperationMessageParamsValue;
25
+ export declare function OperationMessageParamsValueToJSONTyped(value?: OperationMessageParamsValue | null, ignoreDiscriminator?: boolean): any;
@@ -0,0 +1,31 @@
1
+ /* tslint:disable */
2
+ /* eslint-disable */
3
+ /**
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). **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
+ *
7
+ * The version of the OpenAPI document: 2.211.0
8
+ *
9
+ *
10
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
11
+ * https://openapi-generator.tech
12
+ * Do not edit the class manually.
13
+ */
14
+ /**
15
+ * Check if a given object implements the OperationMessageParamsValue interface.
16
+ */
17
+ export function instanceOfOperationMessageParamsValue(value) {
18
+ return true;
19
+ }
20
+ export function OperationMessageParamsValueFromJSON(json) {
21
+ return OperationMessageParamsValueFromJSONTyped(json, false);
22
+ }
23
+ export function OperationMessageParamsValueFromJSONTyped(json, ignoreDiscriminator) {
24
+ return json;
25
+ }
26
+ export function OperationMessageParamsValueToJSON(json) {
27
+ return OperationMessageParamsValueToJSONTyped(json, false);
28
+ }
29
+ export function OperationMessageParamsValueToJSONTyped(value, ignoreDiscriminator = false) {
30
+ return value;
31
+ }
@@ -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.208.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).
@@ -13,6 +13,7 @@ import type { OperationStatus } from './OperationStatus.js';
13
13
  import type { OperationResultMetadata } from './OperationResultMetadata.js';
14
14
  import type { OperationResult } from './OperationResult.js';
15
15
  import type { OperationType } from './OperationType.js';
16
+ import type { OperationMessageParamsValue } from './OperationMessageParamsValue.js';
16
17
  /**
17
18
  * Operation status within a job response
18
19
  * @export
@@ -121,6 +122,9 @@ export interface OperationResponse {
121
122
  * `never_started` (the operation was terminated without ever running
122
123
  * because its job reached a terminal state first — an upstream failure
123
124
  * OR a cancellation; API-derived, never worker-emitted),
125
+ * `processing_limit_exceeded` (a processing tool was killed at a
126
+ * budget set from this input — deterministic, non-retryable; a
127
+ * transient deadline is `timeout`),
124
128
  * `unknown` (unclassified),
125
129
  * `out_of_memory` (retryable), `timeout` (retryable),
126
130
  * `s3_download_failed` (retryable), `s3_upload_failed` (retryable).
@@ -137,6 +141,36 @@ export interface OperationResponse {
137
141
  * @memberof OperationResponse
138
142
  */
139
143
  errorMessage?: string;
144
+ /**
145
+ * Stable, never-localised key REFINING `error_code` on a failed
146
+ * operation, so a client can show specific, localised copy (e.g.
147
+ * `thumbnail.epub.no_cover`). OPTIONAL, failed only. Every value is
148
+ * declared, with the codes it may accompany and its parameters, in
149
+ * `schemas/operation-message-keys.yaml` (the one registry). Passed
150
+ * through unchanged from the worker's OperationResult. A client
151
+ * that does not know a key, or receives one whose registry
152
+ * `error_codes` do not include this `error_code`, ignores the key and
153
+ * falls back to the `error_code` headline;
154
+ * retry is still decided from the code. Ticket U7GQhjhX.
155
+ *
156
+ * @type {string}
157
+ * @memberof OperationResponse
158
+ */
159
+ messageKey?: string;
160
+ /**
161
+ * Interpolation values for `message_key`, named and typed in
162
+ * `schemas/operation-message-keys.yaml`. JSON scalars only (string,
163
+ * integer, number, boolean) — no nested objects. Absent when the key
164
+ * declares no parameters (`params: {}`), and carries exactly the
165
+ * registry's parameters otherwise. Never carries free-text
166
+ * diagnostics; those stay in `error_message`.
167
+ *
168
+ * @type {{ [key: string]: OperationMessageParamsValue; }}
169
+ * @memberof OperationResponse
170
+ */
171
+ messageParams?: {
172
+ [key: string]: OperationMessageParamsValue;
173
+ };
140
174
  }
141
175
  /**
142
176
  * Check if a given object implements the OperationResponse interface.
@@ -2,19 +2,21 @@
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.208.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).
11
11
  * https://openapi-generator.tech
12
12
  * Do not edit the class manually.
13
13
  */
14
+ import { mapValues } from '../runtime.js';
14
15
  import { OperationStatusFromJSON, OperationStatusToJSON, } from './OperationStatus.js';
15
16
  import { OperationResultMetadataFromJSON, OperationResultMetadataToJSON, } from './OperationResultMetadata.js';
16
17
  import { OperationResultFromJSON, OperationResultToJSON, } from './OperationResult.js';
17
18
  import { OperationTypeFromJSON, OperationTypeToJSON, } from './OperationType.js';
19
+ import { OperationMessageParamsValueFromJSON, OperationMessageParamsValueToJSON, } from './OperationMessageParamsValue.js';
18
20
  /**
19
21
  * Check if a given object implements the OperationResponse interface.
20
22
  */
@@ -43,6 +45,8 @@ export function OperationResponseFromJSONTyped(json, ignoreDiscriminator) {
43
45
  'resultMetadata': json['result_metadata'] == null ? undefined : OperationResultMetadataFromJSON(json['result_metadata']),
44
46
  'errorCode': json['error_code'] == null ? undefined : json['error_code'],
45
47
  'errorMessage': json['error_message'] == null ? undefined : json['error_message'],
48
+ 'messageKey': json['message_key'] == null ? undefined : json['message_key'],
49
+ 'messageParams': json['message_params'] == null ? undefined : (mapValues(json['message_params'], OperationMessageParamsValueFromJSON)),
46
50
  };
47
51
  }
48
52
  export function OperationResponseToJSON(json) {
@@ -61,5 +65,7 @@ export function OperationResponseToJSONTyped(value, ignoreDiscriminator = false)
61
65
  'result_metadata': OperationResultMetadataToJSON(value['resultMetadata']),
62
66
  'error_code': value['errorCode'],
63
67
  'error_message': value['errorMessage'],
68
+ 'message_key': value['messageKey'],
69
+ 'message_params': value['messageParams'] == null ? undefined : (mapValues(value['messageParams'], OperationMessageParamsValueToJSON)),
64
70
  };
65
71
  }
@@ -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.208.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.208.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.208.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).
@@ -16,7 +16,9 @@
16
16
  * diagnostics never leak. New keys are **additive named cuts** (the
17
17
  * `additionalProperties: false` closure is the point — an unmodelled
18
18
  * key is a coordinated contract change, not a silent rollout). Twin of
19
- * the AsyncAPI `OperationResultMetadata` (wire ↔ read parity). Distinct
19
+ * the AsyncAPI `OperationResultMetadata` (wire ↔ read parity), except
20
+ * `already_optimal` / `estimated_saving_pct`, which the API projects
21
+ * from the wire `OperationMetrics` where the worker emits them. Distinct
20
22
  * from `OperationResult` (the deliverable output file): this carries
21
23
  * small per-operation metadata, not the output. Per `EurbZLMH` (B1).
22
24
  *
@@ -37,6 +39,30 @@ export interface OperationResultMetadata {
37
39
  * @memberof OperationResultMetadata
38
40
  */
39
41
  watermarkId?: string;
42
+ /**
43
+ * `true` when the operation completed by returning the ORIGINAL file
44
+ * unchanged, because compressing it would not have made it smaller
45
+ * (or the source was already efficiently encoded). The operation is
46
+ * a success, not a failure: `result` is the original. Show it as
47
+ * "already optimised", not as "same size". On an ordinary result it
48
+ * is absent or `false`; treat the two the same. Projected by the API from the wire
49
+ * `OperationMetrics.already_optimal` (ticket `roNRMilt`).
50
+ *
51
+ * @type {boolean}
52
+ * @memberof OperationResultMetadata
53
+ */
54
+ alreadyOptimal?: boolean;
55
+ /**
56
+ * OPTIONAL, only with `already_optimal: true`: the worker's ESTIMATE
57
+ * of how much smaller, as a percentage of the input size, a re-encode
58
+ * would have made the file, when it declined before encoding. Absent
59
+ * when no estimate was made. An estimate, not a guarantee. Projected
60
+ * from the wire `OperationMetrics.estimated_saving_pct`.
61
+ *
62
+ * @type {number}
63
+ * @memberof OperationResultMetadata
64
+ */
65
+ estimatedSavingPct?: number;
40
66
  }
41
67
  /**
42
68
  * Check if a given object implements the OperationResultMetadata interface.
@@ -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.208.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).
@@ -26,6 +26,8 @@ export function OperationResultMetadataFromJSONTyped(json, ignoreDiscriminator)
26
26
  }
27
27
  return {
28
28
  'watermarkId': json['watermark_id'] == null ? undefined : json['watermark_id'],
29
+ 'alreadyOptimal': json['already_optimal'] == null ? undefined : json['already_optimal'],
30
+ 'estimatedSavingPct': json['estimated_saving_pct'] == null ? undefined : json['estimated_saving_pct'],
29
31
  };
30
32
  }
31
33
  export function OperationResultMetadataToJSON(json) {
@@ -37,5 +39,7 @@ export function OperationResultMetadataToJSONTyped(value, ignoreDiscriminator =
37
39
  }
38
40
  return {
39
41
  'watermark_id': value['watermarkId'],
42
+ 'already_optimal': value['alreadyOptimal'],
43
+ 'estimated_saving_pct': value['estimatedSavingPct'],
40
44
  };
41
45
  }
@@ -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.208.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.208.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.208.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).
@@ -36,10 +36,9 @@ export interface OperationSchemaDefinition {
36
36
  /**
37
37
  * Operation-level availability tag. Optional — when absent, the
38
38
  * operation is treated as `stable` (parser obligation per
39
- * ADR-0001 §1.4 / FORMAT.md §Availability Taxonomy). Runtime
40
- * emission lands with [I3 `eCWIpug8`](https://trello.com/c/eCWIpug8);
41
- * until then the contract declares the shape but the endpoint
42
- * does not yet surface the field.
39
+ * ADR-0001 §1.4 / FORMAT.md §Availability Taxonomy). Echoed by
40
+ * `GET /api/operations/schema` whenever the operation schema
41
+ * declares it ([I3 `eCWIpug8`](https://trello.com/c/eCWIpug8)).
43
42
  *
44
43
  * @type {AvailabilityValue}
45
44
  * @memberof OperationSchemaDefinition
@@ -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.208.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).