@giveitsmaller/contracts 0.72.0 → 0.76.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (558) hide show
  1. package/README.md +2 -2
  2. package/accepted-options/accepted-options.json +1 -1
  3. package/accepted-options/image-output-routes.json +1 -1
  4. package/asyncapi/events.yaml +209 -67
  5. package/availability/availability.json +93 -73
  6. package/code-builder/code-builder-metadata.json +155 -71
  7. package/dist/asyncapi/ErrorCode.d.ts +1 -0
  8. package/dist/asyncapi/ErrorCode.js +1 -0
  9. package/dist/asyncapi/Failure.d.ts +2 -0
  10. package/dist/asyncapi/LongFormJobMessage.d.ts +1 -0
  11. package/dist/asyncapi/MultiOutputCompletion.d.ts +2 -0
  12. package/dist/asyncapi/OperationMetrics.d.ts +2 -0
  13. package/dist/asyncapi/SingleOutputCompletion.d.ts +2 -0
  14. package/dist/openapi/models/AccountLimitEntry.d.ts +2 -2
  15. package/dist/openapi/models/AccountLimitEntry.js +2 -2
  16. package/dist/openapi/models/AccountLimits.d.ts +2 -2
  17. package/dist/openapi/models/AccountLimits.js +2 -2
  18. package/dist/openapi/models/AccountLimitsLimits.d.ts +14 -2
  19. package/dist/openapi/models/AccountLimitsLimits.js +6 -2
  20. package/dist/openapi/models/AccountLimitsSuccessEnvelope.d.ts +2 -2
  21. package/dist/openapi/models/AccountLimitsSuccessEnvelope.js +2 -2
  22. package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +2 -2
  23. package/dist/openapi/models/AudioWatermarkDecodeRequest.js +2 -2
  24. package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +2 -2
  25. package/dist/openapi/models/AudioWatermarkDecodeResponse.js +2 -2
  26. package/dist/openapi/models/AuthErrorResponse.d.ts +16 -6
  27. package/dist/openapi/models/AuthErrorResponse.js +2 -2
  28. package/dist/openapi/models/AuthErrorType.d.ts +2 -2
  29. package/dist/openapi/models/AuthErrorType.js +2 -2
  30. package/dist/openapi/models/AuthRejectionEnvelope.d.ts +2 -2
  31. package/dist/openapi/models/AuthRejectionEnvelope.js +2 -2
  32. package/dist/openapi/models/AuthenticatedIdentity.d.ts +2 -2
  33. package/dist/openapi/models/AuthenticatedIdentity.js +2 -2
  34. package/dist/openapi/models/AvailabilityValue.d.ts +2 -2
  35. package/dist/openapi/models/AvailabilityValue.js +2 -2
  36. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +16 -6
  37. package/dist/openapi/models/BalanceExhaustedResponse.js +2 -2
  38. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +2 -2
  39. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +2 -2
  40. package/dist/openapi/models/BillingCheckoutRequest.d.ts +2 -2
  41. package/dist/openapi/models/BillingCheckoutRequest.js +2 -2
  42. package/dist/openapi/models/BillingCheckoutSession.d.ts +2 -2
  43. package/dist/openapi/models/BillingCheckoutSession.js +2 -2
  44. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.d.ts +2 -2
  45. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.js +2 -2
  46. package/dist/openapi/models/CallbackEventType.d.ts +2 -2
  47. package/dist/openapi/models/CallbackEventType.js +2 -2
  48. package/dist/openapi/models/CancelAccountDeletion200Response.d.ts +2 -2
  49. package/dist/openapi/models/CancelAccountDeletion200Response.js +2 -2
  50. package/dist/openapi/models/CancelAccountDeletion200ResponseData.d.ts +2 -2
  51. package/dist/openapi/models/CancelAccountDeletion200ResponseData.js +2 -2
  52. package/dist/openapi/models/CapabilityCondition.d.ts +2 -2
  53. package/dist/openapi/models/CapabilityCondition.js +2 -2
  54. package/dist/openapi/models/CapabilityConditionOneOf.d.ts +2 -2
  55. package/dist/openapi/models/CapabilityConditionOneOf.js +2 -2
  56. package/dist/openapi/models/CapabilityConditionOneOf1.d.ts +2 -2
  57. package/dist/openapi/models/CapabilityConditionOneOf1.js +2 -2
  58. package/dist/openapi/models/CapabilityConditionOneOf2.d.ts +2 -2
  59. package/dist/openapi/models/CapabilityConditionOneOf2.js +2 -2
  60. package/dist/openapi/models/CapabilityConditionOneOf3.d.ts +2 -2
  61. package/dist/openapi/models/CapabilityConditionOneOf3.js +2 -2
  62. package/dist/openapi/models/CapabilityConditionOneOf4.d.ts +2 -2
  63. package/dist/openapi/models/CapabilityConditionOneOf4.js +2 -2
  64. package/dist/openapi/models/CapabilityConditionOneOf5.d.ts +2 -2
  65. package/dist/openapi/models/CapabilityConditionOneOf5.js +2 -2
  66. package/dist/openapi/models/CapabilityConditionOneOf6.d.ts +2 -2
  67. package/dist/openapi/models/CapabilityConditionOneOf6.js +2 -2
  68. package/dist/openapi/models/CapabilityConstraint.d.ts +2 -2
  69. package/dist/openapi/models/CapabilityConstraint.js +2 -2
  70. package/dist/openapi/models/CapabilityInputSpec.d.ts +2 -2
  71. package/dist/openapi/models/CapabilityInputSpec.js +2 -2
  72. package/dist/openapi/models/CapabilityProduces.d.ts +2 -2
  73. package/dist/openapi/models/CapabilityProduces.js +2 -2
  74. package/dist/openapi/models/CapabilityProducesOneOf.d.ts +2 -2
  75. package/dist/openapi/models/CapabilityProducesOneOf.js +2 -2
  76. package/dist/openapi/models/CapabilityProducesOneOf1.d.ts +2 -2
  77. package/dist/openapi/models/CapabilityProducesOneOf1.js +2 -2
  78. package/dist/openapi/models/CapabilityProducesOneOf2.d.ts +2 -2
  79. package/dist/openapi/models/CapabilityProducesOneOf2.js +2 -2
  80. package/dist/openapi/models/ChangePasswordRequest.d.ts +2 -2
  81. package/dist/openapi/models/ChangePasswordRequest.js +2 -2
  82. package/dist/openapi/models/CheckoutSessionStatusResponse.d.ts +46 -0
  83. package/dist/openapi/models/CheckoutSessionStatusResponse.js +54 -0
  84. package/dist/openapi/models/CheckoutSessionStatusResponseData.d.ts +50 -0
  85. package/dist/openapi/models/CheckoutSessionStatusResponseData.js +55 -0
  86. package/dist/openapi/models/CodegenSource.d.ts +5 -4
  87. package/dist/openapi/models/CodegenSource.js +2 -2
  88. package/dist/openapi/models/CodegenSourceInput.d.ts +2 -2
  89. package/dist/openapi/models/CodegenSourceInput.js +2 -2
  90. package/dist/openapi/models/CodegenSourceJob.d.ts +2 -2
  91. package/dist/openapi/models/CodegenSourceJob.js +2 -2
  92. package/dist/openapi/models/CodegenSourceJobSource.d.ts +2 -2
  93. package/dist/openapi/models/CodegenSourceJobSource.js +2 -2
  94. package/dist/openapi/models/CodegenSourceOperation.d.ts +2 -2
  95. package/dist/openapi/models/CodegenSourceOperation.js +2 -2
  96. package/dist/openapi/models/CodegenUploadPlaceholder.d.ts +2 -2
  97. package/dist/openapi/models/CodegenUploadPlaceholder.js +2 -2
  98. package/dist/openapi/models/CompositionPlan.d.ts +2 -2
  99. package/dist/openapi/models/CompositionPlan.js +2 -2
  100. package/dist/openapi/models/CompositionPlanJob.d.ts +2 -2
  101. package/dist/openapi/models/CompositionPlanJob.js +2 -2
  102. package/dist/openapi/models/CompositionPlanOperation.d.ts +2 -2
  103. package/dist/openapi/models/CompositionPlanOperation.js +2 -2
  104. package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +2 -2
  105. package/dist/openapi/models/ConfirmEmailChange200Response.js +2 -2
  106. package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +2 -2
  107. package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +2 -2
  108. package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +2 -2
  109. package/dist/openapi/models/ConfirmEmailChangeRequest.js +2 -2
  110. package/dist/openapi/models/ConnectionSource.d.ts +2 -2
  111. package/dist/openapi/models/ConnectionSource.js +2 -2
  112. package/dist/openapi/models/ContactRequest.d.ts +2 -2
  113. package/dist/openapi/models/ContactRequest.js +2 -2
  114. package/dist/openapi/models/ContactSubject.d.ts +2 -2
  115. package/dist/openapi/models/ContactSubject.js +2 -2
  116. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +2 -2
  117. package/dist/openapi/models/ContactValidationErrorResponse.js +2 -2
  118. package/dist/openapi/models/CreateApiKey201Response.d.ts +2 -2
  119. package/dist/openapi/models/CreateApiKey201Response.js +2 -2
  120. package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +2 -2
  121. package/dist/openapi/models/CreateApiKey201ResponseData.js +2 -2
  122. package/dist/openapi/models/CreateApiKeyRequest.d.ts +2 -2
  123. package/dist/openapi/models/CreateApiKeyRequest.js +2 -2
  124. package/dist/openapi/models/CreateBillingCheckoutSession422Response.d.ts +2 -2
  125. package/dist/openapi/models/CreateBillingCheckoutSession422Response.js +2 -2
  126. package/dist/openapi/models/CreateExternalImport403Response.d.ts +2 -2
  127. package/dist/openapi/models/CreateExternalImport403Response.js +2 -2
  128. package/dist/openapi/models/CreateExternalImport422Response.d.ts +2 -2
  129. package/dist/openapi/models/CreateExternalImport422Response.js +2 -2
  130. package/dist/openapi/models/CreateWorkflow401Response.d.ts +16 -6
  131. package/dist/openapi/models/CreateWorkflow401Response.js +2 -2
  132. package/dist/openapi/models/CreateWorkflow422Response.d.ts +2 -2
  133. package/dist/openapi/models/CreateWorkflow422Response.js +2 -2
  134. package/dist/openapi/models/CreditTransaction.d.ts +22 -12
  135. package/dist/openapi/models/CreditTransaction.js +2 -2
  136. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +2 -2
  137. package/dist/openapi/models/CreditTransactionSourceBucket.js +2 -2
  138. package/dist/openapi/models/CreditsBalanceResponse.d.ts +2 -2
  139. package/dist/openapi/models/CreditsBalanceResponse.js +2 -2
  140. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +2 -2
  141. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +2 -2
  142. package/dist/openapi/models/CreditsUsageResponse.d.ts +2 -2
  143. package/dist/openapi/models/CreditsUsageResponse.js +2 -2
  144. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +2 -2
  145. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +2 -2
  146. package/dist/openapi/models/Delivery.d.ts +2 -2
  147. package/dist/openapi/models/Delivery.js +2 -2
  148. package/dist/openapi/models/DeliveryOutputRef.d.ts +2 -2
  149. package/dist/openapi/models/DeliveryOutputRef.js +2 -2
  150. package/dist/openapi/models/DeliveryPlan.d.ts +2 -2
  151. package/dist/openapi/models/DeliveryPlan.js +2 -2
  152. package/dist/openapi/models/DeliveryPlanOutput.d.ts +2 -2
  153. package/dist/openapi/models/DeliveryPlanOutput.js +2 -2
  154. package/dist/openapi/models/DeliveryPlanReason.d.ts +2 -2
  155. package/dist/openapi/models/DeliveryPlanReason.js +2 -2
  156. package/dist/openapi/models/DeliverySelection.d.ts +2 -2
  157. package/dist/openapi/models/DeliverySelection.js +2 -2
  158. package/dist/openapi/models/DownloadBundle.d.ts +2 -2
  159. package/dist/openapi/models/DownloadBundle.js +2 -2
  160. package/dist/openapi/models/DroppedOption.d.ts +2 -2
  161. package/dist/openapi/models/DroppedOption.js +2 -2
  162. package/dist/openapi/models/EmailNotify.d.ts +2 -2
  163. package/dist/openapi/models/EmailNotify.js +2 -2
  164. package/dist/openapi/models/EmptySuccessEnvelope.d.ts +2 -2
  165. package/dist/openapi/models/EmptySuccessEnvelope.js +2 -2
  166. package/dist/openapi/models/EndpointProjection.d.ts +2 -2
  167. package/dist/openapi/models/EndpointProjection.js +2 -2
  168. package/dist/openapi/models/EndpointProjectionServersInner.d.ts +2 -2
  169. package/dist/openapi/models/EndpointProjectionServersInner.js +2 -2
  170. package/dist/openapi/models/ErrorEnvelope.d.ts +16 -6
  171. package/dist/openapi/models/ErrorEnvelope.js +2 -2
  172. package/dist/openapi/models/EstimateQuality.d.ts +2 -2
  173. package/dist/openapi/models/EstimateQuality.js +2 -2
  174. package/dist/openapi/models/EstimateRange.d.ts +2 -2
  175. package/dist/openapi/models/EstimateRange.js +2 -2
  176. package/dist/openapi/models/ExportAccountData200Response.d.ts +2 -2
  177. package/dist/openapi/models/ExportAccountData200Response.js +2 -2
  178. package/dist/openapi/models/ExportAccountData200ResponseData.d.ts +2 -2
  179. package/dist/openapi/models/ExportAccountData200ResponseData.js +2 -2
  180. package/dist/openapi/models/ExternalDestination.d.ts +2 -2
  181. package/dist/openapi/models/ExternalDestination.js +2 -2
  182. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +2 -2
  183. package/dist/openapi/models/ExternalImportCreatedResponse.js +2 -2
  184. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +2 -2
  185. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +2 -2
  186. package/dist/openapi/models/ExternalImportRequest.d.ts +2 -2
  187. package/dist/openapi/models/ExternalImportRequest.js +2 -2
  188. package/dist/openapi/models/ExternalImportToken.d.ts +2 -2
  189. package/dist/openapi/models/ExternalImportToken.js +2 -2
  190. package/dist/openapi/models/ExternalSource.d.ts +2 -2
  191. package/dist/openapi/models/ExternalSource.js +2 -2
  192. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +16 -6
  193. package/dist/openapi/models/FeatureNotAvailableResponse.js +2 -2
  194. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +16 -6
  195. package/dist/openapi/models/FeatureTierRestrictedResponse.js +2 -2
  196. package/dist/openapi/models/FeatureViolation.d.ts +2 -2
  197. package/dist/openapi/models/FeatureViolation.js +2 -2
  198. package/dist/openapi/models/GetProfile200Response.d.ts +2 -2
  199. package/dist/openapi/models/GetProfile200Response.js +2 -2
  200. package/dist/openapi/models/GetProfile200ResponseData.d.ts +2 -2
  201. package/dist/openapi/models/GetProfile200ResponseData.js +2 -2
  202. package/dist/openapi/models/ImageEncodeCapabilities.d.ts +2 -2
  203. package/dist/openapi/models/ImageEncodeCapabilities.js +2 -2
  204. package/dist/openapi/models/JobDefinition.d.ts +2 -2
  205. package/dist/openapi/models/JobDefinition.js +2 -2
  206. package/dist/openapi/models/JobDownload.d.ts +2 -2
  207. package/dist/openapi/models/JobDownload.js +2 -2
  208. package/dist/openapi/models/JobInputV2.d.ts +2 -2
  209. package/dist/openapi/models/JobInputV2.js +2 -2
  210. package/dist/openapi/models/JobMediaClass.d.ts +2 -2
  211. package/dist/openapi/models/JobMediaClass.js +2 -2
  212. package/dist/openapi/models/JobOutputSource.d.ts +2 -2
  213. package/dist/openapi/models/JobOutputSource.js +2 -2
  214. package/dist/openapi/models/JobResponse.d.ts +2 -2
  215. package/dist/openapi/models/JobResponse.js +2 -2
  216. package/dist/openapi/models/JobStatus.d.ts +2 -2
  217. package/dist/openapi/models/JobStatus.js +2 -2
  218. package/dist/openapi/models/JobType.d.ts +2 -2
  219. package/dist/openapi/models/JobType.js +2 -2
  220. package/dist/openapi/models/LivenessResponse.d.ts +2 -2
  221. package/dist/openapi/models/LivenessResponse.js +2 -2
  222. package/dist/openapi/models/LoginUser200Response.d.ts +2 -2
  223. package/dist/openapi/models/LoginUser200Response.js +2 -2
  224. package/dist/openapi/models/LoginUser200ResponseData.d.ts +2 -2
  225. package/dist/openapi/models/LoginUser200ResponseData.js +2 -2
  226. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +2 -2
  227. package/dist/openapi/models/LoginUser200ResponseDataUser.js +2 -2
  228. package/dist/openapi/models/LoginUser401Response.d.ts +16 -6
  229. package/dist/openapi/models/LoginUser401Response.js +2 -2
  230. package/dist/openapi/models/LoginUserRequest.d.ts +2 -2
  231. package/dist/openapi/models/LoginUserRequest.js +2 -2
  232. package/dist/openapi/models/LongFormConcurrencyLimitResponse.d.ts +21 -8
  233. package/dist/openapi/models/LongFormConcurrencyLimitResponse.js +2 -2
  234. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.d.ts +2 -2
  235. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.js +2 -2
  236. package/dist/openapi/models/MetadataResponse.d.ts +2 -2
  237. package/dist/openapi/models/MetadataResponse.js +2 -2
  238. package/dist/openapi/models/MetadataResponseDimensions.d.ts +2 -2
  239. package/dist/openapi/models/MetadataResponseDimensions.js +2 -2
  240. package/dist/openapi/models/MetadataResponseExif.d.ts +2 -2
  241. package/dist/openapi/models/MetadataResponseExif.js +2 -2
  242. package/dist/openapi/models/MetadataResponseExifGps.d.ts +2 -2
  243. package/dist/openapi/models/MetadataResponseExifGps.js +2 -2
  244. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +2 -2
  245. package/dist/openapi/models/MetadataSuccessEnvelope.js +2 -2
  246. package/dist/openapi/models/MimeGroupSchema.d.ts +64 -15
  247. package/dist/openapi/models/MimeGroupSchema.js +12 -2
  248. package/dist/openapi/models/MultiInputSource.d.ts +2 -2
  249. package/dist/openapi/models/MultiInputSource.js +2 -2
  250. package/dist/openapi/models/MultipartCompleteRequest.d.ts +2 -2
  251. package/dist/openapi/models/MultipartCompleteRequest.js +2 -2
  252. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +2 -2
  253. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +2 -2
  254. package/dist/openapi/models/MultipartCompleteResponse.d.ts +2 -2
  255. package/dist/openapi/models/MultipartCompleteResponse.js +2 -2
  256. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +2 -2
  257. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +2 -2
  258. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +2 -2
  259. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +2 -2
  260. package/dist/openapi/models/MultipartInitiateResponse.d.ts +2 -2
  261. package/dist/openapi/models/MultipartInitiateResponse.js +2 -2
  262. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +2 -2
  263. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +2 -2
  264. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +2 -2
  265. package/dist/openapi/models/MultipartKeepaliveResponse.js +2 -2
  266. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +2 -2
  267. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +2 -2
  268. package/dist/openapi/models/MultipartPartListing.d.ts +2 -2
  269. package/dist/openapi/models/MultipartPartListing.js +2 -2
  270. package/dist/openapi/models/MultipartPresignRequest.d.ts +2 -2
  271. package/dist/openapi/models/MultipartPresignRequest.js +2 -2
  272. package/dist/openapi/models/MultipartPresignResponse.d.ts +2 -2
  273. package/dist/openapi/models/MultipartPresignResponse.js +2 -2
  274. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +2 -2
  275. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +2 -2
  276. package/dist/openapi/models/MultipartStatusResponse.d.ts +2 -2
  277. package/dist/openapi/models/MultipartStatusResponse.js +2 -2
  278. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +2 -2
  279. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +2 -2
  280. package/dist/openapi/models/NotifyConfig.d.ts +9 -5
  281. package/dist/openapi/models/NotifyConfig.js +2 -2
  282. package/dist/openapi/models/OperationCapability.d.ts +2 -2
  283. package/dist/openapi/models/OperationCapability.js +2 -2
  284. package/dist/openapi/models/OperationDefinition.d.ts +2 -2
  285. package/dist/openapi/models/OperationDefinition.js +2 -2
  286. package/dist/openapi/models/OperationDownload.d.ts +2 -2
  287. package/dist/openapi/models/OperationDownload.js +2 -2
  288. package/dist/openapi/models/OperationInputModel.d.ts +2 -2
  289. package/dist/openapi/models/OperationInputModel.js +2 -2
  290. package/dist/openapi/models/OperationMessageParamsValue.d.ts +25 -0
  291. package/dist/openapi/models/OperationMessageParamsValue.js +31 -0
  292. package/dist/openapi/models/OperationResponse.d.ts +36 -2
  293. package/dist/openapi/models/OperationResponse.js +8 -2
  294. package/dist/openapi/models/OperationResult.d.ts +2 -2
  295. package/dist/openapi/models/OperationResult.js +2 -2
  296. package/dist/openapi/models/OperationResultMetadata.d.ts +29 -3
  297. package/dist/openapi/models/OperationResultMetadata.js +6 -2
  298. package/dist/openapi/models/OperationResultMetrics.d.ts +2 -2
  299. package/dist/openapi/models/OperationResultMetrics.js +2 -2
  300. package/dist/openapi/models/OperationSchemaDefinition.d.ts +8 -8
  301. package/dist/openapi/models/OperationSchemaDefinition.js +2 -2
  302. package/dist/openapi/models/OperationStatus.d.ts +2 -2
  303. package/dist/openapi/models/OperationStatus.js +2 -2
  304. package/dist/openapi/models/OperationType.d.ts +11 -5
  305. package/dist/openapi/models/OperationType.js +11 -5
  306. package/dist/openapi/models/OperationsSchemaResponse.d.ts +2 -2
  307. package/dist/openapi/models/OperationsSchemaResponse.js +2 -2
  308. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +2 -2
  309. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +2 -2
  310. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +2 -2
  311. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +2 -2
  312. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +2 -2
  313. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +2 -2
  314. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +2 -2
  315. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +2 -2
  316. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.d.ts +2 -2
  317. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.js +2 -2
  318. package/dist/openapi/models/OptionSchema.d.ts +36 -2
  319. package/dist/openapi/models/OptionSchema.js +10 -2
  320. package/dist/openapi/models/OutputProperties.d.ts +2 -2
  321. package/dist/openapi/models/OutputProperties.js +2 -2
  322. package/dist/openapi/models/OutputPropertiesIsAnimated.d.ts +2 -2
  323. package/dist/openapi/models/OutputPropertiesIsAnimated.js +2 -2
  324. package/dist/openapi/models/PerClassAvailabilityEntry.d.ts +2 -2
  325. package/dist/openapi/models/PerClassAvailabilityEntry.js +2 -2
  326. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +2 -2
  327. package/dist/openapi/models/PerRoleCardinalityEntry.js +2 -2
  328. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +2 -2
  329. package/dist/openapi/models/PerValueAvailabilityEntry.js +2 -2
  330. package/dist/openapi/models/PresignedUrlPart.d.ts +2 -2
  331. package/dist/openapi/models/PresignedUrlPart.js +2 -2
  332. package/dist/openapi/models/ProbePendingResponse.d.ts +16 -6
  333. package/dist/openapi/models/ProbePendingResponse.js +2 -2
  334. package/dist/openapi/models/ProcessingClass.d.ts +2 -2
  335. package/dist/openapi/models/ProcessingClass.js +2 -2
  336. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +2 -2
  337. package/dist/openapi/models/ProcessingClassBandViolation.js +2 -2
  338. package/dist/openapi/models/ProcessingClassConstraints.d.ts +2 -2
  339. package/dist/openapi/models/ProcessingClassConstraints.js +2 -2
  340. package/dist/openapi/models/ProcessingClassEntry.d.ts +2 -2
  341. package/dist/openapi/models/ProcessingClassEntry.js +2 -2
  342. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +16 -6
  343. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +2 -2
  344. package/dist/openapi/models/ProcessingClassHint.d.ts +2 -2
  345. package/dist/openapi/models/ProcessingClassHint.js +2 -2
  346. package/dist/openapi/models/ProcessingClassReason.d.ts +2 -2
  347. package/dist/openapi/models/ProcessingClassReason.js +2 -2
  348. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +2 -2
  349. package/dist/openapi/models/ProcessingClassRejectReason.js +2 -2
  350. package/dist/openapi/models/ProcessingPlan.d.ts +2 -2
  351. package/dist/openapi/models/ProcessingPlan.js +2 -2
  352. package/dist/openapi/models/ProcessingPlanJob.d.ts +2 -2
  353. package/dist/openapi/models/ProcessingPlanJob.js +2 -2
  354. package/dist/openapi/models/ReEncodeDecision.d.ts +2 -2
  355. package/dist/openapi/models/ReEncodeDecision.js +2 -2
  356. package/dist/openapi/models/ReadinessResponse.d.ts +2 -2
  357. package/dist/openapi/models/ReadinessResponse.js +2 -2
  358. package/dist/openapi/models/RegisterUser422Response.d.ts +2 -2
  359. package/dist/openapi/models/RegisterUser422Response.js +2 -2
  360. package/dist/openapi/models/RegisterUserRequest.d.ts +2 -2
  361. package/dist/openapi/models/RegisterUserRequest.js +2 -2
  362. package/dist/openapi/models/RequestAccountDeletion200Response.d.ts +2 -2
  363. package/dist/openapi/models/RequestAccountDeletion200Response.js +2 -2
  364. package/dist/openapi/models/RequestAccountDeletion200ResponseData.d.ts +2 -2
  365. package/dist/openapi/models/RequestAccountDeletion200ResponseData.js +2 -2
  366. package/dist/openapi/models/RequestAccountDeletionRequest.d.ts +2 -2
  367. package/dist/openapi/models/RequestAccountDeletionRequest.js +2 -2
  368. package/dist/openapi/models/ResendVerificationEmailRequest.d.ts +2 -2
  369. package/dist/openapi/models/ResendVerificationEmailRequest.js +2 -2
  370. package/dist/openapi/models/ResetPasswordRequest.d.ts +2 -2
  371. package/dist/openapi/models/ResetPasswordRequest.js +2 -2
  372. package/dist/openapi/models/ResponseEnvelope.d.ts +2 -2
  373. package/dist/openapi/models/ResponseEnvelope.js +2 -2
  374. package/dist/openapi/models/RetryResponse.d.ts +2 -2
  375. package/dist/openapi/models/RetryResponse.js +2 -2
  376. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +2 -2
  377. package/dist/openapi/models/RetrySuccessEnvelope.js +2 -2
  378. package/dist/openapi/models/SseCompletionBase.d.ts +2 -2
  379. package/dist/openapi/models/SseCompletionBase.js +2 -2
  380. package/dist/openapi/models/SseConnectionLimitResponse.d.ts +183 -0
  381. package/dist/openapi/models/SseConnectionLimitResponse.js +65 -0
  382. package/dist/openapi/models/SseEventType.d.ts +2 -2
  383. package/dist/openapi/models/SseEventType.js +2 -2
  384. package/dist/openapi/models/SseJobCompletedData.d.ts +2 -2
  385. package/dist/openapi/models/SseJobCompletedData.js +2 -2
  386. package/dist/openapi/models/SseJobFailedData.d.ts +2 -2
  387. package/dist/openapi/models/SseJobFailedData.js +2 -2
  388. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +2 -2
  389. package/dist/openapi/models/SseMultiOutputCompletion.js +2 -2
  390. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +2 -2
  391. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +2 -2
  392. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +2 -2
  393. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +2 -2
  394. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +2 -2
  395. package/dist/openapi/models/SseMultiOutputResultEntry.js +2 -2
  396. package/dist/openapi/models/SseOperationCompletedData.d.ts +2 -2
  397. package/dist/openapi/models/SseOperationCompletedData.js +2 -2
  398. package/dist/openapi/models/SseOperationCompletionResult.d.ts +2 -2
  399. package/dist/openapi/models/SseOperationCompletionResult.js +2 -2
  400. package/dist/openapi/models/SseOperationFailedData.d.ts +33 -2
  401. package/dist/openapi/models/SseOperationFailedData.js +8 -2
  402. package/dist/openapi/models/SseOperationProgressData.d.ts +2 -2
  403. package/dist/openapi/models/SseOperationProgressData.js +2 -2
  404. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +2 -2
  405. package/dist/openapi/models/SseSingleOutputCompletion.js +2 -2
  406. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +2 -2
  407. package/dist/openapi/models/SseWorkflowTerminalData.js +2 -2
  408. package/dist/openapi/models/TierRestrictionKind.d.ts +2 -2
  409. package/dist/openapi/models/TierRestrictionKind.js +2 -2
  410. package/dist/openapi/models/TierRestrictionResponse.d.ts +16 -6
  411. package/dist/openapi/models/TierRestrictionResponse.js +2 -2
  412. package/dist/openapi/models/UpdateProfile200Response.d.ts +2 -2
  413. package/dist/openapi/models/UpdateProfile200Response.js +2 -2
  414. package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +2 -2
  415. package/dist/openapi/models/UpdateProfile200ResponseData.js +2 -2
  416. package/dist/openapi/models/UpdateProfile422Response.d.ts +2 -2
  417. package/dist/openapi/models/UpdateProfile422Response.js +2 -2
  418. package/dist/openapi/models/UpdateProfileRequest.d.ts +2 -2
  419. package/dist/openapi/models/UpdateProfileRequest.js +2 -2
  420. package/dist/openapi/models/UploadConstraintsApplied.d.ts +2 -2
  421. package/dist/openapi/models/UploadConstraintsApplied.js +2 -2
  422. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +16 -6
  423. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +2 -2
  424. package/dist/openapi/models/UploadFile403Response.d.ts +2 -2
  425. package/dist/openapi/models/UploadFile403Response.js +2 -2
  426. package/dist/openapi/models/UploadFile422Response.d.ts +2 -2
  427. package/dist/openapi/models/UploadFile422Response.js +2 -2
  428. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +2 -2
  429. package/dist/openapi/models/UploadProbeMediaMetadata.js +2 -2
  430. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +6 -5
  431. package/dist/openapi/models/UploadProbeProcessingClass.js +6 -5
  432. package/dist/openapi/models/UploadProbeResponse.d.ts +2 -2
  433. package/dist/openapi/models/UploadProbeResponse.js +2 -2
  434. package/dist/openapi/models/UploadProbeStatus.d.ts +2 -2
  435. package/dist/openapi/models/UploadProbeStatus.js +2 -2
  436. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +2 -2
  437. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +2 -2
  438. package/dist/openapi/models/UploadResponse.d.ts +2 -2
  439. package/dist/openapi/models/UploadResponse.js +2 -2
  440. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +16 -6
  441. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +2 -2
  442. package/dist/openapi/models/UploadSource.d.ts +2 -2
  443. package/dist/openapi/models/UploadSource.js +2 -2
  444. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +2 -2
  445. package/dist/openapi/models/UploadSuccessEnvelope.js +2 -2
  446. package/dist/openapi/models/UploadThresholds.d.ts +2 -2
  447. package/dist/openapi/models/UploadThresholds.js +2 -2
  448. package/dist/openapi/models/UserTier.d.ts +2 -2
  449. package/dist/openapi/models/UserTier.js +2 -2
  450. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +19 -8
  451. package/dist/openapi/models/ValidationErrorEnvelope.js +2 -2
  452. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +2 -2
  453. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +2 -2
  454. package/dist/openapi/models/VerifyEmailRequest.d.ts +2 -2
  455. package/dist/openapi/models/VerifyEmailRequest.js +2 -2
  456. package/dist/openapi/models/WarningType.d.ts +2 -2
  457. package/dist/openapi/models/WarningType.js +2 -2
  458. package/dist/openapi/models/WebhookOperationContext.d.ts +2 -2
  459. package/dist/openapi/models/WebhookOperationContext.js +2 -2
  460. package/dist/openapi/models/WebhookPayload.d.ts +2 -2
  461. package/dist/openapi/models/WebhookPayload.js +2 -2
  462. package/dist/openapi/models/WorkflowArchiveResponse.d.ts +2 -2
  463. package/dist/openapi/models/WorkflowArchiveResponse.js +2 -2
  464. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.d.ts +2 -2
  465. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.js +2 -2
  466. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +7 -6
  467. package/dist/openapi/models/WorkflowCancelBillingEffect.js +7 -6
  468. package/dist/openapi/models/WorkflowCancelResponse.d.ts +2 -2
  469. package/dist/openapi/models/WorkflowCancelResponse.js +2 -2
  470. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +2 -2
  471. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +2 -2
  472. package/dist/openapi/models/WorkflowCreateRequest.d.ts +11 -14
  473. package/dist/openapi/models/WorkflowCreateRequest.js +2 -2
  474. package/dist/openapi/models/WorkflowCreateResponse.d.ts +2 -2
  475. package/dist/openapi/models/WorkflowCreateResponse.js +2 -2
  476. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +2 -2
  477. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +2 -2
  478. package/dist/openapi/models/WorkflowCreditSummary.d.ts +2 -2
  479. package/dist/openapi/models/WorkflowCreditSummary.js +2 -2
  480. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +2 -2
  481. package/dist/openapi/models/WorkflowDownloadResponse.js +2 -2
  482. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +2 -2
  483. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +2 -2
  484. package/dist/openapi/models/WorkflowEdge.d.ts +2 -2
  485. package/dist/openapi/models/WorkflowEdge.js +2 -2
  486. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +16 -6
  487. package/dist/openapi/models/WorkflowExpiredResponse.js +2 -2
  488. package/dist/openapi/models/WorkflowListResponse.d.ts +2 -2
  489. package/dist/openapi/models/WorkflowListResponse.js +2 -2
  490. package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +2 -2
  491. package/dist/openapi/models/WorkflowListSuccessEnvelope.js +2 -2
  492. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +2 -2
  493. package/dist/openapi/models/WorkflowPauseRequiredAction.js +2 -2
  494. package/dist/openapi/models/WorkflowPausedDetail.d.ts +2 -2
  495. package/dist/openapi/models/WorkflowPausedDetail.js +2 -2
  496. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +2 -2
  497. package/dist/openapi/models/WorkflowPausedDetailLinks.js +2 -2
  498. package/dist/openapi/models/WorkflowProcessing.d.ts +2 -2
  499. package/dist/openapi/models/WorkflowProcessing.js +2 -2
  500. package/dist/openapi/models/WorkflowRestoreResponse.d.ts +2 -2
  501. package/dist/openapi/models/WorkflowRestoreResponse.js +2 -2
  502. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.d.ts +2 -2
  503. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.js +2 -2
  504. package/dist/openapi/models/WorkflowResumeResponse.d.ts +2 -2
  505. package/dist/openapi/models/WorkflowResumeResponse.js +2 -2
  506. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +2 -2
  507. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +2 -2
  508. package/dist/openapi/models/WorkflowSource.d.ts +2 -2
  509. package/dist/openapi/models/WorkflowSource.js +2 -2
  510. package/dist/openapi/models/WorkflowStatus.d.ts +2 -2
  511. package/dist/openapi/models/WorkflowStatus.js +2 -2
  512. package/dist/openapi/models/WorkflowStatusResponse.d.ts +5 -3
  513. package/dist/openapi/models/WorkflowStatusResponse.js +2 -2
  514. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +2 -2
  515. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +2 -2
  516. package/dist/openapi/models/WorkflowSummary.d.ts +2 -2
  517. package/dist/openapi/models/WorkflowSummary.js +2 -2
  518. package/dist/openapi/models/WorkflowSummaryJob.d.ts +2 -2
  519. package/dist/openapi/models/WorkflowSummaryJob.js +2 -2
  520. package/dist/openapi/models/WorkflowWarning.d.ts +2 -2
  521. package/dist/openapi/models/WorkflowWarning.js +2 -2
  522. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +2 -2
  523. package/dist/openapi/models/WorkflowWarningSeverity.js +2 -2
  524. package/dist/openapi/models/index.d.ts +4 -0
  525. package/dist/openapi/models/index.js +4 -0
  526. package/dist/openapi/runtime.d.ts +2 -2
  527. package/dist/openapi/runtime.js +2 -2
  528. package/dist/operations/archive.metadata.js +1 -0
  529. package/dist/operations/audio_overlay.metadata.js +1 -2
  530. package/dist/operations/audio_to_video.metadata.js +1 -0
  531. package/dist/operations/audio_watermark.metadata.js +4 -9
  532. package/dist/operations/compress.metadata.js +0 -1
  533. package/dist/operations/convert.metadata.js +0 -1
  534. package/dist/operations/custom_luma.metadata.js +1 -3
  535. package/dist/operations/image_watermark.metadata.js +1 -0
  536. package/dist/operations/merge.metadata.js +1 -1
  537. package/dist/operations/metadata-types.d.ts +2 -0
  538. package/dist/operations/split.metadata.js +12 -4
  539. package/dist/operations/text_watermark.metadata.js +1 -0
  540. package/dist/operations/thumbnail.metadata.js +0 -1
  541. package/dist/operations/transform.metadata.js +0 -1
  542. package/dist/operations/video_text_watermark.metadata.js +2 -1
  543. package/dist/operations/video_watermark.metadata.js +1 -1
  544. package/openapi/README.md +1 -1
  545. package/openapi/api.yaml +743 -189
  546. package/operation-capabilities/operation-capabilities.json +1 -1
  547. package/operations/schemas/audio_overlay.yaml +2 -4
  548. package/operations/schemas/audio_watermark.yaml +34 -33
  549. package/operations/schemas/compress.yaml +265 -165
  550. package/operations/schemas/convert.yaml +12 -2
  551. package/operations/schemas/custom_luma.yaml +5 -7
  552. package/operations/schemas/merge.yaml +8 -3
  553. package/operations/schemas/split.yaml +223 -21
  554. package/operations/schemas/thumbnail.yaml +35 -28
  555. package/operations/schemas/transform.yaml +1 -2
  556. package/operations/schemas/video_text_watermark.yaml +75 -18
  557. package/operations/schemas/video_watermark.yaml +50 -15
  558. package/package.json +3 -3
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
3
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
3
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
5
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
3
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
3
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
5
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
3
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
3
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
5
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
3
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
3
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
5
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -1,8 +1,8 @@
1
1
  /**
2
2
  * GISL Compression API
3
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
3
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.203.0
5
+ * The version of the OpenAPI document: 2.211.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
5
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.203.0
7
+ * The version of the OpenAPI document: 2.211.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -0,0 +1,183 @@
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
+ * `429` body for `GET /api/workflows/{id}/events` when the caller already
14
+ * holds the maximum number of open event streams
15
+ * (`SSE_CONNECTION_LIMIT_EXCEEDED`). The limit, who counts as the caller,
16
+ * and the consumer obligation are on that response. Carries the two
17
+ * counts the SDK taxonomy's `metadataSchema` names (`openStreams` /
18
+ * `maxStreams` after camelCase lowering), so a client can say "5 of 5
19
+ * streams open" without restating the limit.
20
+ *
21
+ * **Both count fields are REQUIRED when `error` is
22
+ * `SSE_CONNECTION_LIMIT_EXCEEDED` and absent otherwise**, enforced by the
23
+ * `if`/`then`/`else` branch below rather than a plain `required` list,
24
+ * because the endpoint's other `429` — `TOO_MANY_REQUESTS` from the
25
+ * start-rate limiter — is the plain `ErrorEnvelope` subset of this shape
26
+ * and must validate against it too.
27
+ *
28
+ * @export
29
+ * @interface SseConnectionLimitResponse
30
+ */
31
+ export interface SseConnectionLimitResponse {
32
+ /**
33
+ *
34
+ * @type {SseConnectionLimitResponseSuccessEnum}
35
+ * @memberof SseConnectionLimitResponse
36
+ */
37
+ success: SseConnectionLimitResponseSuccessEnum;
38
+ /**
39
+ * Machine-readable error code. **Each published code is stable; the
40
+ * SET is open** (`x-string-vocabulary: open`): handle an unknown code
41
+ * as a generic error. E.g.
42
+ * `VALIDATION_FAILED`, `BALANCE_EXHAUSTED`,
43
+ * `REQUIRES_REENCODE`). Canonical English; never localised.
44
+ * SDKs duck-type on this field for typed error-branch
45
+ * helpers — **except where an HTTP-status-shaped code
46
+ * (`UNPROCESSABLE_ENTITY`, `BAD_REQUEST`, …) covers several
47
+ * branches: there `error_type` is the discriminator.**
48
+ * Example: `POST /api/billing/checkout` answers
49
+ * `UNPROCESSABLE_ENTITY` both when checkout is switched off
50
+ * (`error_type: feature_not_available`) and when a pack or
51
+ * plan is not provisioned (no `error_type`); only
52
+ * `error_type` tells them apart.
53
+ *
54
+ * Multipart-session resume codes (per ticket
55
+ * [`HxUmVr3Y`](https://trello.com/c/HxUmVr3Y), V2.10.0):
56
+ * - `MULTIPART_SESSION_NOT_FOUND` (404) — upload_id does
57
+ * not match an in-flight session (expired / never
58
+ * existed / wrong account namespace). Fired by /status,
59
+ * /presign, /keepalive.
60
+ * - `MULTIPART_SESSION_OWNERSHIP` (403) — authenticated
61
+ * caller is not the session owner. Fired by /status,
62
+ * /presign, /keepalive, /complete (when manifest.userId
63
+ * is non-null and differs).
64
+ * - `MULTIPART_SESSION_AUTH_REQUIRED` (403) — session was
65
+ * anonymously initiated; the three resume endpoints
66
+ * require authentication. The `8LABloaz` follow-up will
67
+ * flip `/initiate` to also require auth.
68
+ * - `FILE_TOO_LARGE_FOR_MULTIPART` (422) — assembled object
69
+ * would exceed the S3 multipart capacity cap. Pre-S3
70
+ * server-side capacity gate; distinct from tier-quota
71
+ * rejections (`upload_size_exceeds_tier`).
72
+ *
73
+ * Workflow-create code (per ticket
74
+ * [`nGYbgChX`](https://trello.com/c/nGYbgChX) / sdks
75
+ * [`DRjIyMt9`](https://trello.com/c/DRjIyMt9)):
76
+ * - `UPLOAD_NOT_FOUND` (404) — a `POST /api/workflows` request
77
+ * references an upload that does not exist OR exists but is
78
+ * owned by a different identity (deliberate BOLA/IDOR
79
+ * existence-mask: reported as not-found, **never 403**, so the
80
+ * response does not reveal another user's upload exists).
81
+ * `message_key: "upload.not_found"`. See the createWorkflow
82
+ * 404 response + ADR-0016 Amendment.
83
+ * - `LONG_FORM_CONCURRENCY_LIMIT_EXCEEDED` (429) — caller already
84
+ * holds the maximum concurrent in-flight long-form workflows
85
+ * their tier permits (values: the API's
86
+ * `UserTier.maxConcurrentLongFormJobs`, not restated here).
87
+ * DISTINCT from an infra rate-limit 429: carries no
88
+ * `Retry-After` (it clears on workflow completion) and adds a
89
+ * `links.upgrade` CTA. `message_key:
90
+ * "job.long_form_concurrency_exceeded"`. See the createWorkflow
91
+ * 429 response + `LongFormConcurrencyLimitResponse`.
92
+ *
93
+ * @type {string}
94
+ * @memberof SseConnectionLimitResponse
95
+ */
96
+ error: string;
97
+ /**
98
+ * Human-readable error message, localised per the
99
+ * request's `Accept-Language` header (fallback locale
100
+ * `en-GB`). The response carries `Content-Language:
101
+ * <locale>` + `Vary: Accept-Language` headers. **Never
102
+ * parse this field for control flow** — it changes per
103
+ * locale.
104
+ *
105
+ * @type {string}
106
+ * @memberof SseConnectionLimitResponse
107
+ */
108
+ message?: string;
109
+ /**
110
+ * Stable canonical lookup key for the message (e.g.
111
+ * `error.balance_exhausted.add_credits`,
112
+ * `error.upload_size_exceeds_tier`). Never localised. SDK +
113
+ * frontend translation layers gate on this for client-side
114
+ * i18n catalogs (per ticket X19, cross-repo SDK companion
115
+ * work). Stable across server message-prose updates.
116
+ *
117
+ * @type {string}
118
+ * @memberof SseConnectionLimitResponse
119
+ */
120
+ messageKey?: string;
121
+ /**
122
+ * BCP 47 locale tag echoing the resolved `Content-Language`
123
+ * response header value. Currently always `en-GB` (the only
124
+ * committed locale per `info.description` Localisation block
125
+ * + ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6));
126
+ * additional values will appear here when their catalogs
127
+ * ship. Lets the SDK confirm which locale the server
128
+ * selected when the request used q-value negotiation across
129
+ * multiple `Accept-Language` values.
130
+ *
131
+ * @type {string}
132
+ * @memberof SseConnectionLimitResponse
133
+ */
134
+ locale?: string;
135
+ /**
136
+ * Optional interpolation values for the localised
137
+ * `message`. Keys are stable parameter names referenced by
138
+ * the translation table (e.g.
139
+ * `{ "filename": "photo.heic", "max_size_mb": 100 }`).
140
+ * **Excludes cost / monetary numbers** per plan v5 §F11
141
+ * round-13 narrowing — pricing-related localisation reads
142
+ * numeric state from `GET /api/v2/credits/balance`, not
143
+ * from this field. Values are JSON-native scalars
144
+ * (`string` / `integer` / `number` / `boolean` / `null`)
145
+ * — no nested objects, to keep translation-table
146
+ * integration simple.
147
+ *
148
+ * @type {{ [key: string]: any; }}
149
+ * @memberof SseConnectionLimitResponse
150
+ */
151
+ messageParams?: {
152
+ [key: string]: any;
153
+ };
154
+ /**
155
+ * Streams this caller holds open at the moment of refusal.
156
+ * @type {number}
157
+ * @memberof SseConnectionLimitResponse
158
+ */
159
+ openStreams?: number;
160
+ /**
161
+ * The caller's open-stream limit. **Read the limit from here,
162
+ * not from prose** — it is the server's value at refusal time.
163
+ *
164
+ * @type {number}
165
+ * @memberof SseConnectionLimitResponse
166
+ */
167
+ maxStreams?: number;
168
+ }
169
+ /**
170
+ * @export
171
+ */
172
+ export declare const SseConnectionLimitResponseSuccessEnum: {
173
+ readonly false: false;
174
+ };
175
+ export type SseConnectionLimitResponseSuccessEnum = typeof SseConnectionLimitResponseSuccessEnum[keyof typeof SseConnectionLimitResponseSuccessEnum];
176
+ /**
177
+ * Check if a given object implements the SseConnectionLimitResponse interface.
178
+ */
179
+ export declare function instanceOfSseConnectionLimitResponse(value: object): value is SseConnectionLimitResponse;
180
+ export declare function SseConnectionLimitResponseFromJSON(json: any): SseConnectionLimitResponse;
181
+ export declare function SseConnectionLimitResponseFromJSONTyped(json: any, ignoreDiscriminator: boolean): SseConnectionLimitResponse;
182
+ export declare function SseConnectionLimitResponseToJSON(json: any): SseConnectionLimitResponse;
183
+ export declare function SseConnectionLimitResponseToJSONTyped(value?: SseConnectionLimitResponse | null, ignoreDiscriminator?: boolean): any;