@giveitsmaller/contracts 0.7.0 → 0.8.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 (335) hide show
  1. package/asyncapi/events.yaml +278 -4
  2. package/availability/availability.json +11 -7
  3. package/dist/asyncapi/AnonymousSchema_253.d.ts +5 -0
  4. package/dist/asyncapi/AnonymousSchema_253.js +6 -0
  5. package/dist/asyncapi/LongFormJobMessage.d.ts +10 -0
  6. package/dist/asyncapi/LongFormJobMessage.js +1 -0
  7. package/dist/asyncapi/index.d.ts +2 -0
  8. package/dist/asyncapi/index.js +1 -0
  9. package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +2 -2
  10. package/dist/openapi/models/AudioWatermarkDecodeRequest.js +2 -2
  11. package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +2 -2
  12. package/dist/openapi/models/AudioWatermarkDecodeResponse.js +2 -2
  13. package/dist/openapi/models/AuthErrorResponse.d.ts +9 -6
  14. package/dist/openapi/models/AuthErrorResponse.js +2 -2
  15. package/dist/openapi/models/AuthErrorType.d.ts +2 -2
  16. package/dist/openapi/models/AuthErrorType.js +2 -2
  17. package/dist/openapi/models/AvailabilityValue.d.ts +2 -2
  18. package/dist/openapi/models/AvailabilityValue.js +2 -2
  19. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +2 -2
  20. package/dist/openapi/models/BalanceExhaustedResponse.js +2 -2
  21. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +2 -2
  22. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +2 -2
  23. package/dist/openapi/models/CallbackEventType.d.ts +2 -2
  24. package/dist/openapi/models/CallbackEventType.js +2 -2
  25. package/dist/openapi/models/ConnectionSource.d.ts +2 -2
  26. package/dist/openapi/models/ConnectionSource.js +2 -2
  27. package/dist/openapi/models/ContactRequest.d.ts +2 -2
  28. package/dist/openapi/models/ContactRequest.js +2 -2
  29. package/dist/openapi/models/ContactSubject.d.ts +2 -2
  30. package/dist/openapi/models/ContactSubject.js +2 -2
  31. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +2 -2
  32. package/dist/openapi/models/ContactValidationErrorResponse.js +2 -2
  33. package/dist/openapi/models/CreateExternalImport403Response.d.ts +2 -2
  34. package/dist/openapi/models/CreateExternalImport403Response.js +2 -2
  35. package/dist/openapi/models/CreateExternalImport422Response.d.ts +2 -2
  36. package/dist/openapi/models/CreateExternalImport422Response.js +2 -2
  37. package/dist/openapi/models/CreateWorkflow422Response.d.ts +2 -2
  38. package/dist/openapi/models/CreateWorkflow422Response.js +2 -2
  39. package/dist/openapi/models/CreditTransaction.d.ts +2 -2
  40. package/dist/openapi/models/CreditTransaction.js +2 -2
  41. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +2 -2
  42. package/dist/openapi/models/CreditTransactionSourceBucket.js +2 -2
  43. package/dist/openapi/models/CreditsBalanceResponse.d.ts +2 -2
  44. package/dist/openapi/models/CreditsBalanceResponse.js +2 -2
  45. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +2 -2
  46. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +2 -2
  47. package/dist/openapi/models/CreditsUsageResponse.d.ts +2 -2
  48. package/dist/openapi/models/CreditsUsageResponse.js +2 -2
  49. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +2 -2
  50. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +2 -2
  51. package/dist/openapi/models/Delivery.d.ts +16 -3
  52. package/dist/openapi/models/Delivery.js +2 -2
  53. package/dist/openapi/models/DeliveryOutputRef.d.ts +2 -2
  54. package/dist/openapi/models/DeliveryOutputRef.js +2 -2
  55. package/dist/openapi/models/DeliveryPlan.d.ts +2 -2
  56. package/dist/openapi/models/DeliveryPlan.js +2 -2
  57. package/dist/openapi/models/DeliveryPlanOutput.d.ts +2 -2
  58. package/dist/openapi/models/DeliveryPlanOutput.js +2 -2
  59. package/dist/openapi/models/DeliveryPlanReason.d.ts +2 -2
  60. package/dist/openapi/models/DeliveryPlanReason.js +2 -2
  61. package/dist/openapi/models/DeliverySelection.d.ts +2 -2
  62. package/dist/openapi/models/DeliverySelection.js +2 -2
  63. package/dist/openapi/models/EndpointProjection.d.ts +2 -2
  64. package/dist/openapi/models/EndpointProjection.js +2 -2
  65. package/dist/openapi/models/ErrorEnvelope.d.ts +9 -6
  66. package/dist/openapi/models/ErrorEnvelope.js +2 -2
  67. package/dist/openapi/models/EstimateQuality.d.ts +2 -2
  68. package/dist/openapi/models/EstimateQuality.js +2 -2
  69. package/dist/openapi/models/EstimateRange.d.ts +2 -2
  70. package/dist/openapi/models/EstimateRange.js +2 -2
  71. package/dist/openapi/models/ExternalDestination.d.ts +2 -2
  72. package/dist/openapi/models/ExternalDestination.js +2 -2
  73. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +2 -2
  74. package/dist/openapi/models/ExternalImportCreatedResponse.js +2 -2
  75. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +2 -2
  76. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +2 -2
  77. package/dist/openapi/models/ExternalImportRequest.d.ts +2 -2
  78. package/dist/openapi/models/ExternalImportRequest.js +2 -2
  79. package/dist/openapi/models/ExternalImportToken.d.ts +2 -2
  80. package/dist/openapi/models/ExternalImportToken.js +2 -2
  81. package/dist/openapi/models/ExternalSource.d.ts +2 -2
  82. package/dist/openapi/models/ExternalSource.js +2 -2
  83. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +9 -6
  84. package/dist/openapi/models/FeatureNotAvailableResponse.js +2 -2
  85. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +9 -6
  86. package/dist/openapi/models/FeatureTierRestrictedResponse.js +2 -2
  87. package/dist/openapi/models/FeatureViolation.d.ts +2 -2
  88. package/dist/openapi/models/FeatureViolation.js +2 -2
  89. package/dist/openapi/models/JobDefinition.d.ts +2 -2
  90. package/dist/openapi/models/JobDefinition.js +2 -2
  91. package/dist/openapi/models/JobDownload.d.ts +2 -2
  92. package/dist/openapi/models/JobDownload.js +2 -2
  93. package/dist/openapi/models/JobInputV2.d.ts +2 -2
  94. package/dist/openapi/models/JobInputV2.js +2 -2
  95. package/dist/openapi/models/JobOutputSource.d.ts +2 -2
  96. package/dist/openapi/models/JobOutputSource.js +2 -2
  97. package/dist/openapi/models/JobResponse.d.ts +2 -2
  98. package/dist/openapi/models/JobResponse.js +2 -2
  99. package/dist/openapi/models/JobStatus.d.ts +2 -2
  100. package/dist/openapi/models/JobStatus.js +2 -2
  101. package/dist/openapi/models/JobType.d.ts +2 -2
  102. package/dist/openapi/models/JobType.js +2 -2
  103. package/dist/openapi/models/LivenessResponse.d.ts +2 -2
  104. package/dist/openapi/models/LivenessResponse.js +2 -2
  105. package/dist/openapi/models/LoginUser200Response.d.ts +2 -2
  106. package/dist/openapi/models/LoginUser200Response.js +2 -2
  107. package/dist/openapi/models/LoginUser200ResponseData.d.ts +2 -2
  108. package/dist/openapi/models/LoginUser200ResponseData.js +2 -2
  109. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +2 -2
  110. package/dist/openapi/models/LoginUser200ResponseDataUser.js +2 -2
  111. package/dist/openapi/models/LoginUserRequest.d.ts +2 -2
  112. package/dist/openapi/models/LoginUserRequest.js +2 -2
  113. package/dist/openapi/models/LogoutUser200Response.d.ts +2 -2
  114. package/dist/openapi/models/LogoutUser200Response.js +2 -2
  115. package/dist/openapi/models/MetadataResponse.d.ts +2 -2
  116. package/dist/openapi/models/MetadataResponse.js +2 -2
  117. package/dist/openapi/models/MetadataResponseDimensions.d.ts +2 -2
  118. package/dist/openapi/models/MetadataResponseDimensions.js +2 -2
  119. package/dist/openapi/models/MetadataResponseExif.d.ts +2 -2
  120. package/dist/openapi/models/MetadataResponseExif.js +2 -2
  121. package/dist/openapi/models/MetadataResponseExifGps.d.ts +2 -2
  122. package/dist/openapi/models/MetadataResponseExifGps.js +2 -2
  123. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +2 -2
  124. package/dist/openapi/models/MetadataSuccessEnvelope.js +2 -2
  125. package/dist/openapi/models/MimeGroupSchema.d.ts +2 -2
  126. package/dist/openapi/models/MimeGroupSchema.js +2 -2
  127. package/dist/openapi/models/MultipartCompleteRequest.d.ts +2 -2
  128. package/dist/openapi/models/MultipartCompleteRequest.js +2 -2
  129. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +2 -2
  130. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +2 -2
  131. package/dist/openapi/models/MultipartCompleteResponse.d.ts +2 -2
  132. package/dist/openapi/models/MultipartCompleteResponse.js +2 -2
  133. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +2 -2
  134. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +2 -2
  135. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +2 -2
  136. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +2 -2
  137. package/dist/openapi/models/MultipartInitiateResponse.d.ts +2 -2
  138. package/dist/openapi/models/MultipartInitiateResponse.js +2 -2
  139. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +2 -2
  140. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +2 -2
  141. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +2 -2
  142. package/dist/openapi/models/MultipartKeepaliveResponse.js +2 -2
  143. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +2 -2
  144. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +2 -2
  145. package/dist/openapi/models/MultipartPartListing.d.ts +2 -2
  146. package/dist/openapi/models/MultipartPartListing.js +2 -2
  147. package/dist/openapi/models/MultipartPresignRequest.d.ts +2 -2
  148. package/dist/openapi/models/MultipartPresignRequest.js +2 -2
  149. package/dist/openapi/models/MultipartPresignResponse.d.ts +2 -2
  150. package/dist/openapi/models/MultipartPresignResponse.js +2 -2
  151. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +2 -2
  152. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +2 -2
  153. package/dist/openapi/models/MultipartStatusResponse.d.ts +2 -2
  154. package/dist/openapi/models/MultipartStatusResponse.js +2 -2
  155. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +2 -2
  156. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +2 -2
  157. package/dist/openapi/models/OperationDefinition.d.ts +2 -2
  158. package/dist/openapi/models/OperationDefinition.js +2 -2
  159. package/dist/openapi/models/OperationDownload.d.ts +2 -2
  160. package/dist/openapi/models/OperationDownload.js +2 -2
  161. package/dist/openapi/models/OperationInputModel.d.ts +2 -2
  162. package/dist/openapi/models/OperationInputModel.js +2 -2
  163. package/dist/openapi/models/OperationResponse.d.ts +2 -2
  164. package/dist/openapi/models/OperationResponse.js +2 -2
  165. package/dist/openapi/models/OperationResult.d.ts +2 -2
  166. package/dist/openapi/models/OperationResult.js +2 -2
  167. package/dist/openapi/models/OperationResultMetrics.d.ts +21 -2
  168. package/dist/openapi/models/OperationResultMetrics.js +7 -2
  169. package/dist/openapi/models/OperationSchemaDefinition.d.ts +2 -2
  170. package/dist/openapi/models/OperationSchemaDefinition.js +2 -2
  171. package/dist/openapi/models/OperationStatus.d.ts +2 -2
  172. package/dist/openapi/models/OperationStatus.js +2 -2
  173. package/dist/openapi/models/OperationType.d.ts +2 -2
  174. package/dist/openapi/models/OperationType.js +2 -2
  175. package/dist/openapi/models/OperationsSchemaResponse.d.ts +2 -2
  176. package/dist/openapi/models/OperationsSchemaResponse.js +2 -2
  177. package/dist/openapi/models/OptionSchema.d.ts +22 -2
  178. package/dist/openapi/models/OptionSchema.js +4 -2
  179. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +2 -2
  180. package/dist/openapi/models/PerRoleCardinalityEntry.js +2 -2
  181. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +2 -2
  182. package/dist/openapi/models/PerValueAvailabilityEntry.js +2 -2
  183. package/dist/openapi/models/PresignedUrlPart.d.ts +2 -2
  184. package/dist/openapi/models/PresignedUrlPart.js +2 -2
  185. package/dist/openapi/models/ProbePendingResponse.d.ts +9 -6
  186. package/dist/openapi/models/ProbePendingResponse.js +2 -2
  187. package/dist/openapi/models/ProcessingClass.d.ts +2 -2
  188. package/dist/openapi/models/ProcessingClass.js +2 -2
  189. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +2 -2
  190. package/dist/openapi/models/ProcessingClassBandViolation.js +2 -2
  191. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +9 -6
  192. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +2 -2
  193. package/dist/openapi/models/ProcessingClassHint.d.ts +2 -2
  194. package/dist/openapi/models/ProcessingClassHint.js +2 -2
  195. package/dist/openapi/models/ProcessingClassReason.d.ts +2 -2
  196. package/dist/openapi/models/ProcessingClassReason.js +2 -2
  197. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +2 -2
  198. package/dist/openapi/models/ProcessingClassRejectReason.js +2 -2
  199. package/dist/openapi/models/ProcessingPlan.d.ts +2 -2
  200. package/dist/openapi/models/ProcessingPlan.js +2 -2
  201. package/dist/openapi/models/ProcessingPlanJob.d.ts +2 -2
  202. package/dist/openapi/models/ProcessingPlanJob.js +2 -2
  203. package/dist/openapi/models/ReEncodeDecision.d.ts +38 -0
  204. package/dist/openapi/models/ReEncodeDecision.js +56 -0
  205. package/dist/openapi/models/ReadinessResponse.d.ts +2 -2
  206. package/dist/openapi/models/ReadinessResponse.js +2 -2
  207. package/dist/openapi/models/ResponseEnvelope.d.ts +2 -2
  208. package/dist/openapi/models/ResponseEnvelope.js +2 -2
  209. package/dist/openapi/models/RetryResponse.d.ts +2 -2
  210. package/dist/openapi/models/RetryResponse.js +2 -2
  211. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +2 -2
  212. package/dist/openapi/models/RetrySuccessEnvelope.js +2 -2
  213. package/dist/openapi/models/SseCompletionBase.d.ts +2 -2
  214. package/dist/openapi/models/SseCompletionBase.js +2 -2
  215. package/dist/openapi/models/SseEventType.d.ts +2 -2
  216. package/dist/openapi/models/SseEventType.js +2 -2
  217. package/dist/openapi/models/SseJobCompletedData.d.ts +2 -2
  218. package/dist/openapi/models/SseJobCompletedData.js +2 -2
  219. package/dist/openapi/models/SseJobFailedData.d.ts +2 -2
  220. package/dist/openapi/models/SseJobFailedData.js +2 -2
  221. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +2 -2
  222. package/dist/openapi/models/SseMultiOutputCompletion.js +2 -2
  223. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +2 -2
  224. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +2 -2
  225. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +2 -2
  226. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +2 -2
  227. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +2 -2
  228. package/dist/openapi/models/SseMultiOutputResultEntry.js +2 -2
  229. package/dist/openapi/models/SseOperationCompletedData.d.ts +2 -2
  230. package/dist/openapi/models/SseOperationCompletedData.js +2 -2
  231. package/dist/openapi/models/SseOperationCompletionResult.d.ts +2 -2
  232. package/dist/openapi/models/SseOperationCompletionResult.js +2 -2
  233. package/dist/openapi/models/SseOperationFailedData.d.ts +2 -2
  234. package/dist/openapi/models/SseOperationFailedData.js +2 -2
  235. package/dist/openapi/models/SseOperationProgressData.d.ts +2 -2
  236. package/dist/openapi/models/SseOperationProgressData.js +2 -2
  237. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +2 -2
  238. package/dist/openapi/models/SseSingleOutputCompletion.js +2 -2
  239. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +2 -2
  240. package/dist/openapi/models/SseWorkflowTerminalData.js +2 -2
  241. package/dist/openapi/models/TierRestrictionKind.d.ts +2 -2
  242. package/dist/openapi/models/TierRestrictionKind.js +2 -2
  243. package/dist/openapi/models/TierRestrictionResponse.d.ts +9 -6
  244. package/dist/openapi/models/TierRestrictionResponse.js +2 -2
  245. package/dist/openapi/models/UploadConstraintsApplied.d.ts +2 -2
  246. package/dist/openapi/models/UploadConstraintsApplied.js +2 -2
  247. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +9 -6
  248. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +2 -2
  249. package/dist/openapi/models/UploadFile403Response.d.ts +2 -2
  250. package/dist/openapi/models/UploadFile403Response.js +2 -2
  251. package/dist/openapi/models/UploadFile422Response.d.ts +2 -2
  252. package/dist/openapi/models/UploadFile422Response.js +2 -2
  253. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +16 -5
  254. package/dist/openapi/models/UploadProbeMediaMetadata.js +2 -2
  255. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +2 -2
  256. package/dist/openapi/models/UploadProbeProcessingClass.js +2 -2
  257. package/dist/openapi/models/UploadProbeResponse.d.ts +2 -2
  258. package/dist/openapi/models/UploadProbeResponse.js +2 -2
  259. package/dist/openapi/models/UploadProbeStatus.d.ts +2 -2
  260. package/dist/openapi/models/UploadProbeStatus.js +2 -2
  261. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +2 -2
  262. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +2 -2
  263. package/dist/openapi/models/UploadResponse.d.ts +2 -2
  264. package/dist/openapi/models/UploadResponse.js +2 -2
  265. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +9 -6
  266. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +2 -2
  267. package/dist/openapi/models/UploadSource.d.ts +2 -2
  268. package/dist/openapi/models/UploadSource.js +2 -2
  269. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +2 -2
  270. package/dist/openapi/models/UploadSuccessEnvelope.js +2 -2
  271. package/dist/openapi/models/UploadThresholds.d.ts +2 -2
  272. package/dist/openapi/models/UploadThresholds.js +2 -2
  273. package/dist/openapi/models/UserTier.d.ts +2 -2
  274. package/dist/openapi/models/UserTier.js +2 -2
  275. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +6 -3
  276. package/dist/openapi/models/ValidationErrorEnvelope.js +2 -2
  277. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +2 -2
  278. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +2 -2
  279. package/dist/openapi/models/WarningType.d.ts +2 -2
  280. package/dist/openapi/models/WarningType.js +2 -2
  281. package/dist/openapi/models/WebhookOperationContext.d.ts +2 -2
  282. package/dist/openapi/models/WebhookOperationContext.js +2 -2
  283. package/dist/openapi/models/WebhookPayload.d.ts +2 -2
  284. package/dist/openapi/models/WebhookPayload.js +2 -2
  285. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +2 -2
  286. package/dist/openapi/models/WorkflowCancelBillingEffect.js +2 -2
  287. package/dist/openapi/models/WorkflowCancelResponse.d.ts +2 -2
  288. package/dist/openapi/models/WorkflowCancelResponse.js +2 -2
  289. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +2 -2
  290. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +2 -2
  291. package/dist/openapi/models/WorkflowCreateRequest.d.ts +2 -2
  292. package/dist/openapi/models/WorkflowCreateRequest.js +2 -2
  293. package/dist/openapi/models/WorkflowCreateResponse.d.ts +2 -2
  294. package/dist/openapi/models/WorkflowCreateResponse.js +2 -2
  295. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +2 -2
  296. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +2 -2
  297. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +2 -2
  298. package/dist/openapi/models/WorkflowDownloadResponse.js +2 -2
  299. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +2 -2
  300. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +2 -2
  301. package/dist/openapi/models/WorkflowEdge.d.ts +2 -2
  302. package/dist/openapi/models/WorkflowEdge.js +2 -2
  303. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +9 -6
  304. package/dist/openapi/models/WorkflowExpiredResponse.js +2 -2
  305. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +2 -2
  306. package/dist/openapi/models/WorkflowPauseRequiredAction.js +2 -2
  307. package/dist/openapi/models/WorkflowPausedDetail.d.ts +2 -2
  308. package/dist/openapi/models/WorkflowPausedDetail.js +2 -2
  309. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +2 -2
  310. package/dist/openapi/models/WorkflowPausedDetailLinks.js +2 -2
  311. package/dist/openapi/models/WorkflowProcessing.d.ts +2 -2
  312. package/dist/openapi/models/WorkflowProcessing.js +2 -2
  313. package/dist/openapi/models/WorkflowResumeResponse.d.ts +2 -2
  314. package/dist/openapi/models/WorkflowResumeResponse.js +2 -2
  315. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +2 -2
  316. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +2 -2
  317. package/dist/openapi/models/WorkflowSource.d.ts +2 -2
  318. package/dist/openapi/models/WorkflowSource.js +2 -2
  319. package/dist/openapi/models/WorkflowStatus.d.ts +2 -2
  320. package/dist/openapi/models/WorkflowStatus.js +2 -2
  321. package/dist/openapi/models/WorkflowStatusResponse.d.ts +2 -2
  322. package/dist/openapi/models/WorkflowStatusResponse.js +2 -2
  323. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +2 -2
  324. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +2 -2
  325. package/dist/openapi/models/WorkflowWarning.d.ts +2 -2
  326. package/dist/openapi/models/WorkflowWarning.js +2 -2
  327. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +2 -2
  328. package/dist/openapi/models/WorkflowWarningSeverity.js +2 -2
  329. package/dist/openapi/models/index.d.ts +1 -0
  330. package/dist/openapi/models/index.js +1 -0
  331. package/dist/openapi/runtime.d.ts +2 -2
  332. package/dist/openapi/runtime.js +2 -2
  333. package/openapi/api.yaml +161 -30
  334. package/operations/schemas/merge.yaml +14 -10
  335. package/package.json +1 -1
@@ -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. - **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. - **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). - **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/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.
4
4
  *
5
- * The version of the OpenAPI document: 2.17.0
5
+ * The version of the OpenAPI document: 2.21.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. - **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. - **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). - **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/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.
6
6
  *
7
- * The version of the OpenAPI document: 2.17.0
7
+ * The version of the OpenAPI document: 2.21.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. - **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. - **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). - **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/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.
4
4
  *
5
- * The version of the OpenAPI document: 2.17.0
5
+ * The version of the OpenAPI document: 2.21.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. - **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. - **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). - **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/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.
6
6
  *
7
- * The version of the OpenAPI document: 2.17.0
7
+ * The version of the OpenAPI document: 2.21.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -95,6 +95,7 @@ export * from './ProcessingClassReason.js';
95
95
  export * from './ProcessingClassRejectReason.js';
96
96
  export * from './ProcessingPlan.js';
97
97
  export * from './ProcessingPlanJob.js';
98
+ export * from './ReEncodeDecision.js';
98
99
  export * from './ReadinessResponse.js';
99
100
  export * from './ResponseEnvelope.js';
100
101
  export * from './RetryResponse.js';
@@ -97,6 +97,7 @@ export * from './ProcessingClassReason.js';
97
97
  export * from './ProcessingClassRejectReason.js';
98
98
  export * from './ProcessingPlan.js';
99
99
  export * from './ProcessingPlanJob.js';
100
+ export * from './ReEncodeDecision.js';
100
101
  export * from './ReadinessResponse.js';
101
102
  export * from './ResponseEnvelope.js';
102
103
  export * from './RetryResponse.js';
@@ -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. - **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. - **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). - **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/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.
4
4
  *
5
- * The version of the OpenAPI document: 2.17.0
5
+ * The version of the OpenAPI document: 2.21.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. - **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. - **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). - **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/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.
6
6
  *
7
- * The version of the OpenAPI document: 2.17.0
7
+ * The version of the OpenAPI document: 2.21.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
package/openapi/api.yaml CHANGED
@@ -42,13 +42,27 @@ info:
42
42
  `message_key`. Machine-readable fields (`error`, enum values, status
43
43
  codes) stay canonical English.
44
44
 
45
+ - **Currently committed locales:** `en-GB` only (per ticket
46
+ [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier
47
+ shape (`Accept-Language` + `Content-Language` + `Vary` headers +
48
+ `locale` envelope field + `message_key` + `message_params`) is
49
+ stable and exercised; the **catalog** of translated `message`
50
+ strings is en-GB-only at runtime today. Additional locales (e.g.
51
+ `pt-PT`) will be advertised by name when their catalogs ship —
52
+ the request/response carrier shape does NOT change when a new
53
+ locale lands. Treat unrequested locales as "machine-code +
54
+ `message_key` path is committed; localised `message` prose is
55
+ not" until this prose enumerates them by name.
45
56
  - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value
46
57
  negotiation supported). The server selects the best-match locale
47
- from its supported list; falls back to `en-GB` when no match.
58
+ from its supported list; falls back to `en-GB` when no match
59
+ which, until additional catalogs land, is every non-`en-GB`
60
+ `Accept-Language`.
48
61
  - **Response:** `Content-Language: <locale>` echo on every localised
49
62
  response; `Vary: Accept-Language` on every response (CDN/cache
50
63
  correctness — different `Accept-Language` requests produce
51
- different responses).
64
+ different responses). `Vary` is emitted unconditionally so the
65
+ header contract does not flip when a second locale ships.
52
66
  - **Fallback locale:** `en-GB` (also the canonical locale for
53
67
  `message_key` translations and English `message` prose).
54
68
  - **SDK guidance:** switch on `error` (machine code) for typed
@@ -75,7 +89,7 @@ info:
75
89
  of truth instead of hardcoding magic numbers. A runtime
76
90
  `GET /api/uploads/limits` endpoint for dynamic discovery
77
91
  (per-tier / per-environment overrides) is a deferred follow-up.
78
- version: 2.17.0
92
+ version: 2.21.0
79
93
  contact:
80
94
  name: API Support
81
95
 
@@ -2185,7 +2199,7 @@ paths:
2185
2199
  still fresh. Strong-ETag comparison.
2186
2200
  schema:
2187
2201
  type: string
2188
- example: '"v2-pro-47"'
2202
+ example: '"v2-pro-49"'
2189
2203
  - name: If-Modified-Since
2190
2204
  in: header
2191
2205
  required: false
@@ -2218,7 +2232,7 @@ paths:
2218
2232
  Strong entity tag. Clients send `If-None-Match: <etag>`
2219
2233
  on subsequent requests to revalidate; the server returns
2220
2234
  `304 Not Modified` when the response is still fresh.
2221
- example: '"v2-pro-47"'
2235
+ example: '"v2-pro-49"'
2222
2236
  Last-Modified:
2223
2237
  schema:
2224
2238
  type: string
@@ -2236,7 +2250,7 @@ paths:
2236
2250
  summary: Full schema (truncated for brevity)
2237
2251
  value:
2238
2252
  schema_version: "2.0.0"
2239
- capabilities_version: 47
2253
+ capabilities_version: 49
2240
2254
  generated_at: "2026-04-26T09:00:00Z"
2241
2255
  user_tier: "pro"
2242
2256
  operations:
@@ -2299,7 +2313,7 @@ paths:
2299
2313
  ETag:
2300
2314
  schema:
2301
2315
  type: string
2302
- example: '"v2-pro-47"'
2316
+ example: '"v2-pro-49"'
2303
2317
  Last-Modified:
2304
2318
  schema:
2305
2319
  type: string
@@ -3017,7 +3031,10 @@ paths:
3017
3031
  - name: limit
3018
3032
  in: query
3019
3033
  required: false
3020
- description: Page size. Server may reject larger values with 400.
3034
+ description: |
3035
+ Page size. Server may reject invalid `limit` / `offset`
3036
+ with `422 VALIDATION_FAILED` (per project-wide query-param
3037
+ validation convention).
3021
3038
  schema:
3022
3039
  type: integer
3023
3040
  minimum: 1
@@ -3026,7 +3043,9 @@ paths:
3026
3043
  - name: offset
3027
3044
  in: query
3028
3045
  required: false
3029
- description: Page offset (zero-based).
3046
+ description: |
3047
+ Page offset (zero-based). Server may reject invalid
3048
+ `limit` / `offset` with `422 VALIDATION_FAILED`.
3030
3049
  schema:
3031
3050
  type: integer
3032
3051
  minimum: 0
@@ -3149,21 +3168,33 @@ paths:
3149
3168
  total: 47
3150
3169
  limit: 20
3151
3170
  offset: 0
3152
- '400':
3153
- description: Invalid pagination parameters (limit out of range, offset negative).
3171
+ '401':
3172
+ description: Authentication required.
3154
3173
  content:
3155
3174
  application/json:
3156
3175
  schema:
3157
3176
  $ref: '#/components/schemas/ErrorEnvelope'
3158
- example:
3159
- success: false
3160
- error: "limit must be between 1 and 100"
3161
- '401':
3162
- description: Authentication required.
3177
+ '422':
3178
+ description: |
3179
+ Invalid pagination parameters (`limit` out of range,
3180
+ `offset` negative). Per the project-wide query-param
3181
+ validation convention: the API runtime translates parameter
3182
+ constraint violations into `ValidationErrorEnvelope` with
3183
+ `error: "VALIDATION_FAILED"` and structured `details[]`
3184
+ describing each rejected parameter. Replaces the prior
3185
+ `400 ErrorEnvelope` shape — wire change landed via
3186
+ [`gCfdFhdo`](https://trello.com/c/gCfdFhdo) on the API side
3187
+ (contracts caught up via [`d4rJzTcU`](https://trello.com/c/d4rJzTcU)).
3163
3188
  content:
3164
3189
  application/json:
3165
3190
  schema:
3166
- $ref: '#/components/schemas/ErrorEnvelope'
3191
+ $ref: '#/components/schemas/ValidationErrorEnvelope'
3192
+ example:
3193
+ success: false
3194
+ error: "VALIDATION_FAILED"
3195
+ details:
3196
+ - field: "limit"
3197
+ message: "limit must be between 1 and 100"
3167
3198
  '429':
3168
3199
  description: Rate limit exceeded
3169
3200
  content:
@@ -3420,10 +3451,13 @@ components:
3420
3451
  type: string
3421
3452
  description: |
3422
3453
  BCP 47 locale tag echoing the resolved `Content-Language`
3423
- response header value (e.g. `en-GB`, `pt-BR`, `ja-JP`).
3424
- Lets the SDK confirm which locale the server selected
3425
- when the request used q-value negotiation across multiple
3426
- `Accept-Language` values.
3454
+ response header value. Currently always `en-GB` (the only
3455
+ committed locale per `info.description` Localisation block
3456
+ + ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6));
3457
+ additional values will appear here when their catalogs
3458
+ ship. Lets the SDK confirm which locale the server
3459
+ selected when the request used q-value negotiation across
3460
+ multiple `Accept-Language` values.
3427
3461
  example: "en-GB"
3428
3462
  message_params:
3429
3463
  type: object
@@ -3467,7 +3501,10 @@ components:
3467
3501
  (generic option/value validation failure), `REQUIRES_REENCODE`
3468
3502
  (per ticket I16-CONS — `merge.video` with
3469
3503
  `re_encode_mode: never` and incompatible inputs; caller
3470
- resolves by switching to `re_encode_mode: auto` or `always`).
3504
+ resolves by switching to `re_encode_mode: auto` or `always`),
3505
+ `VALIDATION_FAILED` (request/query-param validation failure
3506
+ per the project-wide convention — e.g. `GET /api/v2/credits/usage`
3507
+ invalid `limit`/`offset`).
3471
3508
  SDKs duck-type on this field for typed error-branch helpers.
3472
3509
  message:
3473
3510
  type: string
@@ -3538,6 +3575,26 @@ components:
3538
3575
  `ErrorEnvelope.message_params`. Excludes cost
3539
3576
  numbers.
3540
3577
 
3578
+ ReEncodeDecision:
3579
+ type: string
3580
+ description: |
3581
+ Path chosen for `merge.video` when `re_encode_mode=auto`.
3582
+ Server reports the actual path so callers can see why
3583
+ `auto` took the slow path. Absent for non-`merge.video`
3584
+ operations and for `merge.video` when `re_encode_mode` is
3585
+ `always` or `never` (path was caller-fixed). Per ticket
3586
+ I16-CONS (Trello 7nCZXEru).
3587
+
3588
+ Mirrors the AsyncAPI `ReEncodeDecision` (and
3589
+ `OperationMetrics.re_encode_decision`); exposed on the REST
3590
+ `OperationResult.metrics` per ticket zS4e9CI2 so the SDK
3591
+ customer path carries the same signal as the SSE/message
3592
+ surface. Cross-spec enum parity is verified by
3593
+ `tests/test_asyncapi_named_schemas.py`.
3594
+ enum:
3595
+ - stream_copy
3596
+ - re_encode
3597
+
3541
3598
  # ============================================
3542
3599
  # AVAILABILITY METADATA (decorative)
3543
3600
  # ============================================
@@ -6631,8 +6688,19 @@ components:
6631
6688
  - explicit
6632
6689
  per_value_availability:
6633
6690
  terminal: { availability: stable }
6634
- all_outputs: { availability: beta }
6635
- explicit: { availability: beta }
6691
+ all_outputs: { availability: planned }
6692
+ explicit: { availability: planned }
6693
+ # Availability flipped beta → planned per ticket
6694
+ # [`co0CERtJ`](https://trello.com/c/co0CERtJ) — the API
6695
+ # runtime currently 422s every non-default `selection.type`
6696
+ # with `feature_not_available`, which per the
6697
+ # `info.description` availability taxonomy IS the `planned`
6698
+ # behaviour (`stable`/`beta` MUST NOT 422). When the API
6699
+ # threads the request-level `delivery.selection` shape, this
6700
+ # flips back. Terminal stays `stable` because the runtime
6701
+ # honours it as the implicit default (`DeliveryPlanComputer`
6702
+ # computes terminal selection regardless of whether the
6703
+ # caller supplied a `delivery` block).
6636
6704
  refs:
6637
6705
  type: array
6638
6706
  description: |
@@ -6659,7 +6727,20 @@ components:
6659
6727
  properties:
6660
6728
  mode:
6661
6729
  type: string
6662
- description: Delivery mode.
6730
+ description: |
6731
+ Delivery mode. `individual` is the only committed value
6732
+ today (per ticket [`co0CERtJ`](https://trello.com/c/co0CERtJ)).
6733
+ `bundle` and `both` are `planned`: the API runtime returns
6734
+ `422 feature_not_available` for any non-`individual` value,
6735
+ which per the `info.description` availability taxonomy is
6736
+ the `planned` behaviour (`stable`/`beta` MUST NOT 422).
6737
+
6738
+ For workflows that need a packaged output today, compose
6739
+ a terminal `archive` job whose `sources` are
6740
+ `JobOutputSource` refs to the upstream jobs — `archive` is
6741
+ the canonical output-bundler per ADR-0017. `delivery.mode:
6742
+ bundle` is the deferred post-launch ergonomic sugar that
6743
+ will reuse the same `archive` runtime under the hood.
6663
6744
  enum:
6664
6745
  - individual
6665
6746
  - bundle
@@ -6667,8 +6748,8 @@ components:
6667
6748
  default: individual
6668
6749
  per_value_availability:
6669
6750
  individual: { availability: stable }
6670
- bundle: { availability: stable }
6671
- both: { availability: beta }
6751
+ bundle: { availability: planned }
6752
+ both: { availability: planned }
6672
6753
  bundle_format:
6673
6754
  type: string
6674
6755
  enum:
@@ -6699,6 +6780,11 @@ components:
6699
6780
  description: |
6700
6781
  How to pick outputs. Default `terminal` (leaves only).
6701
6782
  example:
6783
+ # Spec example uses `bundle` to document the deferred (planned)
6784
+ # shape end-to-end — see Delivery.mode per_value_availability
6785
+ # for the runtime state. For workflows that need packaged
6786
+ # output today, compose a terminal `archive` job whose
6787
+ # `sources` are `JobOutputSource` refs (ADR-0017).
6702
6788
  mode: bundle
6703
6789
  bundle_format: zip
6704
6790
  bundle_filename: "compressed-photos"
@@ -7068,12 +7154,22 @@ components:
7068
7154
  description: Container-reported duration (audio + video).
7069
7155
  width:
7070
7156
  type: integer
7157
+ format: int64
7071
7158
  minimum: 1
7072
- description: Pixel width (image + video; best-effort document).
7159
+ description: |
7160
+ Pixel width (image + video; best-effort document). Declared
7161
+ `int64` so Rust SDK generators emit `i64` instead of the
7162
+ default `i32`; `i32` is fine for everything ffmpeg/libcaesium
7163
+ handles today but the format hint keeps the door open for
7164
+ scientific / RAW imagery without future SDK churn (per
7165
+ ticket [`0sTmbUsc`](https://trello.com/c/0sTmbUsc)).
7073
7166
  height:
7074
7167
  type: integer
7168
+ format: int64
7075
7169
  minimum: 1
7076
- description: Pixel height (image + video; best-effort document).
7170
+ description: |
7171
+ Pixel height (image + video; best-effort document). See
7172
+ `width` for the `format: int64` rationale.
7077
7173
  codec:
7078
7174
  type: string
7079
7175
  description: |
@@ -7108,12 +7204,16 @@ components:
7108
7204
  `29.97`, `23.976`).
7109
7205
  bitrate_bps:
7110
7206
  type: integer
7207
+ format: int64
7111
7208
  minimum: 0
7112
7209
  description: |
7113
7210
  Overall stream bitrate, **bits per second**. Units in
7114
7211
  the field name, mirroring `duration_seconds`, so SDKs
7115
7212
  avoid the kbps-vs-bps guessing trap. Container-reported
7116
- for video + audio.
7213
+ for video + audio. Declared `int64` so Rust SDK
7214
+ generators emit `i64` instead of `i32`; `i32` caps at
7215
+ ~2.1 Gbps which is tight for future 4K/8K/RAW workloads
7216
+ (per ticket [`0sTmbUsc`](https://trello.com/c/0sTmbUsc)).
7117
7217
  audio_layout:
7118
7218
  type: string
7119
7219
  description: |
@@ -7574,6 +7674,21 @@ components:
7574
7674
  duration_ms:
7575
7675
  type: integer
7576
7676
  description: Processing time in milliseconds
7677
+ re_encode_decision:
7678
+ # Mirrors AsyncAPI OperationMetrics.re_encode_decision so the
7679
+ # REST result surface (SDK customer path) carries the same
7680
+ # merge.video stream-copy-vs-re-encode signal as the SSE/message
7681
+ # channel. Per ticket zS4e9CI2 (unblocks e2e aDFI1FgT).
7682
+ $ref: '#/components/schemas/ReEncodeDecision'
7683
+ re_encode_reason:
7684
+ type: string
7685
+ description: |
7686
+ Advisory explanation for `re_encode_decision` (e.g.
7687
+ `all_inputs_compatible`, `explicit_always_mode`,
7688
+ `input_codec_mismatch`, `input_framerate_mismatch`).
7689
+ Free-form string — not an enum — so the Lambda can emit
7690
+ human-readable diagnostics that evolve without contract
7691
+ changes. Mirrors `OperationMetrics.re_encode_reason`.
7577
7692
 
7578
7693
  # ============================================
7579
7694
  # WORKFLOW DOWNLOAD SCHEMAS
@@ -8584,6 +8699,22 @@ components:
8584
8699
  by `make check-per-value-availability` (CI guard, ticket
8585
8700
  [I17 `0gwtwCav`](https://trello.com/c/0gwtwCav)). Runtime
8586
8701
  emission lands with I3.
8702
+ per_value_depends_on:
8703
+ type: object
8704
+ description: |
8705
+ Per-enum-value cross-field constraint map, only meaningful
8706
+ when `type: enum`. Keys MUST be a subset of `values[]`;
8707
+ each entry value is a `depends_on`-shaped condition mapping
8708
+ that the named enum value REQUIRES. Distinct from
8709
+ option-level `depends_on` (which gates applicability with
8710
+ silent-ignore semantics); `per_value_depends_on` rejects
8711
+ the request with `invalid_options` when the named value is
8712
+ chosen and the condition is not met. Verified by
8713
+ `make check-per-value-depends-on` (CI guard, ticket
8714
+ [`bsV3FWM5`](https://trello.com/c/bsV3FWM5)). Runtime
8715
+ emission ships verbatim alongside other availability
8716
+ metadata. See `schemas/FORMAT.md` §per_value_depends_on.
8717
+ additionalProperties: true
8587
8718
  min:
8588
8719
  type: number
8589
8720
  description: Minimum value (for integer/float types)
@@ -289,26 +289,30 @@ operation:
289
289
  values: [crf, target_size]
290
290
  default: crf
291
291
  depends_on: { re_encode_mode: [auto, always] }
292
+ per_value_depends_on:
293
+ target_size: { codec: [h264] }
292
294
  description: |
293
295
  CRF (quality-targeted) vs target_size (two-pass to fixed file size).
294
296
  `target_size` is currently `codec=h264` only — libx265 / libvpx-vp9 / libsvtav1 each
295
297
  require a different two-pass invocation and are tracked as separate per-codec
296
- Lambda follow-ups. The contract narrows `target_size_bytes.depends_on` with
297
- `codec: [h264]`, which rejects `encoding_mode=target_size + codec ∈ {h265, vp9, av1}`
298
- as `invalid_options` **when `target_size_bytes` is present in the request**. Fully
299
- gating `encoding_mode=target_size` itself on codec (so that omitting
300
- `target_size_bytes` is also rejected) awaits a `per_value_depends_on` schema
301
- vocab extension (ticket bsV3FWM5); Lambda continues to catch the residual
302
- `target_size + non-h264 + no target_size_bytes` case in the meantime.
298
+ Lambda follow-ups. The `per_value_depends_on` block above gates
299
+ `encoding_mode=target_size` itself on `codec ∈ [h264]`, so a request with
300
+ `encoding_mode=target_size + codec {h265, vp9, av1}` is rejected as
301
+ `invalid_options` regardless of whether `target_size_bytes` is supplied —
302
+ closing the gap left by the previous option-level `depends_on` (which only
303
+ triggered when `target_size_bytes` was present in the payload). Per ticket
304
+ [`bsV3FWM5`](https://trello.com/c/bsV3FWM5).
303
305
 
304
306
  target_size_bytes:
305
307
  type: integer
306
308
  min: 1048576
307
- depends_on: { re_encode_mode: [auto, always], encoding_mode: target_size, codec: [h264] }
309
+ depends_on: { re_encode_mode: [auto, always], encoding_mode: target_size }
308
310
  description: |
309
311
  Two-pass target file size in bytes (minimum 1 MiB). Required when
310
- `encoding_mode=target_size`. h264-only today; see `encoding_mode` description
311
- for per-codec rollout status.
312
+ `encoding_mode=target_size`. h264-only the codec gate now lives on
313
+ `encoding_mode.per_value_depends_on.target_size.codec` (per ticket
314
+ [`bsV3FWM5`](https://trello.com/c/bsV3FWM5)); this option's own
315
+ `depends_on` no longer duplicates it.
312
316
 
313
317
  Practical floor: a ~100 kbps post-AAC video bitrate (i.e. `target_size_bytes`
314
318
  corresponding to less than ~100 kbps of video after subtracting the 160 kbps
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@giveitsmaller/contracts",
3
- "version": "0.7.0",
3
+ "version": "0.8.0",
4
4
  "description": "Generated contract types for GISL (Give It Smaller)",
5
5
  "license": "MIT",
6
6
  "type": "module",