@giveitsmaller/contracts 0.9.0 → 0.17.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 (446) hide show
  1. package/asyncapi/events.yaml +647 -60
  2. package/availability/availability.json +318 -94
  3. package/dist/asyncapi/Failure.d.ts +2 -0
  4. package/dist/asyncapi/LongFormOperationType.d.ts +2 -1
  5. package/dist/asyncapi/LongFormOperationType.js +1 -0
  6. package/dist/asyncapi/MultiOutputCompletion.d.ts +2 -0
  7. package/dist/asyncapi/{NotificationsOperationsQueue.d.ts → NotificationsJobsQueue.d.ts} +2 -2
  8. package/dist/asyncapi/OperationResultMetadata.d.ts +4 -0
  9. package/dist/asyncapi/OperationResultMetadata.js +1 -0
  10. package/dist/asyncapi/OperationType.d.ts +2 -1
  11. package/dist/asyncapi/OperationType.js +1 -0
  12. package/dist/asyncapi/PageIndexed.d.ts +1 -0
  13. package/dist/asyncapi/PositionIndexed.d.ts +1 -0
  14. package/dist/asyncapi/SingleOutputCompletion.d.ts +2 -0
  15. package/dist/asyncapi/SourceEntry.d.ts +2 -0
  16. package/dist/asyncapi/Unindexed.d.ts +1 -0
  17. package/dist/asyncapi/index.d.ts +2 -1
  18. package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +2 -2
  19. package/dist/openapi/models/AudioWatermarkDecodeRequest.js +2 -2
  20. package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +2 -2
  21. package/dist/openapi/models/AudioWatermarkDecodeResponse.js +2 -2
  22. package/dist/openapi/models/AuthErrorResponse.d.ts +13 -2
  23. package/dist/openapi/models/AuthErrorResponse.js +2 -2
  24. package/dist/openapi/models/AuthErrorType.d.ts +2 -2
  25. package/dist/openapi/models/AuthErrorType.js +2 -2
  26. package/dist/openapi/models/AuthRejectionEnvelope.d.ts +126 -0
  27. package/dist/openapi/models/AuthRejectionEnvelope.js +72 -0
  28. package/dist/openapi/models/AvailabilityValue.d.ts +2 -2
  29. package/dist/openapi/models/AvailabilityValue.js +2 -2
  30. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +13 -2
  31. package/dist/openapi/models/BalanceExhaustedResponse.js +2 -2
  32. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +2 -2
  33. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +2 -2
  34. package/dist/openapi/models/CallbackEventType.d.ts +2 -2
  35. package/dist/openapi/models/CallbackEventType.js +2 -2
  36. package/dist/openapi/models/ChangePasswordRequest.d.ts +38 -0
  37. package/dist/openapi/models/ChangePasswordRequest.js +47 -0
  38. package/dist/openapi/models/CompositionPlan.d.ts +72 -0
  39. package/dist/openapi/models/CompositionPlan.js +53 -0
  40. package/dist/openapi/models/CompositionPlanJob.d.ts +39 -0
  41. package/dist/openapi/models/CompositionPlanJob.js +48 -0
  42. package/dist/openapi/models/CompositionPlanOperation.d.ts +116 -0
  43. package/dist/openapi/models/CompositionPlanOperation.js +62 -0
  44. package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +46 -0
  45. package/dist/openapi/models/ConfirmEmailChange200Response.js +54 -0
  46. package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +32 -0
  47. package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +43 -0
  48. package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +32 -0
  49. package/dist/openapi/models/ConfirmEmailChangeRequest.js +43 -0
  50. package/dist/openapi/models/ConnectionSource.d.ts +2 -2
  51. package/dist/openapi/models/ConnectionSource.js +2 -2
  52. package/dist/openapi/models/ContactRequest.d.ts +2 -2
  53. package/dist/openapi/models/ContactRequest.js +2 -2
  54. package/dist/openapi/models/ContactSubject.d.ts +2 -2
  55. package/dist/openapi/models/ContactSubject.js +2 -2
  56. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +2 -2
  57. package/dist/openapi/models/ContactValidationErrorResponse.js +2 -2
  58. package/dist/openapi/models/CreateApiKey201Response.d.ts +46 -0
  59. package/dist/openapi/models/CreateApiKey201Response.js +54 -0
  60. package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +56 -0
  61. package/dist/openapi/models/CreateApiKey201ResponseData.js +59 -0
  62. package/dist/openapi/models/CreateApiKeyRequest.d.ts +32 -0
  63. package/dist/openapi/models/CreateApiKeyRequest.js +43 -0
  64. package/dist/openapi/models/CreateExternalImport403Response.d.ts +2 -2
  65. package/dist/openapi/models/CreateExternalImport403Response.js +2 -2
  66. package/dist/openapi/models/CreateExternalImport422Response.d.ts +2 -2
  67. package/dist/openapi/models/CreateExternalImport422Response.js +2 -2
  68. package/dist/openapi/models/CreateWorkflow422Response.d.ts +2 -2
  69. package/dist/openapi/models/CreateWorkflow422Response.js +2 -2
  70. package/dist/openapi/models/CreditTransaction.d.ts +2 -2
  71. package/dist/openapi/models/CreditTransaction.js +2 -2
  72. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +2 -2
  73. package/dist/openapi/models/CreditTransactionSourceBucket.js +2 -2
  74. package/dist/openapi/models/CreditsBalanceResponse.d.ts +2 -2
  75. package/dist/openapi/models/CreditsBalanceResponse.js +2 -2
  76. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +2 -2
  77. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +2 -2
  78. package/dist/openapi/models/CreditsUsageResponse.d.ts +2 -2
  79. package/dist/openapi/models/CreditsUsageResponse.js +2 -2
  80. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +2 -2
  81. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +2 -2
  82. package/dist/openapi/models/Delivery.d.ts +2 -2
  83. package/dist/openapi/models/Delivery.js +2 -2
  84. package/dist/openapi/models/DeliveryOutputRef.d.ts +9 -2
  85. package/dist/openapi/models/DeliveryOutputRef.js +2 -2
  86. package/dist/openapi/models/DeliveryPlan.d.ts +2 -2
  87. package/dist/openapi/models/DeliveryPlan.js +2 -2
  88. package/dist/openapi/models/DeliveryPlanOutput.d.ts +17 -2
  89. package/dist/openapi/models/DeliveryPlanOutput.js +4 -2
  90. package/dist/openapi/models/DeliveryPlanReason.d.ts +2 -2
  91. package/dist/openapi/models/DeliveryPlanReason.js +2 -2
  92. package/dist/openapi/models/DeliverySelection.d.ts +6 -4
  93. package/dist/openapi/models/DeliverySelection.js +2 -2
  94. package/dist/openapi/models/EmptySuccessEnvelope.d.ts +58 -0
  95. package/dist/openapi/models/EmptySuccessEnvelope.js +53 -0
  96. package/dist/openapi/models/EndpointProjection.d.ts +12 -3
  97. package/dist/openapi/models/EndpointProjection.js +2 -2
  98. package/dist/openapi/models/ErrorEnvelope.d.ts +13 -2
  99. package/dist/openapi/models/ErrorEnvelope.js +2 -2
  100. package/dist/openapi/models/EstimateQuality.d.ts +2 -2
  101. package/dist/openapi/models/EstimateQuality.js +2 -2
  102. package/dist/openapi/models/EstimateRange.d.ts +2 -2
  103. package/dist/openapi/models/EstimateRange.js +2 -2
  104. package/dist/openapi/models/ExternalDestination.d.ts +2 -2
  105. package/dist/openapi/models/ExternalDestination.js +2 -2
  106. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +2 -2
  107. package/dist/openapi/models/ExternalImportCreatedResponse.js +2 -2
  108. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +2 -2
  109. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +2 -2
  110. package/dist/openapi/models/ExternalImportRequest.d.ts +2 -2
  111. package/dist/openapi/models/ExternalImportRequest.js +2 -2
  112. package/dist/openapi/models/ExternalImportToken.d.ts +2 -2
  113. package/dist/openapi/models/ExternalImportToken.js +2 -2
  114. package/dist/openapi/models/ExternalSource.d.ts +2 -2
  115. package/dist/openapi/models/ExternalSource.js +2 -2
  116. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +13 -2
  117. package/dist/openapi/models/FeatureNotAvailableResponse.js +2 -2
  118. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +13 -2
  119. package/dist/openapi/models/FeatureTierRestrictedResponse.js +2 -2
  120. package/dist/openapi/models/FeatureViolation.d.ts +2 -2
  121. package/dist/openapi/models/FeatureViolation.js +2 -2
  122. package/dist/openapi/models/ForgotPasswordRequest.d.ts +32 -0
  123. package/dist/openapi/models/ForgotPasswordRequest.js +43 -0
  124. package/dist/openapi/models/ImageEncodeCapabilities.d.ts +65 -0
  125. package/dist/openapi/models/ImageEncodeCapabilities.js +55 -0
  126. package/dist/openapi/models/JobDefinition.d.ts +20 -4
  127. package/dist/openapi/models/JobDefinition.js +2 -2
  128. package/dist/openapi/models/JobDownload.d.ts +2 -2
  129. package/dist/openapi/models/JobDownload.js +2 -2
  130. package/dist/openapi/models/JobInputV2.d.ts +13 -9
  131. package/dist/openapi/models/JobInputV2.js +5 -5
  132. package/dist/openapi/models/JobMediaClass.d.ts +34 -0
  133. package/dist/openapi/models/JobMediaClass.js +52 -0
  134. package/dist/openapi/models/JobOutputSource.d.ts +2 -2
  135. package/dist/openapi/models/JobOutputSource.js +2 -2
  136. package/dist/openapi/models/JobResponse.d.ts +2 -2
  137. package/dist/openapi/models/JobResponse.js +2 -2
  138. package/dist/openapi/models/JobStatus.d.ts +2 -2
  139. package/dist/openapi/models/JobStatus.js +2 -2
  140. package/dist/openapi/models/JobType.d.ts +2 -2
  141. package/dist/openapi/models/JobType.js +2 -2
  142. package/dist/openapi/models/LivenessResponse.d.ts +2 -2
  143. package/dist/openapi/models/LivenessResponse.js +2 -2
  144. package/dist/openapi/models/LoginUser200Response.d.ts +2 -2
  145. package/dist/openapi/models/LoginUser200Response.js +2 -2
  146. package/dist/openapi/models/LoginUser200ResponseData.d.ts +2 -2
  147. package/dist/openapi/models/LoginUser200ResponseData.js +2 -2
  148. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +2 -2
  149. package/dist/openapi/models/LoginUser200ResponseDataUser.js +2 -2
  150. package/dist/openapi/models/LoginUserRequest.d.ts +2 -2
  151. package/dist/openapi/models/LoginUserRequest.js +2 -2
  152. package/dist/openapi/models/MetadataResponse.d.ts +2 -2
  153. package/dist/openapi/models/MetadataResponse.js +2 -2
  154. package/dist/openapi/models/MetadataResponseDimensions.d.ts +2 -2
  155. package/dist/openapi/models/MetadataResponseDimensions.js +2 -2
  156. package/dist/openapi/models/MetadataResponseExif.d.ts +2 -2
  157. package/dist/openapi/models/MetadataResponseExif.js +2 -2
  158. package/dist/openapi/models/MetadataResponseExifGps.d.ts +2 -2
  159. package/dist/openapi/models/MetadataResponseExifGps.js +2 -2
  160. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +2 -2
  161. package/dist/openapi/models/MetadataSuccessEnvelope.js +2 -2
  162. package/dist/openapi/models/MimeGroupSchema.d.ts +37 -2
  163. package/dist/openapi/models/MimeGroupSchema.js +5 -2
  164. package/dist/openapi/models/MultiInputSource.d.ts +41 -0
  165. package/dist/openapi/models/MultiInputSource.js +52 -0
  166. package/dist/openapi/models/MultipartCompleteRequest.d.ts +2 -2
  167. package/dist/openapi/models/MultipartCompleteRequest.js +2 -2
  168. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +2 -2
  169. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +2 -2
  170. package/dist/openapi/models/MultipartCompleteResponse.d.ts +2 -2
  171. package/dist/openapi/models/MultipartCompleteResponse.js +2 -2
  172. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +2 -2
  173. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +2 -2
  174. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +2 -2
  175. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +2 -2
  176. package/dist/openapi/models/MultipartInitiateResponse.d.ts +2 -2
  177. package/dist/openapi/models/MultipartInitiateResponse.js +2 -2
  178. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +2 -2
  179. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +2 -2
  180. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +2 -2
  181. package/dist/openapi/models/MultipartKeepaliveResponse.js +2 -2
  182. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +2 -2
  183. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +2 -2
  184. package/dist/openapi/models/MultipartPartListing.d.ts +2 -2
  185. package/dist/openapi/models/MultipartPartListing.js +2 -2
  186. package/dist/openapi/models/MultipartPresignRequest.d.ts +2 -2
  187. package/dist/openapi/models/MultipartPresignRequest.js +2 -2
  188. package/dist/openapi/models/MultipartPresignResponse.d.ts +2 -2
  189. package/dist/openapi/models/MultipartPresignResponse.js +2 -2
  190. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +2 -2
  191. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +2 -2
  192. package/dist/openapi/models/MultipartStatusResponse.d.ts +2 -2
  193. package/dist/openapi/models/MultipartStatusResponse.js +2 -2
  194. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +2 -2
  195. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +2 -2
  196. package/dist/openapi/models/OperationDefinition.d.ts +27 -2
  197. package/dist/openapi/models/OperationDefinition.js +11 -2
  198. package/dist/openapi/models/OperationDownload.d.ts +30 -2
  199. package/dist/openapi/models/OperationDownload.js +6 -2
  200. package/dist/openapi/models/OperationInputModel.d.ts +3 -3
  201. package/dist/openapi/models/OperationInputModel.js +3 -3
  202. package/dist/openapi/models/OperationResponse.d.ts +18 -2
  203. package/dist/openapi/models/OperationResponse.js +5 -2
  204. package/dist/openapi/models/OperationResult.d.ts +2 -2
  205. package/dist/openapi/models/OperationResult.js +2 -2
  206. package/dist/openapi/models/OperationResultMetadata.d.ts +48 -0
  207. package/dist/openapi/models/OperationResultMetadata.js +41 -0
  208. package/dist/openapi/models/OperationResultMetrics.d.ts +16 -3
  209. package/dist/openapi/models/OperationResultMetrics.js +2 -2
  210. package/dist/openapi/models/OperationSchemaDefinition.d.ts +6 -5
  211. package/dist/openapi/models/OperationSchemaDefinition.js +2 -2
  212. package/dist/openapi/models/OperationStatus.d.ts +2 -2
  213. package/dist/openapi/models/OperationStatus.js +2 -2
  214. package/dist/openapi/models/OperationType.d.ts +7 -4
  215. package/dist/openapi/models/OperationType.js +8 -5
  216. package/dist/openapi/models/OperationsSchemaResponse.d.ts +32 -4
  217. package/dist/openapi/models/OperationsSchemaResponse.js +5 -2
  218. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +2 -2
  219. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +2 -2
  220. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +2 -2
  221. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +2 -2
  222. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +2 -2
  223. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +2 -2
  224. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +2 -2
  225. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +2 -2
  226. package/dist/openapi/models/OptionSchema.d.ts +2 -2
  227. package/dist/openapi/models/OptionSchema.js +2 -2
  228. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +2 -2
  229. package/dist/openapi/models/PerRoleCardinalityEntry.js +2 -2
  230. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +2 -2
  231. package/dist/openapi/models/PerValueAvailabilityEntry.js +2 -2
  232. package/dist/openapi/models/PresignedUrlPart.d.ts +2 -2
  233. package/dist/openapi/models/PresignedUrlPart.js +2 -2
  234. package/dist/openapi/models/ProbePendingResponse.d.ts +13 -2
  235. package/dist/openapi/models/ProbePendingResponse.js +2 -2
  236. package/dist/openapi/models/ProcessingClass.d.ts +2 -2
  237. package/dist/openapi/models/ProcessingClass.js +2 -2
  238. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +2 -2
  239. package/dist/openapi/models/ProcessingClassBandViolation.js +2 -2
  240. package/dist/openapi/models/ProcessingClassConstraints.d.ts +69 -0
  241. package/dist/openapi/models/ProcessingClassConstraints.js +49 -0
  242. package/dist/openapi/models/ProcessingClassEntry.d.ts +93 -0
  243. package/dist/openapi/models/ProcessingClassEntry.js +57 -0
  244. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +13 -2
  245. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +2 -2
  246. package/dist/openapi/models/ProcessingClassHint.d.ts +2 -2
  247. package/dist/openapi/models/ProcessingClassHint.js +2 -2
  248. package/dist/openapi/models/ProcessingClassReason.d.ts +2 -2
  249. package/dist/openapi/models/ProcessingClassReason.js +2 -2
  250. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +2 -2
  251. package/dist/openapi/models/ProcessingClassRejectReason.js +2 -2
  252. package/dist/openapi/models/ProcessingPlan.d.ts +2 -2
  253. package/dist/openapi/models/ProcessingPlan.js +2 -2
  254. package/dist/openapi/models/ProcessingPlanJob.d.ts +2 -2
  255. package/dist/openapi/models/ProcessingPlanJob.js +2 -2
  256. package/dist/openapi/models/ReEncodeDecision.d.ts +2 -2
  257. package/dist/openapi/models/ReEncodeDecision.js +2 -2
  258. package/dist/openapi/models/ReadinessResponse.d.ts +2 -2
  259. package/dist/openapi/models/ReadinessResponse.js +2 -2
  260. package/dist/openapi/models/RegisterUser422Response.d.ts +27 -0
  261. package/dist/openapi/models/RegisterUser422Response.js +47 -0
  262. package/dist/openapi/models/RegisterUserRequest.d.ts +38 -0
  263. package/dist/openapi/models/RegisterUserRequest.js +47 -0
  264. package/dist/openapi/models/ResetPasswordRequest.d.ts +38 -0
  265. package/dist/openapi/models/ResetPasswordRequest.js +47 -0
  266. package/dist/openapi/models/ResponseEnvelope.d.ts +2 -2
  267. package/dist/openapi/models/ResponseEnvelope.js +2 -2
  268. package/dist/openapi/models/RetryResponse.d.ts +2 -2
  269. package/dist/openapi/models/RetryResponse.js +2 -2
  270. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +2 -2
  271. package/dist/openapi/models/RetrySuccessEnvelope.js +2 -2
  272. package/dist/openapi/models/SseCompletionBase.d.ts +2 -2
  273. package/dist/openapi/models/SseCompletionBase.js +2 -2
  274. package/dist/openapi/models/SseEventType.d.ts +2 -2
  275. package/dist/openapi/models/SseEventType.js +2 -2
  276. package/dist/openapi/models/SseJobCompletedData.d.ts +2 -2
  277. package/dist/openapi/models/SseJobCompletedData.js +2 -2
  278. package/dist/openapi/models/SseJobFailedData.d.ts +2 -2
  279. package/dist/openapi/models/SseJobFailedData.js +2 -2
  280. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +2 -2
  281. package/dist/openapi/models/SseMultiOutputCompletion.js +2 -2
  282. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +2 -2
  283. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +2 -2
  284. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +2 -2
  285. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +2 -2
  286. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +2 -2
  287. package/dist/openapi/models/SseMultiOutputResultEntry.js +2 -2
  288. package/dist/openapi/models/SseOperationCompletedData.d.ts +17 -3
  289. package/dist/openapi/models/SseOperationCompletedData.js +2 -2
  290. package/dist/openapi/models/SseOperationCompletionResult.d.ts +2 -2
  291. package/dist/openapi/models/SseOperationCompletionResult.js +2 -2
  292. package/dist/openapi/models/SseOperationFailedData.d.ts +2 -2
  293. package/dist/openapi/models/SseOperationFailedData.js +2 -2
  294. package/dist/openapi/models/SseOperationProgressData.d.ts +2 -2
  295. package/dist/openapi/models/SseOperationProgressData.js +2 -2
  296. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +2 -2
  297. package/dist/openapi/models/SseSingleOutputCompletion.js +2 -2
  298. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +2 -2
  299. package/dist/openapi/models/SseWorkflowTerminalData.js +2 -2
  300. package/dist/openapi/models/TierRestrictionKind.d.ts +2 -2
  301. package/dist/openapi/models/TierRestrictionKind.js +2 -2
  302. package/dist/openapi/models/TierRestrictionResponse.d.ts +13 -2
  303. package/dist/openapi/models/TierRestrictionResponse.js +2 -2
  304. package/dist/openapi/models/UpdateProfile200Response.d.ts +46 -0
  305. package/dist/openapi/models/UpdateProfile200Response.js +54 -0
  306. package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +71 -0
  307. package/dist/openapi/models/UpdateProfile200ResponseData.js +67 -0
  308. package/dist/openapi/models/UpdateProfile422Response.d.ts +27 -0
  309. package/dist/openapi/models/UpdateProfile422Response.js +47 -0
  310. package/dist/openapi/models/UpdateProfileRequest.d.ts +44 -0
  311. package/dist/openapi/models/UpdateProfileRequest.js +47 -0
  312. package/dist/openapi/models/UploadConstraintsApplied.d.ts +2 -2
  313. package/dist/openapi/models/UploadConstraintsApplied.js +2 -2
  314. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +13 -2
  315. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +2 -2
  316. package/dist/openapi/models/UploadFile403Response.d.ts +2 -2
  317. package/dist/openapi/models/UploadFile403Response.js +2 -2
  318. package/dist/openapi/models/UploadFile422Response.d.ts +2 -2
  319. package/dist/openapi/models/UploadFile422Response.js +2 -2
  320. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +2 -2
  321. package/dist/openapi/models/UploadProbeMediaMetadata.js +2 -2
  322. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +2 -2
  323. package/dist/openapi/models/UploadProbeProcessingClass.js +2 -2
  324. package/dist/openapi/models/UploadProbeResponse.d.ts +2 -2
  325. package/dist/openapi/models/UploadProbeResponse.js +2 -2
  326. package/dist/openapi/models/UploadProbeStatus.d.ts +2 -2
  327. package/dist/openapi/models/UploadProbeStatus.js +2 -2
  328. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +2 -2
  329. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +2 -2
  330. package/dist/openapi/models/UploadResponse.d.ts +2 -2
  331. package/dist/openapi/models/UploadResponse.js +2 -2
  332. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +13 -2
  333. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +2 -2
  334. package/dist/openapi/models/UploadSource.d.ts +2 -2
  335. package/dist/openapi/models/UploadSource.js +2 -2
  336. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +2 -2
  337. package/dist/openapi/models/UploadSuccessEnvelope.js +2 -2
  338. package/dist/openapi/models/UploadThresholds.d.ts +2 -2
  339. package/dist/openapi/models/UploadThresholds.js +2 -2
  340. package/dist/openapi/models/UserTier.d.ts +2 -2
  341. package/dist/openapi/models/UserTier.js +2 -2
  342. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +2 -2
  343. package/dist/openapi/models/ValidationErrorEnvelope.js +2 -2
  344. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +2 -2
  345. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +2 -2
  346. package/dist/openapi/models/VerifyEmailRequest.d.ts +32 -0
  347. package/dist/openapi/models/VerifyEmailRequest.js +43 -0
  348. package/dist/openapi/models/WarningType.d.ts +2 -2
  349. package/dist/openapi/models/WarningType.js +2 -2
  350. package/dist/openapi/models/WebhookOperationContext.d.ts +2 -2
  351. package/dist/openapi/models/WebhookOperationContext.js +2 -2
  352. package/dist/openapi/models/WebhookPayload.d.ts +2 -2
  353. package/dist/openapi/models/WebhookPayload.js +2 -2
  354. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +2 -2
  355. package/dist/openapi/models/WorkflowCancelBillingEffect.js +2 -2
  356. package/dist/openapi/models/WorkflowCancelResponse.d.ts +2 -2
  357. package/dist/openapi/models/WorkflowCancelResponse.js +2 -2
  358. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +2 -2
  359. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +2 -2
  360. package/dist/openapi/models/WorkflowCreateRequest.d.ts +64 -4
  361. package/dist/openapi/models/WorkflowCreateRequest.js +10 -6
  362. package/dist/openapi/models/WorkflowCreateResponse.d.ts +24 -2
  363. package/dist/openapi/models/WorkflowCreateResponse.js +5 -2
  364. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +2 -2
  365. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +2 -2
  366. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +2 -2
  367. package/dist/openapi/models/WorkflowDownloadResponse.js +2 -2
  368. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +2 -2
  369. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +2 -2
  370. package/dist/openapi/models/WorkflowEdge.d.ts +2 -2
  371. package/dist/openapi/models/WorkflowEdge.js +2 -2
  372. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +13 -2
  373. package/dist/openapi/models/WorkflowExpiredResponse.js +2 -2
  374. package/dist/openapi/models/WorkflowListResponse.d.ts +50 -0
  375. package/dist/openapi/models/WorkflowListResponse.js +50 -0
  376. package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +46 -0
  377. package/dist/openapi/models/WorkflowListSuccessEnvelope.js +54 -0
  378. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +2 -2
  379. package/dist/openapi/models/WorkflowPauseRequiredAction.js +2 -2
  380. package/dist/openapi/models/WorkflowPausedDetail.d.ts +2 -2
  381. package/dist/openapi/models/WorkflowPausedDetail.js +2 -2
  382. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +2 -2
  383. package/dist/openapi/models/WorkflowPausedDetailLinks.js +2 -2
  384. package/dist/openapi/models/WorkflowProcessing.d.ts +2 -2
  385. package/dist/openapi/models/WorkflowProcessing.js +2 -2
  386. package/dist/openapi/models/WorkflowResumeResponse.d.ts +2 -2
  387. package/dist/openapi/models/WorkflowResumeResponse.js +2 -2
  388. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +2 -2
  389. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +2 -2
  390. package/dist/openapi/models/WorkflowSource.d.ts +7 -4
  391. package/dist/openapi/models/WorkflowSource.js +2 -2
  392. package/dist/openapi/models/WorkflowStatus.d.ts +2 -2
  393. package/dist/openapi/models/WorkflowStatus.js +2 -2
  394. package/dist/openapi/models/WorkflowStatusResponse.d.ts +21 -2
  395. package/dist/openapi/models/WorkflowStatusResponse.js +5 -2
  396. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +2 -2
  397. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +2 -2
  398. package/dist/openapi/models/WorkflowSummary.d.ts +60 -0
  399. package/dist/openapi/models/WorkflowSummary.js +57 -0
  400. package/dist/openapi/models/WorkflowSummaryJob.d.ts +57 -0
  401. package/dist/openapi/models/WorkflowSummaryJob.js +57 -0
  402. package/dist/openapi/models/WorkflowWarning.d.ts +2 -2
  403. package/dist/openapi/models/WorkflowWarning.js +2 -2
  404. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +2 -2
  405. package/dist/openapi/models/WorkflowWarningSeverity.js +2 -2
  406. package/dist/openapi/models/index.d.ts +31 -1
  407. package/dist/openapi/models/index.js +31 -1
  408. package/dist/openapi/runtime.d.ts +2 -2
  409. package/dist/openapi/runtime.js +2 -2
  410. package/dist/operations/compress.d.ts +0 -9
  411. package/dist/operations/compress.js +0 -6
  412. package/dist/operations/compress.metadata.js +4 -12
  413. package/dist/operations/index.d.ts +3 -0
  414. package/dist/operations/index.js +3 -0
  415. package/dist/operations/merge.d.ts +4 -0
  416. package/dist/operations/merge.metadata.js +12 -0
  417. package/dist/operations/passthrough.metadata.d.ts +2 -0
  418. package/dist/operations/passthrough.metadata.js +6 -0
  419. package/dist/operations/render_variants.d.ts +24 -0
  420. package/dist/operations/render_variants.js +14 -0
  421. package/dist/operations/render_variants.metadata.d.ts +2 -0
  422. package/dist/operations/render_variants.metadata.js +18 -0
  423. package/dist/operations/split.d.ts +8 -1
  424. package/dist/operations/split.js +5 -0
  425. package/dist/operations/split.metadata.js +19 -6
  426. package/openapi/api.yaml +2333 -241
  427. package/operations/schemas/archive.yaml +1 -1
  428. package/operations/schemas/audio_overlay.yaml +29 -13
  429. package/operations/schemas/audio_to_video.yaml +6 -5
  430. package/operations/schemas/audio_watermark.yaml +18 -16
  431. package/operations/schemas/compress.yaml +60 -35
  432. package/operations/schemas/convert.yaml +6 -1
  433. package/operations/schemas/custom_luma.yaml +18 -3
  434. package/operations/schemas/image_watermark.yaml +22 -7
  435. package/operations/schemas/merge.yaml +88 -35
  436. package/operations/schemas/passthrough.yaml +49 -0
  437. package/operations/schemas/render_variants.yaml +117 -0
  438. package/operations/schemas/split.yaml +78 -20
  439. package/operations/schemas/text_watermark.yaml +6 -6
  440. package/operations/schemas/thumbnail.yaml +1 -1
  441. package/operations/schemas/video_text_watermark.yaml +2 -2
  442. package/operations/schemas/video_watermark.yaml +7 -4
  443. package/package.json +3 -1
  444. package/dist/openapi/models/LogoutUser200Response.d.ts +0 -50
  445. package/dist/openapi/models/LogoutUser200Response.js +0 -53
  446. /package/dist/asyncapi/{NotificationsOperationsQueue.js → NotificationsJobsQueue.js} +0 -0
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
5
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag/Last-Modified revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.31.0
7
+ * The version of the OpenAPI document: 2.66.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -42,6 +42,8 @@ export function OperationDownloadFromJSONTyped(json, ignoreDiscriminator) {
42
42
  'downloadUrl': json['download_url'],
43
43
  'pageIndex': json['page_index'] == null ? undefined : json['page_index'],
44
44
  'position': json['position'] == null ? undefined : json['position'],
45
+ 'targetId': json['target_id'] == null ? undefined : json['target_id'],
46
+ 'nodeId': json['node_id'] == null ? undefined : json['node_id'],
45
47
  };
46
48
  }
47
49
  export function OperationDownloadToJSON(json) {
@@ -59,5 +61,7 @@ export function OperationDownloadToJSONTyped(value, ignoreDiscriminator = false)
59
61
  'download_url': value['downloadUrl'],
60
62
  'page_index': value['pageIndex'],
61
63
  'position': value['position'],
64
+ 'target_id': value['targetId'],
65
+ 'node_id': value['nodeId'],
62
66
  };
63
67
  }
@@ -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.66.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -14,7 +14,7 @@
14
14
  * - single: One input file (compress, thumbnail, thumbnail_image,
15
15
  * thumbnail_video, thumbnail_document, thumbnail_office,
16
16
  * text_watermark, convert, audio_watermark,
17
- * video_text_watermark, split)
17
+ * video_text_watermark, split, passthrough)
18
18
  * - multi: Multiple input files (merge, archive, image_watermark, custom_luma, audio_overlay, audio_to_video, video_watermark). audio_to_video is the first role-based op with an OPTIONAL role (min_inputs=1, max_inputs=2 — see `per_role_cardinality`); video_watermark mirrors `image_watermark`'s 2-required pattern on video bases.
19
19
  *
20
20
  * @export
@@ -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.66.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -16,7 +16,7 @@
16
16
  * - single: One input file (compress, thumbnail, thumbnail_image,
17
17
  * thumbnail_video, thumbnail_document, thumbnail_office,
18
18
  * text_watermark, convert, audio_watermark,
19
- * video_text_watermark, split)
19
+ * video_text_watermark, split, passthrough)
20
20
  * - multi: Multiple input files (merge, archive, image_watermark, custom_luma, audio_overlay, audio_to_video, video_watermark). audio_to_video is the first role-based op with an OPTIONAL role (min_inputs=1, max_inputs=2 — see `per_role_cardinality`); video_watermark mirrors `image_watermark`'s 2-required pattern on video bases.
21
21
  *
22
22
  * @export
@@ -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.66.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -10,6 +10,7 @@
10
10
  * Do not edit the class manually.
11
11
  */
12
12
  import type { OperationStatus } from './OperationStatus.js';
13
+ import type { OperationResultMetadata } from './OperationResultMetadata.js';
13
14
  import type { OperationResult } from './OperationResult.js';
14
15
  import type { OperationType } from './OperationType.js';
15
16
  /**
@@ -48,6 +49,21 @@ export interface OperationResponse {
48
49
  * @memberof OperationResponse
49
50
  */
50
51
  result?: OperationResult;
52
+ /**
53
+ * Whitelisted operation-level metadata (the read projection — what
54
+ * `GET /api/workflows/{id}/status` emits per operation). Optional;
55
+ * present once an operation produces a whitelisted key. Distinct
56
+ * from `result` (the deliverable output): this carries small
57
+ * per-operation metadata, not the file. The `/status` read carries
58
+ * ONLY this `result_metadata` for op-level detail — the output
59
+ * `result` (`download_url`/`size_bytes`) is read via
60
+ * `GET /api/workflows/{id}/downloads` per the rmP7ndhK/ZjVXHkYK
61
+ * narrowing. Per ticket `dw048NKk` (A2) / `EurbZLMH` (B1).
62
+ *
63
+ * @type {OperationResultMetadata}
64
+ * @memberof OperationResponse
65
+ */
66
+ resultMetadata?: OperationResultMetadata;
51
67
  /**
52
68
  * Machine-readable failure code. Present when `status` is `failed`;
53
69
  * absent otherwise. Mirrors `SseOperationFailedData.error_code` — the
@@ -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.66.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -12,6 +12,7 @@
12
12
  * Do not edit the class manually.
13
13
  */
14
14
  import { OperationStatusFromJSON, OperationStatusToJSON, } from './OperationStatus.js';
15
+ import { OperationResultMetadataFromJSON, OperationResultMetadataToJSON, } from './OperationResultMetadata.js';
15
16
  import { OperationResultFromJSON, OperationResultToJSON, } from './OperationResult.js';
16
17
  import { OperationTypeFromJSON, OperationTypeToJSON, } from './OperationType.js';
17
18
  /**
@@ -39,6 +40,7 @@ export function OperationResponseFromJSONTyped(json, ignoreDiscriminator) {
39
40
  'status': OperationStatusFromJSON(json['status']),
40
41
  'progress': json['progress'] == null ? undefined : json['progress'],
41
42
  'result': json['result'] == null ? undefined : OperationResultFromJSON(json['result']),
43
+ 'resultMetadata': json['result_metadata'] == null ? undefined : OperationResultMetadataFromJSON(json['result_metadata']),
42
44
  'errorCode': json['error_code'] == null ? undefined : json['error_code'],
43
45
  'errorMessage': json['error_message'] == null ? undefined : json['error_message'],
44
46
  };
@@ -56,6 +58,7 @@ export function OperationResponseToJSONTyped(value, ignoreDiscriminator = false)
56
58
  'status': OperationStatusToJSON(value['status']),
57
59
  'progress': value['progress'],
58
60
  'result': OperationResultToJSON(value['result']),
61
+ 'result_metadata': OperationResultMetadataToJSON(value['resultMetadata']),
59
62
  'error_code': value['errorCode'],
60
63
  'error_message': value['errorMessage'],
61
64
  };
@@ -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.66.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.66.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -0,0 +1,48 @@
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.66.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
+ * Whitelisted, named operation-level result metadata — a **CLOSED**
14
+ * set of declared keys. The API serves ONLY these declared keys (a
15
+ * whitelist projection), never the raw stored metadata bag, so internal
16
+ * diagnostics never leak. New keys are **additive named cuts** (the
17
+ * `additionalProperties: false` closure is the point — an unmodelled
18
+ * key is a coordinated contract change, not a silent rollout). Twin of
19
+ * the AsyncAPI `OperationResultMetadata` (wire ↔ read parity). Distinct
20
+ * from `OperationResult` (the deliverable output file): this carries
21
+ * small per-operation metadata, not the output. Per `EurbZLMH` (B1).
22
+ *
23
+ * @export
24
+ * @interface OperationResultMetadata
25
+ */
26
+ export interface OperationResultMetadata {
27
+ /**
28
+ * UUIDv7 of the watermark embedded by an `audio_watermark`
29
+ * operation (for later decode/verify). **Display-only / not yet
30
+ * populated** — gated on the audio_watermark Lambda (`EvPl5fkH`,
31
+ * B3) + the watermark registry (B2, deferred). The field +
32
+ * whitelist ship now (additive) so the result_metadata pipeline +
33
+ * read projection land without a later contract bump; absent in
34
+ * practice until B3 is live.
35
+ *
36
+ * @type {string}
37
+ * @memberof OperationResultMetadata
38
+ */
39
+ watermarkId?: string;
40
+ }
41
+ /**
42
+ * Check if a given object implements the OperationResultMetadata interface.
43
+ */
44
+ export declare function instanceOfOperationResultMetadata(value: object): value is OperationResultMetadata;
45
+ export declare function OperationResultMetadataFromJSON(json: any): OperationResultMetadata;
46
+ export declare function OperationResultMetadataFromJSONTyped(json: any, ignoreDiscriminator: boolean): OperationResultMetadata;
47
+ export declare function OperationResultMetadataToJSON(json: any): OperationResultMetadata;
48
+ export declare function OperationResultMetadataToJSONTyped(value?: OperationResultMetadata | null, ignoreDiscriminator?: boolean): any;
@@ -0,0 +1,41 @@
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.66.0
8
+ *
9
+ *
10
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
11
+ * https://openapi-generator.tech
12
+ * Do not edit the class manually.
13
+ */
14
+ /**
15
+ * Check if a given object implements the OperationResultMetadata interface.
16
+ */
17
+ export function instanceOfOperationResultMetadata(value) {
18
+ return true;
19
+ }
20
+ export function OperationResultMetadataFromJSON(json) {
21
+ return OperationResultMetadataFromJSONTyped(json, false);
22
+ }
23
+ export function OperationResultMetadataFromJSONTyped(json, ignoreDiscriminator) {
24
+ if (json == null) {
25
+ return json;
26
+ }
27
+ return {
28
+ 'watermarkId': json['watermark_id'] == null ? undefined : json['watermark_id'],
29
+ };
30
+ }
31
+ export function OperationResultMetadataToJSON(json) {
32
+ return OperationResultMetadataToJSONTyped(json, false);
33
+ }
34
+ export function OperationResultMetadataToJSONTyped(value, ignoreDiscriminator = false) {
35
+ if (value == null) {
36
+ return value;
37
+ }
38
+ return {
39
+ 'watermark_id': value['watermarkId'],
40
+ };
41
+ }
@@ -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.66.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -11,7 +11,20 @@
11
11
  */
12
12
  import type { ReEncodeDecision } from './ReEncodeDecision.js';
13
13
  /**
14
- * Operation-specific performance metrics
14
+ * Operation-specific performance metrics, carried on the
15
+ * **completion result** surface (SSE `operation.completed`
16
+ * result / result-on-poll), NOT on the workflow **status**
17
+ * read (confirmed ZjVXHkYK / api). `GET /api/workflows/{id}`
18
+ * serialises each operation as `{id, type, status}` plus a
19
+ * conditional `error_message`/`error_code` — it does NOT carry
20
+ * `result.metrics`, so `re_encode_decision` / `re_encode_reason`
21
+ * are not readable from the status poll. Canonical reads for
22
+ * those: the per-job `processing_class` echo (on the status
23
+ * response) for the route, and `GET /api/workflows/{id}/downloads`
24
+ * (per-output `size_bytes`) for the authoritative output size.
25
+ * Note `metrics` has no `output_size_bytes` field — output size
26
+ * lives on `size_bytes` / the downloads endpoint.
27
+ *
15
28
  * @export
16
29
  * @interface OperationResultMetrics
17
30
  */
@@ -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.66.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.66.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -92,9 +92,10 @@ export interface OperationSchemaDefinition {
92
92
  * Optional per-role input-count overlay for role-based
93
93
  * multi-input operations. Per ticket
94
94
  * [`SlluxMBN`](https://trello.com/c/SlluxMBN) / ADR-0015.
95
- * Absent on operations whose role rules are still encoded
96
- * in prose only (image_watermark, audio_overlay,
97
- * custom_luma per-op migration follow-ups).
95
+ * Present on all five role-based ops (audio_to_video,
96
+ * video_watermark, audio_overlay, image_watermark,
97
+ * custom_luma); absent on non-role ops (merge, archive)
98
+ * where all inputs share a single role.
98
99
  *
99
100
  * @type {{ [key: string]: PerRoleCardinalityEntry; }}
100
101
  * @memberof OperationSchemaDefinition
@@ -2,9 +2,9 @@
2
2
  /* eslint-disable */
3
3
  /**
4
4
  * GISL Compression API
5
- * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag/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.66.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).