@giveitsmaller/contracts 0.9.0 → 0.16.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 (443) hide show
  1. package/asyncapi/events.yaml +540 -42
  2. package/availability/availability.json +313 -89
  3. package/dist/asyncapi/Failure.d.ts +2 -0
  4. package/dist/asyncapi/MultiOutputCompletion.d.ts +2 -0
  5. package/dist/asyncapi/{NotificationsOperationsQueue.d.ts → NotificationsJobsQueue.d.ts} +2 -2
  6. package/dist/asyncapi/OperationResultMetadata.d.ts +4 -0
  7. package/dist/asyncapi/OperationResultMetadata.js +1 -0
  8. package/dist/asyncapi/OperationType.d.ts +2 -1
  9. package/dist/asyncapi/OperationType.js +1 -0
  10. package/dist/asyncapi/PageIndexed.d.ts +1 -0
  11. package/dist/asyncapi/PositionIndexed.d.ts +1 -0
  12. package/dist/asyncapi/SingleOutputCompletion.d.ts +2 -0
  13. package/dist/asyncapi/SourceEntry.d.ts +2 -0
  14. package/dist/asyncapi/Unindexed.d.ts +1 -0
  15. package/dist/asyncapi/index.d.ts +2 -1
  16. package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +2 -2
  17. package/dist/openapi/models/AudioWatermarkDecodeRequest.js +2 -2
  18. package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +2 -2
  19. package/dist/openapi/models/AudioWatermarkDecodeResponse.js +2 -2
  20. package/dist/openapi/models/AuthErrorResponse.d.ts +13 -2
  21. package/dist/openapi/models/AuthErrorResponse.js +2 -2
  22. package/dist/openapi/models/AuthErrorType.d.ts +2 -2
  23. package/dist/openapi/models/AuthErrorType.js +2 -2
  24. package/dist/openapi/models/AuthRejectionEnvelope.d.ts +126 -0
  25. package/dist/openapi/models/AuthRejectionEnvelope.js +72 -0
  26. package/dist/openapi/models/AvailabilityValue.d.ts +2 -2
  27. package/dist/openapi/models/AvailabilityValue.js +2 -2
  28. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +13 -2
  29. package/dist/openapi/models/BalanceExhaustedResponse.js +2 -2
  30. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +2 -2
  31. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +2 -2
  32. package/dist/openapi/models/CallbackEventType.d.ts +2 -2
  33. package/dist/openapi/models/CallbackEventType.js +2 -2
  34. package/dist/openapi/models/ChangePasswordRequest.d.ts +38 -0
  35. package/dist/openapi/models/ChangePasswordRequest.js +47 -0
  36. package/dist/openapi/models/CompositionPlan.d.ts +72 -0
  37. package/dist/openapi/models/CompositionPlan.js +53 -0
  38. package/dist/openapi/models/CompositionPlanJob.d.ts +39 -0
  39. package/dist/openapi/models/CompositionPlanJob.js +48 -0
  40. package/dist/openapi/models/CompositionPlanOperation.d.ts +116 -0
  41. package/dist/openapi/models/CompositionPlanOperation.js +62 -0
  42. package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +46 -0
  43. package/dist/openapi/models/ConfirmEmailChange200Response.js +54 -0
  44. package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +32 -0
  45. package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +43 -0
  46. package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +32 -0
  47. package/dist/openapi/models/ConfirmEmailChangeRequest.js +43 -0
  48. package/dist/openapi/models/ConnectionSource.d.ts +2 -2
  49. package/dist/openapi/models/ConnectionSource.js +2 -2
  50. package/dist/openapi/models/ContactRequest.d.ts +2 -2
  51. package/dist/openapi/models/ContactRequest.js +2 -2
  52. package/dist/openapi/models/ContactSubject.d.ts +2 -2
  53. package/dist/openapi/models/ContactSubject.js +2 -2
  54. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +2 -2
  55. package/dist/openapi/models/ContactValidationErrorResponse.js +2 -2
  56. package/dist/openapi/models/CreateApiKey201Response.d.ts +46 -0
  57. package/dist/openapi/models/CreateApiKey201Response.js +54 -0
  58. package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +56 -0
  59. package/dist/openapi/models/CreateApiKey201ResponseData.js +59 -0
  60. package/dist/openapi/models/CreateApiKeyRequest.d.ts +32 -0
  61. package/dist/openapi/models/CreateApiKeyRequest.js +43 -0
  62. package/dist/openapi/models/CreateExternalImport403Response.d.ts +2 -2
  63. package/dist/openapi/models/CreateExternalImport403Response.js +2 -2
  64. package/dist/openapi/models/CreateExternalImport422Response.d.ts +2 -2
  65. package/dist/openapi/models/CreateExternalImport422Response.js +2 -2
  66. package/dist/openapi/models/CreateWorkflow422Response.d.ts +2 -2
  67. package/dist/openapi/models/CreateWorkflow422Response.js +2 -2
  68. package/dist/openapi/models/CreditTransaction.d.ts +2 -2
  69. package/dist/openapi/models/CreditTransaction.js +2 -2
  70. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +2 -2
  71. package/dist/openapi/models/CreditTransactionSourceBucket.js +2 -2
  72. package/dist/openapi/models/CreditsBalanceResponse.d.ts +2 -2
  73. package/dist/openapi/models/CreditsBalanceResponse.js +2 -2
  74. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +2 -2
  75. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +2 -2
  76. package/dist/openapi/models/CreditsUsageResponse.d.ts +2 -2
  77. package/dist/openapi/models/CreditsUsageResponse.js +2 -2
  78. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +2 -2
  79. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +2 -2
  80. package/dist/openapi/models/Delivery.d.ts +2 -2
  81. package/dist/openapi/models/Delivery.js +2 -2
  82. package/dist/openapi/models/DeliveryOutputRef.d.ts +9 -2
  83. package/dist/openapi/models/DeliveryOutputRef.js +2 -2
  84. package/dist/openapi/models/DeliveryPlan.d.ts +2 -2
  85. package/dist/openapi/models/DeliveryPlan.js +2 -2
  86. package/dist/openapi/models/DeliveryPlanOutput.d.ts +17 -2
  87. package/dist/openapi/models/DeliveryPlanOutput.js +4 -2
  88. package/dist/openapi/models/DeliveryPlanReason.d.ts +2 -2
  89. package/dist/openapi/models/DeliveryPlanReason.js +2 -2
  90. package/dist/openapi/models/DeliverySelection.d.ts +6 -4
  91. package/dist/openapi/models/DeliverySelection.js +2 -2
  92. package/dist/openapi/models/EmptySuccessEnvelope.d.ts +58 -0
  93. package/dist/openapi/models/EmptySuccessEnvelope.js +53 -0
  94. package/dist/openapi/models/EndpointProjection.d.ts +12 -3
  95. package/dist/openapi/models/EndpointProjection.js +2 -2
  96. package/dist/openapi/models/ErrorEnvelope.d.ts +13 -2
  97. package/dist/openapi/models/ErrorEnvelope.js +2 -2
  98. package/dist/openapi/models/EstimateQuality.d.ts +2 -2
  99. package/dist/openapi/models/EstimateQuality.js +2 -2
  100. package/dist/openapi/models/EstimateRange.d.ts +2 -2
  101. package/dist/openapi/models/EstimateRange.js +2 -2
  102. package/dist/openapi/models/ExternalDestination.d.ts +2 -2
  103. package/dist/openapi/models/ExternalDestination.js +2 -2
  104. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +2 -2
  105. package/dist/openapi/models/ExternalImportCreatedResponse.js +2 -2
  106. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +2 -2
  107. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +2 -2
  108. package/dist/openapi/models/ExternalImportRequest.d.ts +2 -2
  109. package/dist/openapi/models/ExternalImportRequest.js +2 -2
  110. package/dist/openapi/models/ExternalImportToken.d.ts +2 -2
  111. package/dist/openapi/models/ExternalImportToken.js +2 -2
  112. package/dist/openapi/models/ExternalSource.d.ts +2 -2
  113. package/dist/openapi/models/ExternalSource.js +2 -2
  114. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +13 -2
  115. package/dist/openapi/models/FeatureNotAvailableResponse.js +2 -2
  116. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +13 -2
  117. package/dist/openapi/models/FeatureTierRestrictedResponse.js +2 -2
  118. package/dist/openapi/models/FeatureViolation.d.ts +2 -2
  119. package/dist/openapi/models/FeatureViolation.js +2 -2
  120. package/dist/openapi/models/ForgotPasswordRequest.d.ts +32 -0
  121. package/dist/openapi/models/ForgotPasswordRequest.js +43 -0
  122. package/dist/openapi/models/ImageEncodeCapabilities.d.ts +65 -0
  123. package/dist/openapi/models/ImageEncodeCapabilities.js +55 -0
  124. package/dist/openapi/models/JobDefinition.d.ts +20 -4
  125. package/dist/openapi/models/JobDefinition.js +2 -2
  126. package/dist/openapi/models/JobDownload.d.ts +2 -2
  127. package/dist/openapi/models/JobDownload.js +2 -2
  128. package/dist/openapi/models/JobInputV2.d.ts +13 -9
  129. package/dist/openapi/models/JobInputV2.js +5 -5
  130. package/dist/openapi/models/JobMediaClass.d.ts +34 -0
  131. package/dist/openapi/models/JobMediaClass.js +52 -0
  132. package/dist/openapi/models/JobOutputSource.d.ts +2 -2
  133. package/dist/openapi/models/JobOutputSource.js +2 -2
  134. package/dist/openapi/models/JobResponse.d.ts +2 -2
  135. package/dist/openapi/models/JobResponse.js +2 -2
  136. package/dist/openapi/models/JobStatus.d.ts +2 -2
  137. package/dist/openapi/models/JobStatus.js +2 -2
  138. package/dist/openapi/models/JobType.d.ts +2 -2
  139. package/dist/openapi/models/JobType.js +2 -2
  140. package/dist/openapi/models/LivenessResponse.d.ts +2 -2
  141. package/dist/openapi/models/LivenessResponse.js +2 -2
  142. package/dist/openapi/models/LoginUser200Response.d.ts +2 -2
  143. package/dist/openapi/models/LoginUser200Response.js +2 -2
  144. package/dist/openapi/models/LoginUser200ResponseData.d.ts +2 -2
  145. package/dist/openapi/models/LoginUser200ResponseData.js +2 -2
  146. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +2 -2
  147. package/dist/openapi/models/LoginUser200ResponseDataUser.js +2 -2
  148. package/dist/openapi/models/LoginUserRequest.d.ts +2 -2
  149. package/dist/openapi/models/LoginUserRequest.js +2 -2
  150. package/dist/openapi/models/MetadataResponse.d.ts +2 -2
  151. package/dist/openapi/models/MetadataResponse.js +2 -2
  152. package/dist/openapi/models/MetadataResponseDimensions.d.ts +2 -2
  153. package/dist/openapi/models/MetadataResponseDimensions.js +2 -2
  154. package/dist/openapi/models/MetadataResponseExif.d.ts +2 -2
  155. package/dist/openapi/models/MetadataResponseExif.js +2 -2
  156. package/dist/openapi/models/MetadataResponseExifGps.d.ts +2 -2
  157. package/dist/openapi/models/MetadataResponseExifGps.js +2 -2
  158. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +2 -2
  159. package/dist/openapi/models/MetadataSuccessEnvelope.js +2 -2
  160. package/dist/openapi/models/MimeGroupSchema.d.ts +37 -2
  161. package/dist/openapi/models/MimeGroupSchema.js +5 -2
  162. package/dist/openapi/models/MultiInputSource.d.ts +41 -0
  163. package/dist/openapi/models/MultiInputSource.js +52 -0
  164. package/dist/openapi/models/MultipartCompleteRequest.d.ts +2 -2
  165. package/dist/openapi/models/MultipartCompleteRequest.js +2 -2
  166. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +2 -2
  167. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +2 -2
  168. package/dist/openapi/models/MultipartCompleteResponse.d.ts +2 -2
  169. package/dist/openapi/models/MultipartCompleteResponse.js +2 -2
  170. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +2 -2
  171. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +2 -2
  172. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +2 -2
  173. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +2 -2
  174. package/dist/openapi/models/MultipartInitiateResponse.d.ts +2 -2
  175. package/dist/openapi/models/MultipartInitiateResponse.js +2 -2
  176. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +2 -2
  177. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +2 -2
  178. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +2 -2
  179. package/dist/openapi/models/MultipartKeepaliveResponse.js +2 -2
  180. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +2 -2
  181. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +2 -2
  182. package/dist/openapi/models/MultipartPartListing.d.ts +2 -2
  183. package/dist/openapi/models/MultipartPartListing.js +2 -2
  184. package/dist/openapi/models/MultipartPresignRequest.d.ts +2 -2
  185. package/dist/openapi/models/MultipartPresignRequest.js +2 -2
  186. package/dist/openapi/models/MultipartPresignResponse.d.ts +2 -2
  187. package/dist/openapi/models/MultipartPresignResponse.js +2 -2
  188. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +2 -2
  189. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +2 -2
  190. package/dist/openapi/models/MultipartStatusResponse.d.ts +2 -2
  191. package/dist/openapi/models/MultipartStatusResponse.js +2 -2
  192. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +2 -2
  193. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +2 -2
  194. package/dist/openapi/models/OperationDefinition.d.ts +27 -2
  195. package/dist/openapi/models/OperationDefinition.js +11 -2
  196. package/dist/openapi/models/OperationDownload.d.ts +30 -2
  197. package/dist/openapi/models/OperationDownload.js +6 -2
  198. package/dist/openapi/models/OperationInputModel.d.ts +3 -3
  199. package/dist/openapi/models/OperationInputModel.js +3 -3
  200. package/dist/openapi/models/OperationResponse.d.ts +18 -2
  201. package/dist/openapi/models/OperationResponse.js +5 -2
  202. package/dist/openapi/models/OperationResult.d.ts +2 -2
  203. package/dist/openapi/models/OperationResult.js +2 -2
  204. package/dist/openapi/models/OperationResultMetadata.d.ts +48 -0
  205. package/dist/openapi/models/OperationResultMetadata.js +41 -0
  206. package/dist/openapi/models/OperationResultMetrics.d.ts +16 -3
  207. package/dist/openapi/models/OperationResultMetrics.js +2 -2
  208. package/dist/openapi/models/OperationSchemaDefinition.d.ts +6 -5
  209. package/dist/openapi/models/OperationSchemaDefinition.js +2 -2
  210. package/dist/openapi/models/OperationStatus.d.ts +2 -2
  211. package/dist/openapi/models/OperationStatus.js +2 -2
  212. package/dist/openapi/models/OperationType.d.ts +7 -4
  213. package/dist/openapi/models/OperationType.js +8 -5
  214. package/dist/openapi/models/OperationsSchemaResponse.d.ts +32 -4
  215. package/dist/openapi/models/OperationsSchemaResponse.js +5 -2
  216. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +2 -2
  217. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +2 -2
  218. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +2 -2
  219. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +2 -2
  220. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +2 -2
  221. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +2 -2
  222. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +2 -2
  223. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +2 -2
  224. package/dist/openapi/models/OptionSchema.d.ts +2 -2
  225. package/dist/openapi/models/OptionSchema.js +2 -2
  226. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +2 -2
  227. package/dist/openapi/models/PerRoleCardinalityEntry.js +2 -2
  228. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +2 -2
  229. package/dist/openapi/models/PerValueAvailabilityEntry.js +2 -2
  230. package/dist/openapi/models/PresignedUrlPart.d.ts +2 -2
  231. package/dist/openapi/models/PresignedUrlPart.js +2 -2
  232. package/dist/openapi/models/ProbePendingResponse.d.ts +13 -2
  233. package/dist/openapi/models/ProbePendingResponse.js +2 -2
  234. package/dist/openapi/models/ProcessingClass.d.ts +2 -2
  235. package/dist/openapi/models/ProcessingClass.js +2 -2
  236. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +2 -2
  237. package/dist/openapi/models/ProcessingClassBandViolation.js +2 -2
  238. package/dist/openapi/models/ProcessingClassConstraints.d.ts +69 -0
  239. package/dist/openapi/models/ProcessingClassConstraints.js +49 -0
  240. package/dist/openapi/models/ProcessingClassEntry.d.ts +93 -0
  241. package/dist/openapi/models/ProcessingClassEntry.js +57 -0
  242. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +13 -2
  243. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +2 -2
  244. package/dist/openapi/models/ProcessingClassHint.d.ts +2 -2
  245. package/dist/openapi/models/ProcessingClassHint.js +2 -2
  246. package/dist/openapi/models/ProcessingClassReason.d.ts +2 -2
  247. package/dist/openapi/models/ProcessingClassReason.js +2 -2
  248. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +2 -2
  249. package/dist/openapi/models/ProcessingClassRejectReason.js +2 -2
  250. package/dist/openapi/models/ProcessingPlan.d.ts +2 -2
  251. package/dist/openapi/models/ProcessingPlan.js +2 -2
  252. package/dist/openapi/models/ProcessingPlanJob.d.ts +2 -2
  253. package/dist/openapi/models/ProcessingPlanJob.js +2 -2
  254. package/dist/openapi/models/ReEncodeDecision.d.ts +2 -2
  255. package/dist/openapi/models/ReEncodeDecision.js +2 -2
  256. package/dist/openapi/models/ReadinessResponse.d.ts +2 -2
  257. package/dist/openapi/models/ReadinessResponse.js +2 -2
  258. package/dist/openapi/models/RegisterUser422Response.d.ts +27 -0
  259. package/dist/openapi/models/RegisterUser422Response.js +47 -0
  260. package/dist/openapi/models/RegisterUserRequest.d.ts +38 -0
  261. package/dist/openapi/models/RegisterUserRequest.js +47 -0
  262. package/dist/openapi/models/ResetPasswordRequest.d.ts +38 -0
  263. package/dist/openapi/models/ResetPasswordRequest.js +47 -0
  264. package/dist/openapi/models/ResponseEnvelope.d.ts +2 -2
  265. package/dist/openapi/models/ResponseEnvelope.js +2 -2
  266. package/dist/openapi/models/RetryResponse.d.ts +2 -2
  267. package/dist/openapi/models/RetryResponse.js +2 -2
  268. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +2 -2
  269. package/dist/openapi/models/RetrySuccessEnvelope.js +2 -2
  270. package/dist/openapi/models/SseCompletionBase.d.ts +2 -2
  271. package/dist/openapi/models/SseCompletionBase.js +2 -2
  272. package/dist/openapi/models/SseEventType.d.ts +2 -2
  273. package/dist/openapi/models/SseEventType.js +2 -2
  274. package/dist/openapi/models/SseJobCompletedData.d.ts +2 -2
  275. package/dist/openapi/models/SseJobCompletedData.js +2 -2
  276. package/dist/openapi/models/SseJobFailedData.d.ts +2 -2
  277. package/dist/openapi/models/SseJobFailedData.js +2 -2
  278. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +2 -2
  279. package/dist/openapi/models/SseMultiOutputCompletion.js +2 -2
  280. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +2 -2
  281. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +2 -2
  282. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +2 -2
  283. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +2 -2
  284. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +2 -2
  285. package/dist/openapi/models/SseMultiOutputResultEntry.js +2 -2
  286. package/dist/openapi/models/SseOperationCompletedData.d.ts +17 -3
  287. package/dist/openapi/models/SseOperationCompletedData.js +2 -2
  288. package/dist/openapi/models/SseOperationCompletionResult.d.ts +2 -2
  289. package/dist/openapi/models/SseOperationCompletionResult.js +2 -2
  290. package/dist/openapi/models/SseOperationFailedData.d.ts +2 -2
  291. package/dist/openapi/models/SseOperationFailedData.js +2 -2
  292. package/dist/openapi/models/SseOperationProgressData.d.ts +2 -2
  293. package/dist/openapi/models/SseOperationProgressData.js +2 -2
  294. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +2 -2
  295. package/dist/openapi/models/SseSingleOutputCompletion.js +2 -2
  296. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +2 -2
  297. package/dist/openapi/models/SseWorkflowTerminalData.js +2 -2
  298. package/dist/openapi/models/TierRestrictionKind.d.ts +2 -2
  299. package/dist/openapi/models/TierRestrictionKind.js +2 -2
  300. package/dist/openapi/models/TierRestrictionResponse.d.ts +13 -2
  301. package/dist/openapi/models/TierRestrictionResponse.js +2 -2
  302. package/dist/openapi/models/UpdateProfile200Response.d.ts +46 -0
  303. package/dist/openapi/models/UpdateProfile200Response.js +54 -0
  304. package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +71 -0
  305. package/dist/openapi/models/UpdateProfile200ResponseData.js +67 -0
  306. package/dist/openapi/models/UpdateProfile422Response.d.ts +27 -0
  307. package/dist/openapi/models/UpdateProfile422Response.js +47 -0
  308. package/dist/openapi/models/UpdateProfileRequest.d.ts +44 -0
  309. package/dist/openapi/models/UpdateProfileRequest.js +47 -0
  310. package/dist/openapi/models/UploadConstraintsApplied.d.ts +2 -2
  311. package/dist/openapi/models/UploadConstraintsApplied.js +2 -2
  312. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +13 -2
  313. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +2 -2
  314. package/dist/openapi/models/UploadFile403Response.d.ts +2 -2
  315. package/dist/openapi/models/UploadFile403Response.js +2 -2
  316. package/dist/openapi/models/UploadFile422Response.d.ts +2 -2
  317. package/dist/openapi/models/UploadFile422Response.js +2 -2
  318. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +2 -2
  319. package/dist/openapi/models/UploadProbeMediaMetadata.js +2 -2
  320. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +2 -2
  321. package/dist/openapi/models/UploadProbeProcessingClass.js +2 -2
  322. package/dist/openapi/models/UploadProbeResponse.d.ts +2 -2
  323. package/dist/openapi/models/UploadProbeResponse.js +2 -2
  324. package/dist/openapi/models/UploadProbeStatus.d.ts +2 -2
  325. package/dist/openapi/models/UploadProbeStatus.js +2 -2
  326. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +2 -2
  327. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +2 -2
  328. package/dist/openapi/models/UploadResponse.d.ts +2 -2
  329. package/dist/openapi/models/UploadResponse.js +2 -2
  330. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +13 -2
  331. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +2 -2
  332. package/dist/openapi/models/UploadSource.d.ts +2 -2
  333. package/dist/openapi/models/UploadSource.js +2 -2
  334. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +2 -2
  335. package/dist/openapi/models/UploadSuccessEnvelope.js +2 -2
  336. package/dist/openapi/models/UploadThresholds.d.ts +2 -2
  337. package/dist/openapi/models/UploadThresholds.js +2 -2
  338. package/dist/openapi/models/UserTier.d.ts +2 -2
  339. package/dist/openapi/models/UserTier.js +2 -2
  340. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +2 -2
  341. package/dist/openapi/models/ValidationErrorEnvelope.js +2 -2
  342. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +2 -2
  343. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +2 -2
  344. package/dist/openapi/models/VerifyEmailRequest.d.ts +32 -0
  345. package/dist/openapi/models/VerifyEmailRequest.js +43 -0
  346. package/dist/openapi/models/WarningType.d.ts +2 -2
  347. package/dist/openapi/models/WarningType.js +2 -2
  348. package/dist/openapi/models/WebhookOperationContext.d.ts +2 -2
  349. package/dist/openapi/models/WebhookOperationContext.js +2 -2
  350. package/dist/openapi/models/WebhookPayload.d.ts +2 -2
  351. package/dist/openapi/models/WebhookPayload.js +2 -2
  352. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +2 -2
  353. package/dist/openapi/models/WorkflowCancelBillingEffect.js +2 -2
  354. package/dist/openapi/models/WorkflowCancelResponse.d.ts +2 -2
  355. package/dist/openapi/models/WorkflowCancelResponse.js +2 -2
  356. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +2 -2
  357. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +2 -2
  358. package/dist/openapi/models/WorkflowCreateRequest.d.ts +64 -4
  359. package/dist/openapi/models/WorkflowCreateRequest.js +10 -6
  360. package/dist/openapi/models/WorkflowCreateResponse.d.ts +24 -2
  361. package/dist/openapi/models/WorkflowCreateResponse.js +5 -2
  362. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +2 -2
  363. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +2 -2
  364. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +2 -2
  365. package/dist/openapi/models/WorkflowDownloadResponse.js +2 -2
  366. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +2 -2
  367. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +2 -2
  368. package/dist/openapi/models/WorkflowEdge.d.ts +2 -2
  369. package/dist/openapi/models/WorkflowEdge.js +2 -2
  370. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +13 -2
  371. package/dist/openapi/models/WorkflowExpiredResponse.js +2 -2
  372. package/dist/openapi/models/WorkflowListResponse.d.ts +50 -0
  373. package/dist/openapi/models/WorkflowListResponse.js +50 -0
  374. package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +46 -0
  375. package/dist/openapi/models/WorkflowListSuccessEnvelope.js +54 -0
  376. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +2 -2
  377. package/dist/openapi/models/WorkflowPauseRequiredAction.js +2 -2
  378. package/dist/openapi/models/WorkflowPausedDetail.d.ts +2 -2
  379. package/dist/openapi/models/WorkflowPausedDetail.js +2 -2
  380. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +2 -2
  381. package/dist/openapi/models/WorkflowPausedDetailLinks.js +2 -2
  382. package/dist/openapi/models/WorkflowProcessing.d.ts +2 -2
  383. package/dist/openapi/models/WorkflowProcessing.js +2 -2
  384. package/dist/openapi/models/WorkflowResumeResponse.d.ts +2 -2
  385. package/dist/openapi/models/WorkflowResumeResponse.js +2 -2
  386. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +2 -2
  387. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +2 -2
  388. package/dist/openapi/models/WorkflowSource.d.ts +7 -4
  389. package/dist/openapi/models/WorkflowSource.js +2 -2
  390. package/dist/openapi/models/WorkflowStatus.d.ts +2 -2
  391. package/dist/openapi/models/WorkflowStatus.js +2 -2
  392. package/dist/openapi/models/WorkflowStatusResponse.d.ts +21 -2
  393. package/dist/openapi/models/WorkflowStatusResponse.js +5 -2
  394. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +2 -2
  395. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +2 -2
  396. package/dist/openapi/models/WorkflowSummary.d.ts +60 -0
  397. package/dist/openapi/models/WorkflowSummary.js +57 -0
  398. package/dist/openapi/models/WorkflowSummaryJob.d.ts +57 -0
  399. package/dist/openapi/models/WorkflowSummaryJob.js +57 -0
  400. package/dist/openapi/models/WorkflowWarning.d.ts +2 -2
  401. package/dist/openapi/models/WorkflowWarning.js +2 -2
  402. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +2 -2
  403. package/dist/openapi/models/WorkflowWarningSeverity.js +2 -2
  404. package/dist/openapi/models/index.d.ts +31 -1
  405. package/dist/openapi/models/index.js +31 -1
  406. package/dist/openapi/runtime.d.ts +2 -2
  407. package/dist/openapi/runtime.js +2 -2
  408. package/dist/operations/compress.d.ts +0 -9
  409. package/dist/operations/compress.js +0 -6
  410. package/dist/operations/compress.metadata.js +4 -12
  411. package/dist/operations/index.d.ts +3 -0
  412. package/dist/operations/index.js +3 -0
  413. package/dist/operations/merge.d.ts +4 -0
  414. package/dist/operations/merge.metadata.js +12 -0
  415. package/dist/operations/passthrough.metadata.d.ts +2 -0
  416. package/dist/operations/passthrough.metadata.js +6 -0
  417. package/dist/operations/render_variants.d.ts +24 -0
  418. package/dist/operations/render_variants.js +14 -0
  419. package/dist/operations/render_variants.metadata.d.ts +2 -0
  420. package/dist/operations/render_variants.metadata.js +18 -0
  421. package/dist/operations/split.d.ts +8 -1
  422. package/dist/operations/split.js +5 -0
  423. package/dist/operations/split.metadata.js +18 -5
  424. package/openapi/api.yaml +2333 -241
  425. package/operations/schemas/archive.yaml +1 -1
  426. package/operations/schemas/audio_overlay.yaml +29 -13
  427. package/operations/schemas/audio_to_video.yaml +6 -5
  428. package/operations/schemas/audio_watermark.yaml +18 -16
  429. package/operations/schemas/compress.yaml +34 -32
  430. package/operations/schemas/custom_luma.yaml +18 -3
  431. package/operations/schemas/image_watermark.yaml +22 -7
  432. package/operations/schemas/merge.yaml +88 -35
  433. package/operations/schemas/passthrough.yaml +49 -0
  434. package/operations/schemas/render_variants.yaml +117 -0
  435. package/operations/schemas/split.yaml +72 -18
  436. package/operations/schemas/text_watermark.yaml +6 -6
  437. package/operations/schemas/thumbnail.yaml +1 -1
  438. package/operations/schemas/video_text_watermark.yaml +2 -2
  439. package/operations/schemas/video_watermark.yaml +7 -4
  440. package/package.json +3 -1
  441. package/dist/openapi/models/LogoutUser200Response.d.ts +0 -50
  442. package/dist/openapi/models/LogoutUser200Response.js +0 -53
  443. /package/dist/asyncapi/{NotificationsOperationsQueue.js → NotificationsJobsQueue.js} +0 -0
@@ -0,0 +1,69 @@
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). **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.64.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
+ * Numeric size / duration caps for a single processing class (or
14
+ * a per-tier override of those caps). All fields optional; the
15
+ * `max_input_*` keys apply to single-input mime_groups while the
16
+ * `max_total_*` keys apply to multi-input merge-style mime_groups
17
+ * (a merge can have many small inputs whose combined size triggers
18
+ * long-form). Byte caps are positive integers; duration caps are
19
+ * ISO-8601 duration strings (e.g. `PT5M`). Field set is CI-fixed —
20
+ * `scripts/check-per-tier-constraints.py` rejects unknown keys and
21
+ * bad value types. See `schemas/FORMAT.md` §`constraints` sub-block.
22
+ *
23
+ * @export
24
+ * @interface ProcessingClassConstraints
25
+ */
26
+ export interface ProcessingClassConstraints {
27
+ /**
28
+ * Max per-input duration as an ISO-8601 duration string.
29
+ * Single-input mime_groups.
30
+ *
31
+ * @type {string}
32
+ * @memberof ProcessingClassConstraints
33
+ */
34
+ maxInputDuration?: string;
35
+ /**
36
+ * Max per-input file size in bytes. Single-input mime_groups.
37
+ * @type {number}
38
+ * @memberof ProcessingClassConstraints
39
+ */
40
+ maxInputSizeBytes?: number;
41
+ /**
42
+ * Max output file size in bytes. Any mime_group.
43
+ * @type {number}
44
+ * @memberof ProcessingClassConstraints
45
+ */
46
+ maxOutputSizeBytes?: number;
47
+ /**
48
+ * Max combined duration across all inputs as an ISO-8601
49
+ * duration string. Multi-input (merge) mime_groups.
50
+ *
51
+ * @type {string}
52
+ * @memberof ProcessingClassConstraints
53
+ */
54
+ maxTotalDuration?: string;
55
+ /**
56
+ * Max combined input size in bytes. Multi-input (merge) mime_groups.
57
+ * @type {number}
58
+ * @memberof ProcessingClassConstraints
59
+ */
60
+ maxTotalInputSizeBytes?: number;
61
+ }
62
+ /**
63
+ * Check if a given object implements the ProcessingClassConstraints interface.
64
+ */
65
+ export declare function instanceOfProcessingClassConstraints(value: object): value is ProcessingClassConstraints;
66
+ export declare function ProcessingClassConstraintsFromJSON(json: any): ProcessingClassConstraints;
67
+ export declare function ProcessingClassConstraintsFromJSONTyped(json: any, ignoreDiscriminator: boolean): ProcessingClassConstraints;
68
+ export declare function ProcessingClassConstraintsToJSON(json: any): ProcessingClassConstraints;
69
+ export declare function ProcessingClassConstraintsToJSONTyped(value?: ProcessingClassConstraints | null, ignoreDiscriminator?: boolean): any;
@@ -0,0 +1,49 @@
1
+ /* tslint:disable */
2
+ /* eslint-disable */
3
+ /**
4
+ * GISL Compression API
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
+ *
7
+ * The version of the OpenAPI document: 2.64.0
8
+ *
9
+ *
10
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
11
+ * https://openapi-generator.tech
12
+ * Do not edit the class manually.
13
+ */
14
+ /**
15
+ * Check if a given object implements the ProcessingClassConstraints interface.
16
+ */
17
+ export function instanceOfProcessingClassConstraints(value) {
18
+ return true;
19
+ }
20
+ export function ProcessingClassConstraintsFromJSON(json) {
21
+ return ProcessingClassConstraintsFromJSONTyped(json, false);
22
+ }
23
+ export function ProcessingClassConstraintsFromJSONTyped(json, ignoreDiscriminator) {
24
+ if (json == null) {
25
+ return json;
26
+ }
27
+ return {
28
+ 'maxInputDuration': json['max_input_duration'] == null ? undefined : json['max_input_duration'],
29
+ 'maxInputSizeBytes': json['max_input_size_bytes'] == null ? undefined : json['max_input_size_bytes'],
30
+ 'maxOutputSizeBytes': json['max_output_size_bytes'] == null ? undefined : json['max_output_size_bytes'],
31
+ 'maxTotalDuration': json['max_total_duration'] == null ? undefined : json['max_total_duration'],
32
+ 'maxTotalInputSizeBytes': json['max_total_input_size_bytes'] == null ? undefined : json['max_total_input_size_bytes'],
33
+ };
34
+ }
35
+ export function ProcessingClassConstraintsToJSON(json) {
36
+ return ProcessingClassConstraintsToJSONTyped(json, false);
37
+ }
38
+ export function ProcessingClassConstraintsToJSONTyped(value, ignoreDiscriminator = false) {
39
+ if (value == null) {
40
+ return value;
41
+ }
42
+ return {
43
+ 'max_input_duration': value['maxInputDuration'],
44
+ 'max_input_size_bytes': value['maxInputSizeBytes'],
45
+ 'max_output_size_bytes': value['maxOutputSizeBytes'],
46
+ 'max_total_duration': value['maxTotalDuration'],
47
+ 'max_total_input_size_bytes': value['maxTotalInputSizeBytes'],
48
+ };
49
+ }
@@ -0,0 +1,93 @@
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). **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.64.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
+ import type { ProcessingClassConstraints } from './ProcessingClassConstraints.js';
13
+ import type { UserTier } from './UserTier.js';
14
+ import type { AvailabilityValue } from './AvailabilityValue.js';
15
+ /**
16
+ * Single processing-class entry within a mime_group's
17
+ * `processing_class` map (per ticket
18
+ * [I15-CONS `YZpBKzOM`](https://trello.com/c/YZpBKzOM)). Mirrors
19
+ * `PerValueAvailabilityEntry` (availability + optional tier / eta /
20
+ * documentation_url) plus per-class `constraints` and an optional
21
+ * `per_tier_constraints` overlay. Surfaced on the typed getSchema
22
+ * model per ticket [`yWeBr81O`](https://trello.com/c/yWeBr81O).
23
+ * See `schemas/FORMAT.md` §`processing_class:` block.
24
+ *
25
+ * @export
26
+ * @interface ProcessingClassEntry
27
+ */
28
+ export interface ProcessingClassEntry {
29
+ /**
30
+ * Per-class availability tag.
31
+ * @type {AvailabilityValue}
32
+ * @memberof ProcessingClassEntry
33
+ */
34
+ availability: AvailabilityValue;
35
+ /**
36
+ *
37
+ * @type {UserTier}
38
+ * @memberof ProcessingClassEntry
39
+ */
40
+ requiredTier?: UserTier | null;
41
+ /**
42
+ * ISO-8601 date (`2026-09-15`) or quarter (`2026-Q3`) when
43
+ * this class is expected to ship. Only meaningful for
44
+ * `availability: planned`.
45
+ *
46
+ * @type {string}
47
+ * @memberof ProcessingClassEntry
48
+ */
49
+ eta?: string;
50
+ /**
51
+ * Optional link to processing-class documentation.
52
+ * @type {string}
53
+ * @memberof ProcessingClassEntry
54
+ */
55
+ documentationUrl?: string;
56
+ /**
57
+ * Baseline caps for the lowest tier this class's
58
+ * `required_tier` permits. Overlaid per-caller by
59
+ * `per_tier_constraints` (see below).
60
+ *
61
+ * @type {ProcessingClassConstraints}
62
+ * @memberof ProcessingClassEntry
63
+ */
64
+ constraints?: ProcessingClassConstraints;
65
+ /**
66
+ * Optional per-tier numeric-cap override map (per
67
+ * [ADR-0011](../docs/decisions/0011-per-tier-processing-class-constraints.md),
68
+ * ticket [`z4GDTUMx`](https://trello.com/c/z4GDTUMx)). Keys
69
+ * MUST be a subset of the `UserTier` enum and SHOULD name only
70
+ * tiers HIGHER than the class baseline (CI-enforced by
71
+ * `scripts/check-per-tier-constraints.py`). Each value
72
+ * overrides `constraints` field-by-field for callers of that
73
+ * tier. A consumer that ignores this map reads `constraints`
74
+ * and sees the smallest permitted-tier cap — it can never
75
+ * over-promise. `per_tier_constraints` sizes caps, it does
76
+ * NOT grant access (eligibility stays governed by
77
+ * `availability` + `required_tier`).
78
+ *
79
+ * @type {{ [key: string]: ProcessingClassConstraints; }}
80
+ * @memberof ProcessingClassEntry
81
+ */
82
+ perTierConstraints?: {
83
+ [key: string]: ProcessingClassConstraints;
84
+ };
85
+ }
86
+ /**
87
+ * Check if a given object implements the ProcessingClassEntry interface.
88
+ */
89
+ export declare function instanceOfProcessingClassEntry(value: object): value is ProcessingClassEntry;
90
+ export declare function ProcessingClassEntryFromJSON(json: any): ProcessingClassEntry;
91
+ export declare function ProcessingClassEntryFromJSONTyped(json: any, ignoreDiscriminator: boolean): ProcessingClassEntry;
92
+ export declare function ProcessingClassEntryToJSON(json: any): ProcessingClassEntry;
93
+ export declare function ProcessingClassEntryToJSONTyped(value?: ProcessingClassEntry | null, ignoreDiscriminator?: boolean): any;
@@ -0,0 +1,57 @@
1
+ /* tslint:disable */
2
+ /* eslint-disable */
3
+ /**
4
+ * GISL Compression API
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
+ *
7
+ * The version of the OpenAPI document: 2.64.0
8
+ *
9
+ *
10
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
11
+ * https://openapi-generator.tech
12
+ * Do not edit the class manually.
13
+ */
14
+ import { mapValues } from '../runtime.js';
15
+ import { ProcessingClassConstraintsFromJSON, ProcessingClassConstraintsToJSON, } from './ProcessingClassConstraints.js';
16
+ import { UserTierFromJSON, UserTierToJSON, } from './UserTier.js';
17
+ import { AvailabilityValueFromJSON, AvailabilityValueToJSON, } from './AvailabilityValue.js';
18
+ /**
19
+ * Check if a given object implements the ProcessingClassEntry interface.
20
+ */
21
+ export function instanceOfProcessingClassEntry(value) {
22
+ if (!('availability' in value) || value['availability'] === undefined)
23
+ return false;
24
+ return true;
25
+ }
26
+ export function ProcessingClassEntryFromJSON(json) {
27
+ return ProcessingClassEntryFromJSONTyped(json, false);
28
+ }
29
+ export function ProcessingClassEntryFromJSONTyped(json, ignoreDiscriminator) {
30
+ if (json == null) {
31
+ return json;
32
+ }
33
+ return {
34
+ 'availability': AvailabilityValueFromJSON(json['availability']),
35
+ 'requiredTier': json['required_tier'] == null ? undefined : UserTierFromJSON(json['required_tier']),
36
+ 'eta': json['eta'] == null ? undefined : json['eta'],
37
+ 'documentationUrl': json['documentation_url'] == null ? undefined : json['documentation_url'],
38
+ 'constraints': json['constraints'] == null ? undefined : ProcessingClassConstraintsFromJSON(json['constraints']),
39
+ 'perTierConstraints': json['per_tier_constraints'] == null ? undefined : (mapValues(json['per_tier_constraints'], ProcessingClassConstraintsFromJSON)),
40
+ };
41
+ }
42
+ export function ProcessingClassEntryToJSON(json) {
43
+ return ProcessingClassEntryToJSONTyped(json, false);
44
+ }
45
+ export function ProcessingClassEntryToJSONTyped(value, ignoreDiscriminator = false) {
46
+ if (value == null) {
47
+ return value;
48
+ }
49
+ return {
50
+ 'availability': AvailabilityValueToJSON(value['availability']),
51
+ 'required_tier': UserTierToJSON(value['requiredTier']),
52
+ 'eta': value['eta'],
53
+ 'documentation_url': value['documentationUrl'],
54
+ 'constraints': ProcessingClassConstraintsToJSON(value['constraints']),
55
+ 'per_tier_constraints': value['perTierConstraints'] == null ? undefined : (mapValues(value['perTierConstraints'], ProcessingClassConstraintsToJSON)),
56
+ };
57
+ }
@@ -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/Last-Modified 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). **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.31.0
5
+ * The version of the OpenAPI document: 2.64.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -77,6 +77,17 @@ export interface ProcessingClassExceedsBandResponse {
77
77
  * server-side capacity gate; distinct from tier-quota
78
78
  * rejections (`upload_size_exceeds_tier`).
79
79
  *
80
+ * Workflow-create code (per ticket
81
+ * [`nGYbgChX`](https://trello.com/c/nGYbgChX) / sdks
82
+ * [`DRjIyMt9`](https://trello.com/c/DRjIyMt9)):
83
+ * - `UPLOAD_NOT_FOUND` (404) — a `POST /api/workflows` request
84
+ * references an upload that does not exist OR exists but is
85
+ * owned by a different identity (deliberate BOLA/IDOR
86
+ * existence-mask: reported as not-found, **never 403**, so the
87
+ * response does not reveal another user's upload exists).
88
+ * `message_key: "upload.not_found"`. See the createWorkflow
89
+ * 404 response + ADR-0016 Amendment.
90
+ *
80
91
  * @type {string}
81
92
  * @memberof ProcessingClassExceedsBandResponse
82
93
  */
@@ -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/Last-Modified 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). **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.31.0
7
+ * The version of the OpenAPI document: 2.64.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/Last-Modified 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). **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.31.0
5
+ * The version of the OpenAPI document: 2.64.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/Last-Modified 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). **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.31.0
7
+ * The version of the OpenAPI document: 2.64.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/Last-Modified 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). **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.31.0
5
+ * The version of the OpenAPI document: 2.64.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/Last-Modified 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). **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.31.0
7
+ * The version of the OpenAPI document: 2.64.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/Last-Modified 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). **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.31.0
5
+ * The version of the OpenAPI document: 2.64.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/Last-Modified 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). **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.31.0
7
+ * The version of the OpenAPI document: 2.64.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).