@giveitsmaller/contracts 0.9.0 → 0.16.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (443) hide show
  1. package/asyncapi/events.yaml +540 -42
  2. package/availability/availability.json +313 -89
  3. package/dist/asyncapi/Failure.d.ts +2 -0
  4. package/dist/asyncapi/MultiOutputCompletion.d.ts +2 -0
  5. package/dist/asyncapi/{NotificationsOperationsQueue.d.ts → NotificationsJobsQueue.d.ts} +2 -2
  6. package/dist/asyncapi/OperationResultMetadata.d.ts +4 -0
  7. package/dist/asyncapi/OperationResultMetadata.js +1 -0
  8. package/dist/asyncapi/OperationType.d.ts +2 -1
  9. package/dist/asyncapi/OperationType.js +1 -0
  10. package/dist/asyncapi/PageIndexed.d.ts +1 -0
  11. package/dist/asyncapi/PositionIndexed.d.ts +1 -0
  12. package/dist/asyncapi/SingleOutputCompletion.d.ts +2 -0
  13. package/dist/asyncapi/SourceEntry.d.ts +2 -0
  14. package/dist/asyncapi/Unindexed.d.ts +1 -0
  15. package/dist/asyncapi/index.d.ts +2 -1
  16. package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +2 -2
  17. package/dist/openapi/models/AudioWatermarkDecodeRequest.js +2 -2
  18. package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +2 -2
  19. package/dist/openapi/models/AudioWatermarkDecodeResponse.js +2 -2
  20. package/dist/openapi/models/AuthErrorResponse.d.ts +13 -2
  21. package/dist/openapi/models/AuthErrorResponse.js +2 -2
  22. package/dist/openapi/models/AuthErrorType.d.ts +2 -2
  23. package/dist/openapi/models/AuthErrorType.js +2 -2
  24. package/dist/openapi/models/AuthRejectionEnvelope.d.ts +126 -0
  25. package/dist/openapi/models/AuthRejectionEnvelope.js +72 -0
  26. package/dist/openapi/models/AvailabilityValue.d.ts +2 -2
  27. package/dist/openapi/models/AvailabilityValue.js +2 -2
  28. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +13 -2
  29. package/dist/openapi/models/BalanceExhaustedResponse.js +2 -2
  30. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +2 -2
  31. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +2 -2
  32. package/dist/openapi/models/CallbackEventType.d.ts +2 -2
  33. package/dist/openapi/models/CallbackEventType.js +2 -2
  34. package/dist/openapi/models/ChangePasswordRequest.d.ts +38 -0
  35. package/dist/openapi/models/ChangePasswordRequest.js +47 -0
  36. package/dist/openapi/models/CompositionPlan.d.ts +72 -0
  37. package/dist/openapi/models/CompositionPlan.js +53 -0
  38. package/dist/openapi/models/CompositionPlanJob.d.ts +39 -0
  39. package/dist/openapi/models/CompositionPlanJob.js +48 -0
  40. package/dist/openapi/models/CompositionPlanOperation.d.ts +116 -0
  41. package/dist/openapi/models/CompositionPlanOperation.js +62 -0
  42. package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +46 -0
  43. package/dist/openapi/models/ConfirmEmailChange200Response.js +54 -0
  44. package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +32 -0
  45. package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +43 -0
  46. package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +32 -0
  47. package/dist/openapi/models/ConfirmEmailChangeRequest.js +43 -0
  48. package/dist/openapi/models/ConnectionSource.d.ts +2 -2
  49. package/dist/openapi/models/ConnectionSource.js +2 -2
  50. package/dist/openapi/models/ContactRequest.d.ts +2 -2
  51. package/dist/openapi/models/ContactRequest.js +2 -2
  52. package/dist/openapi/models/ContactSubject.d.ts +2 -2
  53. package/dist/openapi/models/ContactSubject.js +2 -2
  54. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +2 -2
  55. package/dist/openapi/models/ContactValidationErrorResponse.js +2 -2
  56. package/dist/openapi/models/CreateApiKey201Response.d.ts +46 -0
  57. package/dist/openapi/models/CreateApiKey201Response.js +54 -0
  58. package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +56 -0
  59. package/dist/openapi/models/CreateApiKey201ResponseData.js +59 -0
  60. package/dist/openapi/models/CreateApiKeyRequest.d.ts +32 -0
  61. package/dist/openapi/models/CreateApiKeyRequest.js +43 -0
  62. package/dist/openapi/models/CreateExternalImport403Response.d.ts +2 -2
  63. package/dist/openapi/models/CreateExternalImport403Response.js +2 -2
  64. package/dist/openapi/models/CreateExternalImport422Response.d.ts +2 -2
  65. package/dist/openapi/models/CreateExternalImport422Response.js +2 -2
  66. package/dist/openapi/models/CreateWorkflow422Response.d.ts +2 -2
  67. package/dist/openapi/models/CreateWorkflow422Response.js +2 -2
  68. package/dist/openapi/models/CreditTransaction.d.ts +2 -2
  69. package/dist/openapi/models/CreditTransaction.js +2 -2
  70. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +2 -2
  71. package/dist/openapi/models/CreditTransactionSourceBucket.js +2 -2
  72. package/dist/openapi/models/CreditsBalanceResponse.d.ts +2 -2
  73. package/dist/openapi/models/CreditsBalanceResponse.js +2 -2
  74. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +2 -2
  75. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +2 -2
  76. package/dist/openapi/models/CreditsUsageResponse.d.ts +2 -2
  77. package/dist/openapi/models/CreditsUsageResponse.js +2 -2
  78. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +2 -2
  79. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +2 -2
  80. package/dist/openapi/models/Delivery.d.ts +2 -2
  81. package/dist/openapi/models/Delivery.js +2 -2
  82. package/dist/openapi/models/DeliveryOutputRef.d.ts +9 -2
  83. package/dist/openapi/models/DeliveryOutputRef.js +2 -2
  84. package/dist/openapi/models/DeliveryPlan.d.ts +2 -2
  85. package/dist/openapi/models/DeliveryPlan.js +2 -2
  86. package/dist/openapi/models/DeliveryPlanOutput.d.ts +17 -2
  87. package/dist/openapi/models/DeliveryPlanOutput.js +4 -2
  88. package/dist/openapi/models/DeliveryPlanReason.d.ts +2 -2
  89. package/dist/openapi/models/DeliveryPlanReason.js +2 -2
  90. package/dist/openapi/models/DeliverySelection.d.ts +6 -4
  91. package/dist/openapi/models/DeliverySelection.js +2 -2
  92. package/dist/openapi/models/EmptySuccessEnvelope.d.ts +58 -0
  93. package/dist/openapi/models/EmptySuccessEnvelope.js +53 -0
  94. package/dist/openapi/models/EndpointProjection.d.ts +12 -3
  95. package/dist/openapi/models/EndpointProjection.js +2 -2
  96. package/dist/openapi/models/ErrorEnvelope.d.ts +13 -2
  97. package/dist/openapi/models/ErrorEnvelope.js +2 -2
  98. package/dist/openapi/models/EstimateQuality.d.ts +2 -2
  99. package/dist/openapi/models/EstimateQuality.js +2 -2
  100. package/dist/openapi/models/EstimateRange.d.ts +2 -2
  101. package/dist/openapi/models/EstimateRange.js +2 -2
  102. package/dist/openapi/models/ExternalDestination.d.ts +2 -2
  103. package/dist/openapi/models/ExternalDestination.js +2 -2
  104. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +2 -2
  105. package/dist/openapi/models/ExternalImportCreatedResponse.js +2 -2
  106. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +2 -2
  107. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +2 -2
  108. package/dist/openapi/models/ExternalImportRequest.d.ts +2 -2
  109. package/dist/openapi/models/ExternalImportRequest.js +2 -2
  110. package/dist/openapi/models/ExternalImportToken.d.ts +2 -2
  111. package/dist/openapi/models/ExternalImportToken.js +2 -2
  112. package/dist/openapi/models/ExternalSource.d.ts +2 -2
  113. package/dist/openapi/models/ExternalSource.js +2 -2
  114. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +13 -2
  115. package/dist/openapi/models/FeatureNotAvailableResponse.js +2 -2
  116. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +13 -2
  117. package/dist/openapi/models/FeatureTierRestrictedResponse.js +2 -2
  118. package/dist/openapi/models/FeatureViolation.d.ts +2 -2
  119. package/dist/openapi/models/FeatureViolation.js +2 -2
  120. package/dist/openapi/models/ForgotPasswordRequest.d.ts +32 -0
  121. package/dist/openapi/models/ForgotPasswordRequest.js +43 -0
  122. package/dist/openapi/models/ImageEncodeCapabilities.d.ts +65 -0
  123. package/dist/openapi/models/ImageEncodeCapabilities.js +55 -0
  124. package/dist/openapi/models/JobDefinition.d.ts +20 -4
  125. package/dist/openapi/models/JobDefinition.js +2 -2
  126. package/dist/openapi/models/JobDownload.d.ts +2 -2
  127. package/dist/openapi/models/JobDownload.js +2 -2
  128. package/dist/openapi/models/JobInputV2.d.ts +13 -9
  129. package/dist/openapi/models/JobInputV2.js +5 -5
  130. package/dist/openapi/models/JobMediaClass.d.ts +34 -0
  131. package/dist/openapi/models/JobMediaClass.js +52 -0
  132. package/dist/openapi/models/JobOutputSource.d.ts +2 -2
  133. package/dist/openapi/models/JobOutputSource.js +2 -2
  134. package/dist/openapi/models/JobResponse.d.ts +2 -2
  135. package/dist/openapi/models/JobResponse.js +2 -2
  136. package/dist/openapi/models/JobStatus.d.ts +2 -2
  137. package/dist/openapi/models/JobStatus.js +2 -2
  138. package/dist/openapi/models/JobType.d.ts +2 -2
  139. package/dist/openapi/models/JobType.js +2 -2
  140. package/dist/openapi/models/LivenessResponse.d.ts +2 -2
  141. package/dist/openapi/models/LivenessResponse.js +2 -2
  142. package/dist/openapi/models/LoginUser200Response.d.ts +2 -2
  143. package/dist/openapi/models/LoginUser200Response.js +2 -2
  144. package/dist/openapi/models/LoginUser200ResponseData.d.ts +2 -2
  145. package/dist/openapi/models/LoginUser200ResponseData.js +2 -2
  146. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +2 -2
  147. package/dist/openapi/models/LoginUser200ResponseDataUser.js +2 -2
  148. package/dist/openapi/models/LoginUserRequest.d.ts +2 -2
  149. package/dist/openapi/models/LoginUserRequest.js +2 -2
  150. package/dist/openapi/models/MetadataResponse.d.ts +2 -2
  151. package/dist/openapi/models/MetadataResponse.js +2 -2
  152. package/dist/openapi/models/MetadataResponseDimensions.d.ts +2 -2
  153. package/dist/openapi/models/MetadataResponseDimensions.js +2 -2
  154. package/dist/openapi/models/MetadataResponseExif.d.ts +2 -2
  155. package/dist/openapi/models/MetadataResponseExif.js +2 -2
  156. package/dist/openapi/models/MetadataResponseExifGps.d.ts +2 -2
  157. package/dist/openapi/models/MetadataResponseExifGps.js +2 -2
  158. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +2 -2
  159. package/dist/openapi/models/MetadataSuccessEnvelope.js +2 -2
  160. package/dist/openapi/models/MimeGroupSchema.d.ts +37 -2
  161. package/dist/openapi/models/MimeGroupSchema.js +5 -2
  162. package/dist/openapi/models/MultiInputSource.d.ts +41 -0
  163. package/dist/openapi/models/MultiInputSource.js +52 -0
  164. package/dist/openapi/models/MultipartCompleteRequest.d.ts +2 -2
  165. package/dist/openapi/models/MultipartCompleteRequest.js +2 -2
  166. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +2 -2
  167. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +2 -2
  168. package/dist/openapi/models/MultipartCompleteResponse.d.ts +2 -2
  169. package/dist/openapi/models/MultipartCompleteResponse.js +2 -2
  170. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +2 -2
  171. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +2 -2
  172. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +2 -2
  173. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +2 -2
  174. package/dist/openapi/models/MultipartInitiateResponse.d.ts +2 -2
  175. package/dist/openapi/models/MultipartInitiateResponse.js +2 -2
  176. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +2 -2
  177. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +2 -2
  178. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +2 -2
  179. package/dist/openapi/models/MultipartKeepaliveResponse.js +2 -2
  180. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +2 -2
  181. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +2 -2
  182. package/dist/openapi/models/MultipartPartListing.d.ts +2 -2
  183. package/dist/openapi/models/MultipartPartListing.js +2 -2
  184. package/dist/openapi/models/MultipartPresignRequest.d.ts +2 -2
  185. package/dist/openapi/models/MultipartPresignRequest.js +2 -2
  186. package/dist/openapi/models/MultipartPresignResponse.d.ts +2 -2
  187. package/dist/openapi/models/MultipartPresignResponse.js +2 -2
  188. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +2 -2
  189. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +2 -2
  190. package/dist/openapi/models/MultipartStatusResponse.d.ts +2 -2
  191. package/dist/openapi/models/MultipartStatusResponse.js +2 -2
  192. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +2 -2
  193. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +2 -2
  194. package/dist/openapi/models/OperationDefinition.d.ts +27 -2
  195. package/dist/openapi/models/OperationDefinition.js +11 -2
  196. package/dist/openapi/models/OperationDownload.d.ts +30 -2
  197. package/dist/openapi/models/OperationDownload.js +6 -2
  198. package/dist/openapi/models/OperationInputModel.d.ts +3 -3
  199. package/dist/openapi/models/OperationInputModel.js +3 -3
  200. package/dist/openapi/models/OperationResponse.d.ts +18 -2
  201. package/dist/openapi/models/OperationResponse.js +5 -2
  202. package/dist/openapi/models/OperationResult.d.ts +2 -2
  203. package/dist/openapi/models/OperationResult.js +2 -2
  204. package/dist/openapi/models/OperationResultMetadata.d.ts +48 -0
  205. package/dist/openapi/models/OperationResultMetadata.js +41 -0
  206. package/dist/openapi/models/OperationResultMetrics.d.ts +16 -3
  207. package/dist/openapi/models/OperationResultMetrics.js +2 -2
  208. package/dist/openapi/models/OperationSchemaDefinition.d.ts +6 -5
  209. package/dist/openapi/models/OperationSchemaDefinition.js +2 -2
  210. package/dist/openapi/models/OperationStatus.d.ts +2 -2
  211. package/dist/openapi/models/OperationStatus.js +2 -2
  212. package/dist/openapi/models/OperationType.d.ts +7 -4
  213. package/dist/openapi/models/OperationType.js +8 -5
  214. package/dist/openapi/models/OperationsSchemaResponse.d.ts +32 -4
  215. package/dist/openapi/models/OperationsSchemaResponse.js +5 -2
  216. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +2 -2
  217. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +2 -2
  218. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +2 -2
  219. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +2 -2
  220. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +2 -2
  221. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +2 -2
  222. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +2 -2
  223. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +2 -2
  224. package/dist/openapi/models/OptionSchema.d.ts +2 -2
  225. package/dist/openapi/models/OptionSchema.js +2 -2
  226. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +2 -2
  227. package/dist/openapi/models/PerRoleCardinalityEntry.js +2 -2
  228. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +2 -2
  229. package/dist/openapi/models/PerValueAvailabilityEntry.js +2 -2
  230. package/dist/openapi/models/PresignedUrlPart.d.ts +2 -2
  231. package/dist/openapi/models/PresignedUrlPart.js +2 -2
  232. package/dist/openapi/models/ProbePendingResponse.d.ts +13 -2
  233. package/dist/openapi/models/ProbePendingResponse.js +2 -2
  234. package/dist/openapi/models/ProcessingClass.d.ts +2 -2
  235. package/dist/openapi/models/ProcessingClass.js +2 -2
  236. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +2 -2
  237. package/dist/openapi/models/ProcessingClassBandViolation.js +2 -2
  238. package/dist/openapi/models/ProcessingClassConstraints.d.ts +69 -0
  239. package/dist/openapi/models/ProcessingClassConstraints.js +49 -0
  240. package/dist/openapi/models/ProcessingClassEntry.d.ts +93 -0
  241. package/dist/openapi/models/ProcessingClassEntry.js +57 -0
  242. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +13 -2
  243. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +2 -2
  244. package/dist/openapi/models/ProcessingClassHint.d.ts +2 -2
  245. package/dist/openapi/models/ProcessingClassHint.js +2 -2
  246. package/dist/openapi/models/ProcessingClassReason.d.ts +2 -2
  247. package/dist/openapi/models/ProcessingClassReason.js +2 -2
  248. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +2 -2
  249. package/dist/openapi/models/ProcessingClassRejectReason.js +2 -2
  250. package/dist/openapi/models/ProcessingPlan.d.ts +2 -2
  251. package/dist/openapi/models/ProcessingPlan.js +2 -2
  252. package/dist/openapi/models/ProcessingPlanJob.d.ts +2 -2
  253. package/dist/openapi/models/ProcessingPlanJob.js +2 -2
  254. package/dist/openapi/models/ReEncodeDecision.d.ts +2 -2
  255. package/dist/openapi/models/ReEncodeDecision.js +2 -2
  256. package/dist/openapi/models/ReadinessResponse.d.ts +2 -2
  257. package/dist/openapi/models/ReadinessResponse.js +2 -2
  258. package/dist/openapi/models/RegisterUser422Response.d.ts +27 -0
  259. package/dist/openapi/models/RegisterUser422Response.js +47 -0
  260. package/dist/openapi/models/RegisterUserRequest.d.ts +38 -0
  261. package/dist/openapi/models/RegisterUserRequest.js +47 -0
  262. package/dist/openapi/models/ResetPasswordRequest.d.ts +38 -0
  263. package/dist/openapi/models/ResetPasswordRequest.js +47 -0
  264. package/dist/openapi/models/ResponseEnvelope.d.ts +2 -2
  265. package/dist/openapi/models/ResponseEnvelope.js +2 -2
  266. package/dist/openapi/models/RetryResponse.d.ts +2 -2
  267. package/dist/openapi/models/RetryResponse.js +2 -2
  268. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +2 -2
  269. package/dist/openapi/models/RetrySuccessEnvelope.js +2 -2
  270. package/dist/openapi/models/SseCompletionBase.d.ts +2 -2
  271. package/dist/openapi/models/SseCompletionBase.js +2 -2
  272. package/dist/openapi/models/SseEventType.d.ts +2 -2
  273. package/dist/openapi/models/SseEventType.js +2 -2
  274. package/dist/openapi/models/SseJobCompletedData.d.ts +2 -2
  275. package/dist/openapi/models/SseJobCompletedData.js +2 -2
  276. package/dist/openapi/models/SseJobFailedData.d.ts +2 -2
  277. package/dist/openapi/models/SseJobFailedData.js +2 -2
  278. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +2 -2
  279. package/dist/openapi/models/SseMultiOutputCompletion.js +2 -2
  280. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +2 -2
  281. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +2 -2
  282. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +2 -2
  283. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +2 -2
  284. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +2 -2
  285. package/dist/openapi/models/SseMultiOutputResultEntry.js +2 -2
  286. package/dist/openapi/models/SseOperationCompletedData.d.ts +17 -3
  287. package/dist/openapi/models/SseOperationCompletedData.js +2 -2
  288. package/dist/openapi/models/SseOperationCompletionResult.d.ts +2 -2
  289. package/dist/openapi/models/SseOperationCompletionResult.js +2 -2
  290. package/dist/openapi/models/SseOperationFailedData.d.ts +2 -2
  291. package/dist/openapi/models/SseOperationFailedData.js +2 -2
  292. package/dist/openapi/models/SseOperationProgressData.d.ts +2 -2
  293. package/dist/openapi/models/SseOperationProgressData.js +2 -2
  294. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +2 -2
  295. package/dist/openapi/models/SseSingleOutputCompletion.js +2 -2
  296. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +2 -2
  297. package/dist/openapi/models/SseWorkflowTerminalData.js +2 -2
  298. package/dist/openapi/models/TierRestrictionKind.d.ts +2 -2
  299. package/dist/openapi/models/TierRestrictionKind.js +2 -2
  300. package/dist/openapi/models/TierRestrictionResponse.d.ts +13 -2
  301. package/dist/openapi/models/TierRestrictionResponse.js +2 -2
  302. package/dist/openapi/models/UpdateProfile200Response.d.ts +46 -0
  303. package/dist/openapi/models/UpdateProfile200Response.js +54 -0
  304. package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +71 -0
  305. package/dist/openapi/models/UpdateProfile200ResponseData.js +67 -0
  306. package/dist/openapi/models/UpdateProfile422Response.d.ts +27 -0
  307. package/dist/openapi/models/UpdateProfile422Response.js +47 -0
  308. package/dist/openapi/models/UpdateProfileRequest.d.ts +44 -0
  309. package/dist/openapi/models/UpdateProfileRequest.js +47 -0
  310. package/dist/openapi/models/UploadConstraintsApplied.d.ts +2 -2
  311. package/dist/openapi/models/UploadConstraintsApplied.js +2 -2
  312. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +13 -2
  313. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +2 -2
  314. package/dist/openapi/models/UploadFile403Response.d.ts +2 -2
  315. package/dist/openapi/models/UploadFile403Response.js +2 -2
  316. package/dist/openapi/models/UploadFile422Response.d.ts +2 -2
  317. package/dist/openapi/models/UploadFile422Response.js +2 -2
  318. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +2 -2
  319. package/dist/openapi/models/UploadProbeMediaMetadata.js +2 -2
  320. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +2 -2
  321. package/dist/openapi/models/UploadProbeProcessingClass.js +2 -2
  322. package/dist/openapi/models/UploadProbeResponse.d.ts +2 -2
  323. package/dist/openapi/models/UploadProbeResponse.js +2 -2
  324. package/dist/openapi/models/UploadProbeStatus.d.ts +2 -2
  325. package/dist/openapi/models/UploadProbeStatus.js +2 -2
  326. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +2 -2
  327. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +2 -2
  328. package/dist/openapi/models/UploadResponse.d.ts +2 -2
  329. package/dist/openapi/models/UploadResponse.js +2 -2
  330. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +13 -2
  331. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +2 -2
  332. package/dist/openapi/models/UploadSource.d.ts +2 -2
  333. package/dist/openapi/models/UploadSource.js +2 -2
  334. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +2 -2
  335. package/dist/openapi/models/UploadSuccessEnvelope.js +2 -2
  336. package/dist/openapi/models/UploadThresholds.d.ts +2 -2
  337. package/dist/openapi/models/UploadThresholds.js +2 -2
  338. package/dist/openapi/models/UserTier.d.ts +2 -2
  339. package/dist/openapi/models/UserTier.js +2 -2
  340. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +2 -2
  341. package/dist/openapi/models/ValidationErrorEnvelope.js +2 -2
  342. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +2 -2
  343. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +2 -2
  344. package/dist/openapi/models/VerifyEmailRequest.d.ts +32 -0
  345. package/dist/openapi/models/VerifyEmailRequest.js +43 -0
  346. package/dist/openapi/models/WarningType.d.ts +2 -2
  347. package/dist/openapi/models/WarningType.js +2 -2
  348. package/dist/openapi/models/WebhookOperationContext.d.ts +2 -2
  349. package/dist/openapi/models/WebhookOperationContext.js +2 -2
  350. package/dist/openapi/models/WebhookPayload.d.ts +2 -2
  351. package/dist/openapi/models/WebhookPayload.js +2 -2
  352. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +2 -2
  353. package/dist/openapi/models/WorkflowCancelBillingEffect.js +2 -2
  354. package/dist/openapi/models/WorkflowCancelResponse.d.ts +2 -2
  355. package/dist/openapi/models/WorkflowCancelResponse.js +2 -2
  356. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +2 -2
  357. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +2 -2
  358. package/dist/openapi/models/WorkflowCreateRequest.d.ts +64 -4
  359. package/dist/openapi/models/WorkflowCreateRequest.js +10 -6
  360. package/dist/openapi/models/WorkflowCreateResponse.d.ts +24 -2
  361. package/dist/openapi/models/WorkflowCreateResponse.js +5 -2
  362. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +2 -2
  363. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +2 -2
  364. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +2 -2
  365. package/dist/openapi/models/WorkflowDownloadResponse.js +2 -2
  366. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +2 -2
  367. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +2 -2
  368. package/dist/openapi/models/WorkflowEdge.d.ts +2 -2
  369. package/dist/openapi/models/WorkflowEdge.js +2 -2
  370. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +13 -2
  371. package/dist/openapi/models/WorkflowExpiredResponse.js +2 -2
  372. package/dist/openapi/models/WorkflowListResponse.d.ts +50 -0
  373. package/dist/openapi/models/WorkflowListResponse.js +50 -0
  374. package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +46 -0
  375. package/dist/openapi/models/WorkflowListSuccessEnvelope.js +54 -0
  376. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +2 -2
  377. package/dist/openapi/models/WorkflowPauseRequiredAction.js +2 -2
  378. package/dist/openapi/models/WorkflowPausedDetail.d.ts +2 -2
  379. package/dist/openapi/models/WorkflowPausedDetail.js +2 -2
  380. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +2 -2
  381. package/dist/openapi/models/WorkflowPausedDetailLinks.js +2 -2
  382. package/dist/openapi/models/WorkflowProcessing.d.ts +2 -2
  383. package/dist/openapi/models/WorkflowProcessing.js +2 -2
  384. package/dist/openapi/models/WorkflowResumeResponse.d.ts +2 -2
  385. package/dist/openapi/models/WorkflowResumeResponse.js +2 -2
  386. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +2 -2
  387. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +2 -2
  388. package/dist/openapi/models/WorkflowSource.d.ts +7 -4
  389. package/dist/openapi/models/WorkflowSource.js +2 -2
  390. package/dist/openapi/models/WorkflowStatus.d.ts +2 -2
  391. package/dist/openapi/models/WorkflowStatus.js +2 -2
  392. package/dist/openapi/models/WorkflowStatusResponse.d.ts +21 -2
  393. package/dist/openapi/models/WorkflowStatusResponse.js +5 -2
  394. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +2 -2
  395. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +2 -2
  396. package/dist/openapi/models/WorkflowSummary.d.ts +60 -0
  397. package/dist/openapi/models/WorkflowSummary.js +57 -0
  398. package/dist/openapi/models/WorkflowSummaryJob.d.ts +57 -0
  399. package/dist/openapi/models/WorkflowSummaryJob.js +57 -0
  400. package/dist/openapi/models/WorkflowWarning.d.ts +2 -2
  401. package/dist/openapi/models/WorkflowWarning.js +2 -2
  402. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +2 -2
  403. package/dist/openapi/models/WorkflowWarningSeverity.js +2 -2
  404. package/dist/openapi/models/index.d.ts +31 -1
  405. package/dist/openapi/models/index.js +31 -1
  406. package/dist/openapi/runtime.d.ts +2 -2
  407. package/dist/openapi/runtime.js +2 -2
  408. package/dist/operations/compress.d.ts +0 -9
  409. package/dist/operations/compress.js +0 -6
  410. package/dist/operations/compress.metadata.js +4 -12
  411. package/dist/operations/index.d.ts +3 -0
  412. package/dist/operations/index.js +3 -0
  413. package/dist/operations/merge.d.ts +4 -0
  414. package/dist/operations/merge.metadata.js +12 -0
  415. package/dist/operations/passthrough.metadata.d.ts +2 -0
  416. package/dist/operations/passthrough.metadata.js +6 -0
  417. package/dist/operations/render_variants.d.ts +24 -0
  418. package/dist/operations/render_variants.js +14 -0
  419. package/dist/operations/render_variants.metadata.d.ts +2 -0
  420. package/dist/operations/render_variants.metadata.js +18 -0
  421. package/dist/operations/split.d.ts +8 -1
  422. package/dist/operations/split.js +5 -0
  423. package/dist/operations/split.metadata.js +18 -5
  424. package/openapi/api.yaml +2333 -241
  425. package/operations/schemas/archive.yaml +1 -1
  426. package/operations/schemas/audio_overlay.yaml +29 -13
  427. package/operations/schemas/audio_to_video.yaml +6 -5
  428. package/operations/schemas/audio_watermark.yaml +18 -16
  429. package/operations/schemas/compress.yaml +34 -32
  430. package/operations/schemas/custom_luma.yaml +18 -3
  431. package/operations/schemas/image_watermark.yaml +22 -7
  432. package/operations/schemas/merge.yaml +88 -35
  433. package/operations/schemas/passthrough.yaml +49 -0
  434. package/operations/schemas/render_variants.yaml +117 -0
  435. package/operations/schemas/split.yaml +72 -18
  436. package/operations/schemas/text_watermark.yaml +6 -6
  437. package/operations/schemas/thumbnail.yaml +1 -1
  438. package/operations/schemas/video_text_watermark.yaml +2 -2
  439. package/operations/schemas/video_watermark.yaml +7 -4
  440. package/package.json +3 -1
  441. package/dist/openapi/models/LogoutUser200Response.d.ts +0 -50
  442. package/dist/openapi/models/LogoutUser200Response.js +0 -53
  443. /package/dist/asyncapi/{NotificationsOperationsQueue.js → NotificationsJobsQueue.js} +0 -0
@@ -0,0 +1,65 @@
1
+ /**
2
+ * GISL Compression API
3
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
+ *
5
+ * The version of the OpenAPI document: 2.64.0
6
+ *
7
+ *
8
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
9
+ * https://openapi-generator.tech
10
+ * Do not edit the class manually.
11
+ */
12
+ /**
13
+ * Image-encode-stage capability flags that gate format/quality
14
+ * choices for the canonical `encode` node. **Image-encode-scoped**
15
+ * — these caveats apply to the image encode pass only, not to
16
+ * video / audio / document encoding. Surfaced so FE/SDK do not
17
+ * promise capabilities the worker cannot honour (e.g. a WebP
18
+ * quality slider the convert path silently ignores).
19
+ *
20
+ * @export
21
+ * @interface ImageEncodeCapabilities
22
+ */
23
+ export interface ImageEncodeCapabilities {
24
+ /**
25
+ * Whether quality-controlled (lossy) WebP encode is available.
26
+ * `false` today: WebP via the convert/encode path is
27
+ * lossless-only and the `quality` option is silently ignored
28
+ * (quality-controlled WebP is only reachable via `compress`).
29
+ * Consumers MUST NOT offer a WebP quality control when this is
30
+ * `false`.
31
+ *
32
+ * @type {boolean}
33
+ * @memberof ImageEncodeCapabilities
34
+ */
35
+ webpQualitySupported: boolean;
36
+ /**
37
+ * Whether alpha→non-alpha background flattening is available at
38
+ * encode time. `conditional` today: flatten fires only when an
39
+ * alpha source is encoded to a non-alpha output (e.g. PNG→JPEG).
40
+ * - `unsupported`: never applied.
41
+ * - `conditional`: applied only on alpha→non-alpha transitions.
42
+ * - `supported`: always available.
43
+ *
44
+ * @type {ImageEncodeCapabilitiesBackgroundFlattenEnum}
45
+ * @memberof ImageEncodeCapabilities
46
+ */
47
+ backgroundFlatten: ImageEncodeCapabilitiesBackgroundFlattenEnum;
48
+ }
49
+ /**
50
+ * @export
51
+ */
52
+ export declare const ImageEncodeCapabilitiesBackgroundFlattenEnum: {
53
+ readonly unsupported: "unsupported";
54
+ readonly conditional: "conditional";
55
+ readonly supported: "supported";
56
+ };
57
+ export type ImageEncodeCapabilitiesBackgroundFlattenEnum = typeof ImageEncodeCapabilitiesBackgroundFlattenEnum[keyof typeof ImageEncodeCapabilitiesBackgroundFlattenEnum];
58
+ /**
59
+ * Check if a given object implements the ImageEncodeCapabilities interface.
60
+ */
61
+ export declare function instanceOfImageEncodeCapabilities(value: object): value is ImageEncodeCapabilities;
62
+ export declare function ImageEncodeCapabilitiesFromJSON(json: any): ImageEncodeCapabilities;
63
+ export declare function ImageEncodeCapabilitiesFromJSONTyped(json: any, ignoreDiscriminator: boolean): ImageEncodeCapabilities;
64
+ export declare function ImageEncodeCapabilitiesToJSON(json: any): ImageEncodeCapabilities;
65
+ export declare function ImageEncodeCapabilitiesToJSONTyped(value?: ImageEncodeCapabilities | null, ignoreDiscriminator?: boolean): any;
@@ -0,0 +1,55 @@
1
+ /* tslint:disable */
2
+ /* eslint-disable */
3
+ /**
4
+ * GISL Compression API
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
+ *
7
+ * The version of the OpenAPI document: 2.64.0
8
+ *
9
+ *
10
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
11
+ * https://openapi-generator.tech
12
+ * Do not edit the class manually.
13
+ */
14
+ /**
15
+ * @export
16
+ */
17
+ export const ImageEncodeCapabilitiesBackgroundFlattenEnum = {
18
+ unsupported: 'unsupported',
19
+ conditional: 'conditional',
20
+ supported: 'supported'
21
+ };
22
+ /**
23
+ * Check if a given object implements the ImageEncodeCapabilities interface.
24
+ */
25
+ export function instanceOfImageEncodeCapabilities(value) {
26
+ if (!('webpQualitySupported' in value) || value['webpQualitySupported'] === undefined)
27
+ return false;
28
+ if (!('backgroundFlatten' in value) || value['backgroundFlatten'] === undefined)
29
+ return false;
30
+ return true;
31
+ }
32
+ export function ImageEncodeCapabilitiesFromJSON(json) {
33
+ return ImageEncodeCapabilitiesFromJSONTyped(json, false);
34
+ }
35
+ export function ImageEncodeCapabilitiesFromJSONTyped(json, ignoreDiscriminator) {
36
+ if (json == null) {
37
+ return json;
38
+ }
39
+ return {
40
+ 'webpQualitySupported': json['webp_quality_supported'],
41
+ 'backgroundFlatten': json['background_flatten'],
42
+ };
43
+ }
44
+ export function ImageEncodeCapabilitiesToJSON(json) {
45
+ return ImageEncodeCapabilitiesToJSONTyped(json, false);
46
+ }
47
+ export function ImageEncodeCapabilitiesToJSONTyped(value, ignoreDiscriminator = false) {
48
+ if (value == null) {
49
+ return value;
50
+ }
51
+ return {
52
+ 'webp_quality_supported': value['webpQualitySupported'],
53
+ 'background_flatten': value['backgroundFlatten'],
54
+ };
55
+ }
@@ -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).
@@ -98,7 +98,10 @@ export interface JobDefinition {
98
98
  * Multi-input list for `merge`, `archive`, `image_watermark`,
99
99
  * `custom_luma`, `audio_overlay`, `audio_to_video`, and
100
100
  * `video_watermark`. Each
101
- * entry is a `JobInputV2` with its own `WorkflowSource`.
101
+ * entry is a `JobInputV2` with its own `MultiInputSource` (the
102
+ * 3-leaf subset of `WorkflowSource` that excludes upload-direct;
103
+ * uploads enter via a `passthrough` source job referenced by
104
+ * `job_output`).
102
105
  * Mutually exclusive with `source` — the V2 shape boundary
103
106
  * stays `source` (single-input) XOR `inputs[]` (multi-input
104
107
  * role-based) per ADR-0004 / I12.
@@ -117,10 +120,23 @@ export interface JobDefinition {
117
120
  */
118
121
  inputs?: Array<JobInputV2>;
119
122
  /**
120
- * Ordered list of operations. Executed sequentially each
123
+ * Unordered **set** of operations for this job. The API
124
+ * canonicalizes them to a deterministic order — submitted order
125
+ * does not affect the result (same set, any order → same plan →
126
+ * same bytes). The resolved canonical order is echoed in the
127
+ * response `composition_plan` (see
128
+ * `WorkflowCreateResponse.composition_plan`). Each canonical chain
121
129
  * operation consumes the previous operation's output; all
122
130
  * intermediate and final outputs are kept.
123
131
  *
132
+ * Order-independence is over a *well-formed* set: conflicting or
133
+ * duplicate same-stage operations (e.g. two `compress` with
134
+ * different options) are resolved or rejected by the
135
+ * canonicalization engine — the contract does not enumerate the
136
+ * conflict-resolution rules (engine-side, like the opaque
137
+ * processing-time estimator). A rejected set surfaces as a
138
+ * `validation_error` (422); it is not silently ordered.
139
+ *
124
140
  * Multi-input jobs (with `inputs[]`) must have exactly one
125
141
  * operation, and it must be a multi-input type (`merge`,
126
142
  * `archive`, `image_watermark`, `custom_luma`,
@@ -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,22 +1,26 @@
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).
9
9
  * https://openapi-generator.tech
10
10
  * Do not edit the class manually.
11
11
  */
12
- import type { WorkflowSource } from './WorkflowSource.js';
12
+ import type { MultiInputSource } from './MultiInputSource.js';
13
13
  /**
14
14
  * V2 multi-input entry per [ADR-0004](../docs/decisions/0004-job-shape.md)
15
15
  * §"JobInputV2". Replaces V1 `JobInput`. Each entry carries its own
16
- * `source` (a `WorkflowSource` value — same union used at
17
- * `JobDefinition.source`), so multi-input jobs can mix uploads,
18
- * external imports, vault connections, and upstream job outputs
19
- * within a single inputs[] array.
16
+ * `source` (a `MultiInputSource` value — the 3-leaf subset of
17
+ * `WorkflowSource` that **excludes upload-direct**), so multi-input
18
+ * jobs can mix external imports, vault connections, and upstream job
19
+ * outputs within a single inputs[] array. An uploaded file enters a
20
+ * multi-input op via a `passthrough` source job (single-input,
21
+ * `operations: [{type: passthrough}]`) referenced here as
22
+ * `{ type: job_output, from: <id> }` — not as a direct `upload`
23
+ * source (per ticket [`4som89Uh`](https://trello.com/c/4som89Uh)).
20
24
  *
21
25
  * @export
22
26
  * @interface JobInputV2
@@ -24,10 +28,10 @@ import type { WorkflowSource } from './WorkflowSource.js';
24
28
  export interface JobInputV2 {
25
29
  /**
26
30
  *
27
- * @type {WorkflowSource}
31
+ * @type {MultiInputSource}
28
32
  * @memberof JobInputV2
29
33
  */
30
- source: WorkflowSource;
34
+ source: MultiInputSource;
31
35
  /**
32
36
  * Role for role-based multi-input operations:
33
37
  * - `image_watermark`: REQUIRED; values `base` (the source
@@ -2,16 +2,16 @@
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).
11
11
  * https://openapi-generator.tech
12
12
  * Do not edit the class manually.
13
13
  */
14
- import { WorkflowSourceFromJSON, WorkflowSourceToJSON, } from './WorkflowSource.js';
14
+ import { MultiInputSourceFromJSON, MultiInputSourceToJSON, } from './MultiInputSource.js';
15
15
  /**
16
16
  * @export
17
17
  */
@@ -36,7 +36,7 @@ export function JobInputV2FromJSONTyped(json, ignoreDiscriminator) {
36
36
  return json;
37
37
  }
38
38
  return {
39
- 'source': WorkflowSourceFromJSON(json['source']),
39
+ 'source': MultiInputSourceFromJSON(json['source']),
40
40
  'role': json['role'] == null ? undefined : json['role'],
41
41
  'perInputOptions': json['per_input_options'] == null ? undefined : json['per_input_options'],
42
42
  };
@@ -49,7 +49,7 @@ export function JobInputV2ToJSONTyped(value, ignoreDiscriminator = false) {
49
49
  return value;
50
50
  }
51
51
  return {
52
- 'source': WorkflowSourceToJSON(value['source']),
52
+ 'source': MultiInputSourceToJSON(value['source']),
53
53
  'role': value['role'],
54
54
  'per_input_options': value['perInputOptions'],
55
55
  };
@@ -0,0 +1,34 @@
1
+ /**
2
+ * GISL Compression API
3
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
+ *
5
+ * The version of the OpenAPI document: 2.64.0
6
+ *
7
+ *
8
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
9
+ * https://openapi-generator.tech
10
+ * Do not edit the class manually.
11
+ */
12
+ /**
13
+ * The media class of a job (the kind of media it processes), distinct
14
+ * from an operation's step `type` (`convert` / `compress` / …). `mixed`
15
+ * is a multi-input job spanning more than one class (e.g. an archive or
16
+ * a merge of heterogeneous inputs). Used in the lightweight workflows
17
+ * list row so a UI can label/group rows by media without drilling into
18
+ * per-operation detail.
19
+ *
20
+ * @export
21
+ */
22
+ export declare const JobMediaClass: {
23
+ readonly image: "image";
24
+ readonly video: "video";
25
+ readonly audio: "audio";
26
+ readonly document: "document";
27
+ readonly mixed: "mixed";
28
+ };
29
+ export type JobMediaClass = typeof JobMediaClass[keyof typeof JobMediaClass];
30
+ export declare function instanceOfJobMediaClass(value: any): boolean;
31
+ export declare function JobMediaClassFromJSON(json: any): JobMediaClass;
32
+ export declare function JobMediaClassFromJSONTyped(json: any, ignoreDiscriminator: boolean): JobMediaClass;
33
+ export declare function JobMediaClassToJSON(value?: JobMediaClass | null): any;
34
+ export declare function JobMediaClassToJSONTyped(value: any, ignoreDiscriminator: boolean): JobMediaClass;
@@ -0,0 +1,52 @@
1
+ /* tslint:disable */
2
+ /* eslint-disable */
3
+ /**
4
+ * GISL Compression API
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
+ *
7
+ * The version of the OpenAPI document: 2.64.0
8
+ *
9
+ *
10
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
11
+ * https://openapi-generator.tech
12
+ * Do not edit the class manually.
13
+ */
14
+ /**
15
+ * The media class of a job (the kind of media it processes), distinct
16
+ * from an operation's step `type` (`convert` / `compress` / …). `mixed`
17
+ * is a multi-input job spanning more than one class (e.g. an archive or
18
+ * a merge of heterogeneous inputs). Used in the lightweight workflows
19
+ * list row so a UI can label/group rows by media without drilling into
20
+ * per-operation detail.
21
+ *
22
+ * @export
23
+ */
24
+ export const JobMediaClass = {
25
+ image: 'image',
26
+ video: 'video',
27
+ audio: 'audio',
28
+ document: 'document',
29
+ mixed: 'mixed'
30
+ };
31
+ export function instanceOfJobMediaClass(value) {
32
+ for (const key in JobMediaClass) {
33
+ if (Object.prototype.hasOwnProperty.call(JobMediaClass, key)) {
34
+ if (JobMediaClass[key] === value) {
35
+ return true;
36
+ }
37
+ }
38
+ }
39
+ return false;
40
+ }
41
+ export function JobMediaClassFromJSON(json) {
42
+ return JobMediaClassFromJSONTyped(json, false);
43
+ }
44
+ export function JobMediaClassFromJSONTyped(json, ignoreDiscriminator) {
45
+ return json;
46
+ }
47
+ export function JobMediaClassToJSON(value) {
48
+ return value;
49
+ }
50
+ export function JobMediaClassToJSONTyped(value, ignoreDiscriminator) {
51
+ return value;
52
+ }
@@ -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).