@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
@@ -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).
@@ -11,22 +11,82 @@
11
11
  */
12
12
  import type { WorkflowEdge } from './WorkflowEdge.js';
13
13
  import type { CallbackEventType } from './CallbackEventType.js';
14
+ import type { WorkflowSource } from './WorkflowSource.js';
14
15
  import type { Delivery } from './Delivery.js';
16
+ import type { OperationDefinition } from './OperationDefinition.js';
15
17
  import type { JobDefinition } from './JobDefinition.js';
16
18
  import type { WorkflowProcessing } from './WorkflowProcessing.js';
17
19
  import type { ExternalDestination } from './ExternalDestination.js';
18
20
  /**
21
+ * Create a workflow. **Two mutually-exclusive request forms:**
22
+ *
23
+ * - **Explicit jobs** — `jobs[]` (+ optional `workflow_edges`), the
24
+ * full multi-job DAG form. Use for multi-job workflows, role-based
25
+ * / multi-input operations, output-as-role-input chains, explicit
26
+ * edges, or `delivery.selection.type: explicit`.
27
+ * - **Flat (single-job sugar)** — top-level `source` + `operations[]`,
28
+ * **exactly equivalent to `jobs: [{ source, operations }]`** (per
29
+ * ticket [`D0Gsri8V`](https://trello.com/c/D0Gsri8V)). The server
30
+ * lowers it into one `JobDefinition` and validates it as such —
31
+ * inheriting every `JobDefinition` guard verbatim — then runs the
32
+ * existing single-job canonicalizer. For the file-first
33
+ * dump-and-go case: one input + a set of single-input operations
34
+ * (a chain plus `base`-derived branches like thumbnail / split).
35
+ *
36
+ * The two forms are mutually exclusive (a request supplies exactly
37
+ * one — enforced by the `oneOf` below); they are NOT combined.
38
+ *
39
+ * Because the flat form lowers to ONE single-input job, its
40
+ * `operations[]` admits only **single-input** operation types. The
41
+ * multi-input / role operations (`merge`, `archive`,
42
+ * `image_watermark`, `custom_luma`, `audio_overlay`,
43
+ * `audio_to_video`, `video_watermark` — the enum at the
44
+ * `JobDefinition` multi-input guard) require `inputs[]` and MUST use
45
+ * the explicit `jobs[]` form; the server rejects them in flat mode
46
+ * via that same `JobDefinition` guard after lowering (not a
47
+ * separate structural rule). The flat form also does **not** support
48
+ * `workflow_edges` or `delivery.selection.type: explicit` — both
49
+ * need a named job id the single implicit job has none of; use
50
+ * explicit `jobs[]` for those. Delivery defaults and selection
51
+ * otherwise behave exactly as for one explicit job.
19
52
  *
20
53
  * @export
21
54
  * @interface WorkflowCreateRequest
22
55
  */
23
56
  export interface WorkflowCreateRequest {
24
57
  /**
25
- * List of jobs in this workflow
58
+ * List of jobs in this workflow (the explicit-jobs form).
59
+ * Mutually exclusive with the flat `source` + `operations`
60
+ * form — supply exactly one.
61
+ *
26
62
  * @type {Array<JobDefinition>}
27
63
  * @memberof WorkflowCreateRequest
28
64
  */
29
- jobs: Array<JobDefinition>;
65
+ jobs?: Array<JobDefinition>;
66
+ /**
67
+ * Flat-form single input source. Present only in the flat form
68
+ * (with `operations`); equivalent to a single explicit job's
69
+ * `source`. Single-input `WorkflowSource` (4-leaf union incl.
70
+ * `upload`) — multi-input role-based jobs use explicit
71
+ * `jobs[].inputs[]`. See the schema description for the
72
+ * flat/explicit mutex.
73
+ *
74
+ * @type {WorkflowSource}
75
+ * @memberof WorkflowCreateRequest
76
+ */
77
+ source?: WorkflowSource;
78
+ /**
79
+ * Flat-form operation set (the unordered operations applied to
80
+ * the top-level `source`). Present only in the flat form (with
81
+ * `source`); equivalent to a single explicit job's
82
+ * `operations[]` and lowered + canonicalized identically.
83
+ * Single-input operation types only (see the schema
84
+ * description). Each entry is an `OperationDefinition`.
85
+ *
86
+ * @type {Array<OperationDefinition>}
87
+ * @memberof WorkflowCreateRequest
88
+ */
89
+ operations?: Array<OperationDefinition>;
30
90
  /**
31
91
  * DAG dependency edges between jobs. Each edge defines that a downstream
32
92
  * job depends on an upstream job's output. Jobs with no incoming edges
@@ -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).
@@ -13,7 +13,9 @@
13
13
  */
14
14
  import { WorkflowEdgeFromJSON, WorkflowEdgeToJSON, } from './WorkflowEdge.js';
15
15
  import { CallbackEventTypeFromJSON, CallbackEventTypeToJSON, } from './CallbackEventType.js';
16
+ import { WorkflowSourceFromJSON, WorkflowSourceToJSON, } from './WorkflowSource.js';
16
17
  import { DeliveryFromJSON, DeliveryToJSON, } from './Delivery.js';
18
+ import { OperationDefinitionFromJSON, OperationDefinitionToJSON, } from './OperationDefinition.js';
17
19
  import { JobDefinitionFromJSON, JobDefinitionToJSON, } from './JobDefinition.js';
18
20
  import { WorkflowProcessingFromJSON, WorkflowProcessingToJSON, } from './WorkflowProcessing.js';
19
21
  import { ExternalDestinationFromJSON, ExternalDestinationToJSON, } from './ExternalDestination.js';
@@ -21,8 +23,6 @@ import { ExternalDestinationFromJSON, ExternalDestinationToJSON, } from './Exter
21
23
  * Check if a given object implements the WorkflowCreateRequest interface.
22
24
  */
23
25
  export function instanceOfWorkflowCreateRequest(value) {
24
- if (!('jobs' in value) || value['jobs'] === undefined)
25
- return false;
26
26
  return true;
27
27
  }
28
28
  export function WorkflowCreateRequestFromJSON(json) {
@@ -33,7 +33,9 @@ export function WorkflowCreateRequestFromJSONTyped(json, ignoreDiscriminator) {
33
33
  return json;
34
34
  }
35
35
  return {
36
- 'jobs': (json['jobs'].map(JobDefinitionFromJSON)),
36
+ 'jobs': json['jobs'] == null ? undefined : (json['jobs'].map(JobDefinitionFromJSON)),
37
+ 'source': json['source'] == null ? undefined : WorkflowSourceFromJSON(json['source']),
38
+ 'operations': json['operations'] == null ? undefined : (json['operations'].map(OperationDefinitionFromJSON)),
37
39
  'workflowEdges': json['workflow_edges'] == null ? undefined : (json['workflow_edges'].map(WorkflowEdgeFromJSON)),
38
40
  'callbackUrl': json['callback_url'] == null ? undefined : json['callback_url'],
39
41
  'callbackEvents': json['callback_events'] == null ? undefined : (json['callback_events'].map(CallbackEventTypeFromJSON)),
@@ -50,7 +52,9 @@ export function WorkflowCreateRequestToJSONTyped(value, ignoreDiscriminator = fa
50
52
  return value;
51
53
  }
52
54
  return {
53
- 'jobs': (value['jobs'].map(JobDefinitionToJSON)),
55
+ 'jobs': value['jobs'] == null ? undefined : (value['jobs'].map(JobDefinitionToJSON)),
56
+ 'source': WorkflowSourceToJSON(value['source']),
57
+ 'operations': value['operations'] == null ? undefined : (value['operations'].map(OperationDefinitionToJSON)),
54
58
  'workflow_edges': value['workflowEdges'] == null ? undefined : (value['workflowEdges'].map(WorkflowEdgeToJSON)),
55
59
  'callback_url': value['callbackUrl'],
56
60
  'callback_events': value['callbackEvents'] == null ? undefined : (value['callbackEvents'].map(CallbackEventTypeToJSON)),
@@ -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).
@@ -10,6 +10,7 @@
10
10
  * Do not edit the class manually.
11
11
  */
12
12
  import type { DeliveryPlan } from './DeliveryPlan.js';
13
+ import type { CompositionPlan } from './CompositionPlan.js';
13
14
  import type { WorkflowWarning } from './WorkflowWarning.js';
14
15
  import type { JobResponse } from './JobResponse.js';
15
16
  import type { ProcessingPlan } from './ProcessingPlan.js';
@@ -77,6 +78,27 @@ export interface WorkflowCreateResponse {
77
78
  * @memberof WorkflowCreateResponse
78
79
  */
79
80
  processingPlan: ProcessingPlan;
81
+ /**
82
+ * Server-computed canonical composition plan — the single
83
+ * source of truth for how the submitted operation **set** was
84
+ * canonicalized into a deterministic DAG (canonical order,
85
+ * per-op chain group/position, derived-artifact lineage, and
86
+ * image-encode capabilities). Frontend + SDK read this instead
87
+ * of hardcoding the pipeline order (which today lives only in
88
+ * the API), so click-order never changes the result.
89
+ *
90
+ * **OPTIONAL (optional-then-promote).** The canonicalization
91
+ * engine that emits it ships in later phases of the
92
+ * operation-composition epic; until it is live the server omits
93
+ * this field rather than emitting a partial plan. Promoted to
94
+ * required once the engine emits reliably (the same
95
+ * optional-then-promote path `delivery_plan` / `processing_plan`
96
+ * took). Consumers MUST treat it as may-be-absent.
97
+ *
98
+ * @type {CompositionPlan}
99
+ * @memberof WorkflowCreateResponse
100
+ */
101
+ compositionPlan?: CompositionPlan;
80
102
  /**
81
103
  * Advisory non-blocking warnings detected at
82
104
  * workflow-create time per ticket
@@ -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).
@@ -12,6 +12,7 @@
12
12
  * Do not edit the class manually.
13
13
  */
14
14
  import { DeliveryPlanFromJSON, DeliveryPlanToJSON, } from './DeliveryPlan.js';
15
+ import { CompositionPlanFromJSON, CompositionPlanToJSON, } from './CompositionPlan.js';
15
16
  import { WorkflowWarningFromJSON, WorkflowWarningToJSON, } from './WorkflowWarning.js';
16
17
  import { JobResponseFromJSON, JobResponseToJSON, } from './JobResponse.js';
17
18
  import { ProcessingPlanFromJSON, ProcessingPlanToJSON, } from './ProcessingPlan.js';
@@ -50,6 +51,7 @@ export function WorkflowCreateResponseFromJSONTyped(json, ignoreDiscriminator) {
50
51
  'jobs': (json['jobs'].map(JobResponseFromJSON)),
51
52
  'deliveryPlan': DeliveryPlanFromJSON(json['delivery_plan']),
52
53
  'processingPlan': ProcessingPlanFromJSON(json['processing_plan']),
54
+ 'compositionPlan': json['composition_plan'] == null ? undefined : CompositionPlanFromJSON(json['composition_plan']),
53
55
  'warnings': (json['warnings'].map(WorkflowWarningFromJSON)),
54
56
  'webhookSecret': json['webhook_secret'] == null ? undefined : json['webhook_secret'],
55
57
  };
@@ -68,6 +70,7 @@ export function WorkflowCreateResponseToJSONTyped(value, ignoreDiscriminator = f
68
70
  'jobs': (value['jobs'].map(JobResponseToJSON)),
69
71
  'delivery_plan': DeliveryPlanToJSON(value['deliveryPlan']),
70
72
  'processing_plan': ProcessingPlanToJSON(value['processingPlan']),
73
+ 'composition_plan': CompositionPlanToJSON(value['compositionPlan']),
71
74
  'warnings': (value['warnings'].map(WorkflowWarningToJSON)),
72
75
  };
73
76
  }
@@ -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).
@@ -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).