@giveitsmaller/contracts 0.55.0 → 0.57.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 (482) hide show
  1. package/LICENSE +202 -0
  2. package/accepted-options/accepted-options.json +1 -15
  3. package/accepted-options/image-output-routes.json +1 -1
  4. package/availability/availability.json +9 -60
  5. package/code-builder/code-builder-metadata.json +3 -165
  6. package/dist/openapi/models/AccountLimitEntry.d.ts +1 -1
  7. package/dist/openapi/models/AccountLimitEntry.js +1 -1
  8. package/dist/openapi/models/AccountLimits.d.ts +1 -1
  9. package/dist/openapi/models/AccountLimits.js +1 -1
  10. package/dist/openapi/models/AccountLimitsLimits.d.ts +1 -1
  11. package/dist/openapi/models/AccountLimitsLimits.js +1 -1
  12. package/dist/openapi/models/AccountLimitsSuccessEnvelope.d.ts +1 -1
  13. package/dist/openapi/models/AccountLimitsSuccessEnvelope.js +1 -1
  14. package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +1 -1
  15. package/dist/openapi/models/AudioWatermarkDecodeRequest.js +1 -1
  16. package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +1 -1
  17. package/dist/openapi/models/AudioWatermarkDecodeResponse.js +1 -1
  18. package/dist/openapi/models/AuthErrorResponse.d.ts +1 -1
  19. package/dist/openapi/models/AuthErrorResponse.js +1 -1
  20. package/dist/openapi/models/AuthErrorType.d.ts +52 -31
  21. package/dist/openapi/models/AuthErrorType.js +53 -32
  22. package/dist/openapi/models/AuthRejectionEnvelope.d.ts +1 -1
  23. package/dist/openapi/models/AuthRejectionEnvelope.js +1 -1
  24. package/dist/openapi/models/AvailabilityValue.d.ts +1 -1
  25. package/dist/openapi/models/AvailabilityValue.js +1 -1
  26. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +1 -1
  27. package/dist/openapi/models/BalanceExhaustedResponse.js +1 -1
  28. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +1 -1
  29. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +1 -1
  30. package/dist/openapi/models/BillingCheckoutRequest.d.ts +1 -1
  31. package/dist/openapi/models/BillingCheckoutRequest.js +1 -1
  32. package/dist/openapi/models/BillingCheckoutSession.d.ts +1 -1
  33. package/dist/openapi/models/BillingCheckoutSession.js +1 -1
  34. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.d.ts +1 -1
  35. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.js +1 -1
  36. package/dist/openapi/models/CallbackEventType.d.ts +1 -1
  37. package/dist/openapi/models/CallbackEventType.js +1 -1
  38. package/dist/openapi/models/CapabilityCondition.d.ts +1 -1
  39. package/dist/openapi/models/CapabilityCondition.js +1 -1
  40. package/dist/openapi/models/CapabilityConditionOneOf.d.ts +1 -1
  41. package/dist/openapi/models/CapabilityConditionOneOf.js +1 -1
  42. package/dist/openapi/models/CapabilityConditionOneOf1.d.ts +1 -1
  43. package/dist/openapi/models/CapabilityConditionOneOf1.js +1 -1
  44. package/dist/openapi/models/CapabilityConditionOneOf2.d.ts +1 -1
  45. package/dist/openapi/models/CapabilityConditionOneOf2.js +1 -1
  46. package/dist/openapi/models/CapabilityConditionOneOf3.d.ts +1 -1
  47. package/dist/openapi/models/CapabilityConditionOneOf3.js +1 -1
  48. package/dist/openapi/models/CapabilityConditionOneOf4.d.ts +1 -1
  49. package/dist/openapi/models/CapabilityConditionOneOf4.js +1 -1
  50. package/dist/openapi/models/CapabilityConditionOneOf5.d.ts +1 -1
  51. package/dist/openapi/models/CapabilityConditionOneOf5.js +1 -1
  52. package/dist/openapi/models/CapabilityConditionOneOf6.d.ts +1 -1
  53. package/dist/openapi/models/CapabilityConditionOneOf6.js +1 -1
  54. package/dist/openapi/models/CapabilityConstraint.d.ts +1 -1
  55. package/dist/openapi/models/CapabilityConstraint.js +1 -1
  56. package/dist/openapi/models/CapabilityInputSpec.d.ts +1 -1
  57. package/dist/openapi/models/CapabilityInputSpec.js +1 -1
  58. package/dist/openapi/models/CapabilityProduces.d.ts +1 -1
  59. package/dist/openapi/models/CapabilityProduces.js +1 -1
  60. package/dist/openapi/models/CapabilityProducesOneOf.d.ts +1 -1
  61. package/dist/openapi/models/CapabilityProducesOneOf.js +1 -1
  62. package/dist/openapi/models/CapabilityProducesOneOf1.d.ts +1 -1
  63. package/dist/openapi/models/CapabilityProducesOneOf1.js +1 -1
  64. package/dist/openapi/models/CapabilityProducesOneOf2.d.ts +1 -1
  65. package/dist/openapi/models/CapabilityProducesOneOf2.js +1 -1
  66. package/dist/openapi/models/ChangePasswordRequest.d.ts +1 -1
  67. package/dist/openapi/models/ChangePasswordRequest.js +1 -1
  68. package/dist/openapi/models/CodegenSource.d.ts +1 -1
  69. package/dist/openapi/models/CodegenSource.js +1 -1
  70. package/dist/openapi/models/CodegenSourceInput.d.ts +1 -1
  71. package/dist/openapi/models/CodegenSourceInput.js +1 -1
  72. package/dist/openapi/models/CodegenSourceJob.d.ts +1 -1
  73. package/dist/openapi/models/CodegenSourceJob.js +1 -1
  74. package/dist/openapi/models/CodegenSourceJobSource.d.ts +1 -1
  75. package/dist/openapi/models/CodegenSourceJobSource.js +1 -1
  76. package/dist/openapi/models/CodegenSourceOperation.d.ts +1 -1
  77. package/dist/openapi/models/CodegenSourceOperation.js +1 -1
  78. package/dist/openapi/models/CodegenUploadPlaceholder.d.ts +1 -1
  79. package/dist/openapi/models/CodegenUploadPlaceholder.js +1 -1
  80. package/dist/openapi/models/CompositionPlan.d.ts +1 -1
  81. package/dist/openapi/models/CompositionPlan.js +1 -1
  82. package/dist/openapi/models/CompositionPlanJob.d.ts +1 -1
  83. package/dist/openapi/models/CompositionPlanJob.js +1 -1
  84. package/dist/openapi/models/CompositionPlanOperation.d.ts +1 -1
  85. package/dist/openapi/models/CompositionPlanOperation.js +1 -1
  86. package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +1 -1
  87. package/dist/openapi/models/ConfirmEmailChange200Response.js +1 -1
  88. package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +1 -1
  89. package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +1 -1
  90. package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +1 -1
  91. package/dist/openapi/models/ConfirmEmailChangeRequest.js +1 -1
  92. package/dist/openapi/models/ConnectionSource.d.ts +1 -1
  93. package/dist/openapi/models/ConnectionSource.js +1 -1
  94. package/dist/openapi/models/ContactRequest.d.ts +1 -1
  95. package/dist/openapi/models/ContactRequest.js +1 -1
  96. package/dist/openapi/models/ContactSubject.d.ts +1 -1
  97. package/dist/openapi/models/ContactSubject.js +1 -1
  98. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +1 -1
  99. package/dist/openapi/models/ContactValidationErrorResponse.js +1 -1
  100. package/dist/openapi/models/CreateApiKey201Response.d.ts +1 -1
  101. package/dist/openapi/models/CreateApiKey201Response.js +1 -1
  102. package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +1 -1
  103. package/dist/openapi/models/CreateApiKey201ResponseData.js +1 -1
  104. package/dist/openapi/models/CreateApiKeyRequest.d.ts +1 -1
  105. package/dist/openapi/models/CreateApiKeyRequest.js +1 -1
  106. package/dist/openapi/models/CreateBillingCheckoutSession422Response.d.ts +1 -1
  107. package/dist/openapi/models/CreateBillingCheckoutSession422Response.js +1 -1
  108. package/dist/openapi/models/CreateExternalImport403Response.d.ts +1 -1
  109. package/dist/openapi/models/CreateExternalImport403Response.js +1 -1
  110. package/dist/openapi/models/CreateExternalImport422Response.d.ts +1 -1
  111. package/dist/openapi/models/CreateExternalImport422Response.js +1 -1
  112. package/dist/openapi/models/CreateWorkflow401Response.d.ts +160 -0
  113. package/dist/openapi/models/CreateWorkflow401Response.js +73 -0
  114. package/dist/openapi/models/CreateWorkflow422Response.d.ts +1 -1
  115. package/dist/openapi/models/CreateWorkflow422Response.js +1 -1
  116. package/dist/openapi/models/CreditTransaction.d.ts +1 -1
  117. package/dist/openapi/models/CreditTransaction.js +1 -1
  118. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +1 -1
  119. package/dist/openapi/models/CreditTransactionSourceBucket.js +1 -1
  120. package/dist/openapi/models/CreditsBalanceResponse.d.ts +1 -1
  121. package/dist/openapi/models/CreditsBalanceResponse.js +1 -1
  122. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +1 -1
  123. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +1 -1
  124. package/dist/openapi/models/CreditsUsageResponse.d.ts +1 -1
  125. package/dist/openapi/models/CreditsUsageResponse.js +1 -1
  126. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +1 -1
  127. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +1 -1
  128. package/dist/openapi/models/Delivery.d.ts +1 -1
  129. package/dist/openapi/models/Delivery.js +1 -1
  130. package/dist/openapi/models/DeliveryOutputRef.d.ts +1 -1
  131. package/dist/openapi/models/DeliveryOutputRef.js +1 -1
  132. package/dist/openapi/models/DeliveryPlan.d.ts +1 -1
  133. package/dist/openapi/models/DeliveryPlan.js +1 -1
  134. package/dist/openapi/models/DeliveryPlanOutput.d.ts +1 -1
  135. package/dist/openapi/models/DeliveryPlanOutput.js +1 -1
  136. package/dist/openapi/models/DeliveryPlanReason.d.ts +1 -1
  137. package/dist/openapi/models/DeliveryPlanReason.js +1 -1
  138. package/dist/openapi/models/DeliverySelection.d.ts +1 -1
  139. package/dist/openapi/models/DeliverySelection.js +1 -1
  140. package/dist/openapi/models/DownloadBundle.d.ts +1 -1
  141. package/dist/openapi/models/DownloadBundle.js +1 -1
  142. package/dist/openapi/models/EmailNotify.d.ts +73 -0
  143. package/dist/openapi/models/EmailNotify.js +46 -0
  144. package/dist/openapi/models/EmptySuccessEnvelope.d.ts +1 -1
  145. package/dist/openapi/models/EmptySuccessEnvelope.js +1 -1
  146. package/dist/openapi/models/EndpointProjection.d.ts +1 -1
  147. package/dist/openapi/models/EndpointProjection.js +1 -1
  148. package/dist/openapi/models/ErrorEnvelope.d.ts +1 -1
  149. package/dist/openapi/models/ErrorEnvelope.js +1 -1
  150. package/dist/openapi/models/EstimateQuality.d.ts +1 -1
  151. package/dist/openapi/models/EstimateQuality.js +1 -1
  152. package/dist/openapi/models/EstimateRange.d.ts +1 -1
  153. package/dist/openapi/models/EstimateRange.js +1 -1
  154. package/dist/openapi/models/ExternalDestination.d.ts +1 -1
  155. package/dist/openapi/models/ExternalDestination.js +1 -1
  156. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +1 -1
  157. package/dist/openapi/models/ExternalImportCreatedResponse.js +1 -1
  158. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +1 -1
  159. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +1 -1
  160. package/dist/openapi/models/ExternalImportRequest.d.ts +1 -1
  161. package/dist/openapi/models/ExternalImportRequest.js +1 -1
  162. package/dist/openapi/models/ExternalImportToken.d.ts +1 -1
  163. package/dist/openapi/models/ExternalImportToken.js +1 -1
  164. package/dist/openapi/models/ExternalSource.d.ts +1 -1
  165. package/dist/openapi/models/ExternalSource.js +1 -1
  166. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +1 -1
  167. package/dist/openapi/models/FeatureNotAvailableResponse.js +1 -1
  168. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +1 -1
  169. package/dist/openapi/models/FeatureTierRestrictedResponse.js +1 -1
  170. package/dist/openapi/models/FeatureViolation.d.ts +1 -1
  171. package/dist/openapi/models/FeatureViolation.js +1 -1
  172. package/dist/openapi/models/ImageEncodeCapabilities.d.ts +1 -1
  173. package/dist/openapi/models/ImageEncodeCapabilities.js +1 -1
  174. package/dist/openapi/models/JobDefinition.d.ts +1 -1
  175. package/dist/openapi/models/JobDefinition.js +1 -1
  176. package/dist/openapi/models/JobDownload.d.ts +1 -1
  177. package/dist/openapi/models/JobDownload.js +1 -1
  178. package/dist/openapi/models/JobInputV2.d.ts +1 -1
  179. package/dist/openapi/models/JobInputV2.js +1 -1
  180. package/dist/openapi/models/JobMediaClass.d.ts +1 -1
  181. package/dist/openapi/models/JobMediaClass.js +1 -1
  182. package/dist/openapi/models/JobOutputSource.d.ts +1 -1
  183. package/dist/openapi/models/JobOutputSource.js +1 -1
  184. package/dist/openapi/models/JobResponse.d.ts +1 -1
  185. package/dist/openapi/models/JobResponse.js +1 -1
  186. package/dist/openapi/models/JobStatus.d.ts +1 -1
  187. package/dist/openapi/models/JobStatus.js +1 -1
  188. package/dist/openapi/models/JobType.d.ts +1 -1
  189. package/dist/openapi/models/JobType.js +1 -1
  190. package/dist/openapi/models/LivenessResponse.d.ts +1 -1
  191. package/dist/openapi/models/LivenessResponse.js +1 -1
  192. package/dist/openapi/models/LoginUser200Response.d.ts +1 -1
  193. package/dist/openapi/models/LoginUser200Response.js +1 -1
  194. package/dist/openapi/models/LoginUser200ResponseData.d.ts +1 -1
  195. package/dist/openapi/models/LoginUser200ResponseData.js +1 -1
  196. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +1 -1
  197. package/dist/openapi/models/LoginUser200ResponseDataUser.js +1 -1
  198. package/dist/openapi/models/LoginUser401Response.d.ts +158 -0
  199. package/dist/openapi/models/LoginUser401Response.js +71 -0
  200. package/dist/openapi/models/LoginUserRequest.d.ts +1 -1
  201. package/dist/openapi/models/LoginUserRequest.js +1 -1
  202. package/dist/openapi/models/LongFormConcurrencyLimitResponse.d.ts +1 -1
  203. package/dist/openapi/models/LongFormConcurrencyLimitResponse.js +1 -1
  204. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.d.ts +1 -1
  205. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.js +1 -1
  206. package/dist/openapi/models/MetadataResponse.d.ts +1 -1
  207. package/dist/openapi/models/MetadataResponse.js +1 -1
  208. package/dist/openapi/models/MetadataResponseDimensions.d.ts +1 -1
  209. package/dist/openapi/models/MetadataResponseDimensions.js +1 -1
  210. package/dist/openapi/models/MetadataResponseExif.d.ts +1 -1
  211. package/dist/openapi/models/MetadataResponseExif.js +1 -1
  212. package/dist/openapi/models/MetadataResponseExifGps.d.ts +1 -1
  213. package/dist/openapi/models/MetadataResponseExifGps.js +1 -1
  214. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +1 -1
  215. package/dist/openapi/models/MetadataSuccessEnvelope.js +1 -1
  216. package/dist/openapi/models/MimeGroupSchema.d.ts +1 -1
  217. package/dist/openapi/models/MimeGroupSchema.js +1 -1
  218. package/dist/openapi/models/MultiInputSource.d.ts +1 -1
  219. package/dist/openapi/models/MultiInputSource.js +1 -1
  220. package/dist/openapi/models/MultipartCompleteRequest.d.ts +1 -1
  221. package/dist/openapi/models/MultipartCompleteRequest.js +1 -1
  222. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +1 -1
  223. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +1 -1
  224. package/dist/openapi/models/MultipartCompleteResponse.d.ts +1 -1
  225. package/dist/openapi/models/MultipartCompleteResponse.js +1 -1
  226. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +1 -1
  227. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +1 -1
  228. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +1 -1
  229. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +1 -1
  230. package/dist/openapi/models/MultipartInitiateResponse.d.ts +1 -1
  231. package/dist/openapi/models/MultipartInitiateResponse.js +1 -1
  232. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +1 -1
  233. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +1 -1
  234. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +1 -1
  235. package/dist/openapi/models/MultipartKeepaliveResponse.js +1 -1
  236. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +1 -1
  237. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +1 -1
  238. package/dist/openapi/models/MultipartPartListing.d.ts +1 -1
  239. package/dist/openapi/models/MultipartPartListing.js +1 -1
  240. package/dist/openapi/models/MultipartPresignRequest.d.ts +1 -1
  241. package/dist/openapi/models/MultipartPresignRequest.js +1 -1
  242. package/dist/openapi/models/MultipartPresignResponse.d.ts +1 -1
  243. package/dist/openapi/models/MultipartPresignResponse.js +1 -1
  244. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +1 -1
  245. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +1 -1
  246. package/dist/openapi/models/MultipartStatusResponse.d.ts +1 -1
  247. package/dist/openapi/models/MultipartStatusResponse.js +1 -1
  248. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +1 -1
  249. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +1 -1
  250. package/dist/openapi/models/NotifyConfig.d.ts +46 -0
  251. package/dist/openapi/models/NotifyConfig.js +42 -0
  252. package/dist/openapi/models/OperationCapability.d.ts +1 -1
  253. package/dist/openapi/models/OperationCapability.js +1 -1
  254. package/dist/openapi/models/OperationDefinition.d.ts +1 -1
  255. package/dist/openapi/models/OperationDefinition.js +1 -1
  256. package/dist/openapi/models/OperationDownload.d.ts +1 -1
  257. package/dist/openapi/models/OperationDownload.js +1 -1
  258. package/dist/openapi/models/OperationInputModel.d.ts +1 -1
  259. package/dist/openapi/models/OperationInputModel.js +1 -1
  260. package/dist/openapi/models/OperationResponse.d.ts +1 -1
  261. package/dist/openapi/models/OperationResponse.js +1 -1
  262. package/dist/openapi/models/OperationResult.d.ts +1 -1
  263. package/dist/openapi/models/OperationResult.js +1 -1
  264. package/dist/openapi/models/OperationResultMetadata.d.ts +1 -1
  265. package/dist/openapi/models/OperationResultMetadata.js +1 -1
  266. package/dist/openapi/models/OperationResultMetrics.d.ts +1 -1
  267. package/dist/openapi/models/OperationResultMetrics.js +1 -1
  268. package/dist/openapi/models/OperationSchemaDefinition.d.ts +1 -1
  269. package/dist/openapi/models/OperationSchemaDefinition.js +1 -1
  270. package/dist/openapi/models/OperationStatus.d.ts +1 -1
  271. package/dist/openapi/models/OperationStatus.js +1 -1
  272. package/dist/openapi/models/OperationType.d.ts +1 -1
  273. package/dist/openapi/models/OperationType.js +1 -1
  274. package/dist/openapi/models/OperationsSchemaResponse.d.ts +1 -1
  275. package/dist/openapi/models/OperationsSchemaResponse.js +1 -1
  276. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +1 -1
  277. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +1 -1
  278. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +1 -1
  279. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +1 -1
  280. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +1 -1
  281. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +1 -1
  282. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +1 -1
  283. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +1 -1
  284. package/dist/openapi/models/OptionSchema.d.ts +1 -1
  285. package/dist/openapi/models/OptionSchema.js +1 -1
  286. package/dist/openapi/models/OutputProperties.d.ts +1 -1
  287. package/dist/openapi/models/OutputProperties.js +1 -1
  288. package/dist/openapi/models/OutputPropertiesIsAnimated.d.ts +1 -1
  289. package/dist/openapi/models/OutputPropertiesIsAnimated.js +1 -1
  290. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +1 -1
  291. package/dist/openapi/models/PerRoleCardinalityEntry.js +1 -1
  292. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +1 -1
  293. package/dist/openapi/models/PerValueAvailabilityEntry.js +1 -1
  294. package/dist/openapi/models/PresignedUrlPart.d.ts +1 -1
  295. package/dist/openapi/models/PresignedUrlPart.js +1 -1
  296. package/dist/openapi/models/ProbePendingResponse.d.ts +1 -1
  297. package/dist/openapi/models/ProbePendingResponse.js +1 -1
  298. package/dist/openapi/models/ProcessingClass.d.ts +1 -1
  299. package/dist/openapi/models/ProcessingClass.js +1 -1
  300. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +1 -1
  301. package/dist/openapi/models/ProcessingClassBandViolation.js +1 -1
  302. package/dist/openapi/models/ProcessingClassConstraints.d.ts +1 -1
  303. package/dist/openapi/models/ProcessingClassConstraints.js +1 -1
  304. package/dist/openapi/models/ProcessingClassEntry.d.ts +1 -1
  305. package/dist/openapi/models/ProcessingClassEntry.js +1 -1
  306. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +1 -1
  307. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +1 -1
  308. package/dist/openapi/models/ProcessingClassHint.d.ts +1 -1
  309. package/dist/openapi/models/ProcessingClassHint.js +1 -1
  310. package/dist/openapi/models/ProcessingClassReason.d.ts +1 -1
  311. package/dist/openapi/models/ProcessingClassReason.js +1 -1
  312. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +1 -1
  313. package/dist/openapi/models/ProcessingClassRejectReason.js +1 -1
  314. package/dist/openapi/models/ProcessingPlan.d.ts +1 -1
  315. package/dist/openapi/models/ProcessingPlan.js +1 -1
  316. package/dist/openapi/models/ProcessingPlanJob.d.ts +1 -1
  317. package/dist/openapi/models/ProcessingPlanJob.js +1 -1
  318. package/dist/openapi/models/ReEncodeDecision.d.ts +1 -1
  319. package/dist/openapi/models/ReEncodeDecision.js +1 -1
  320. package/dist/openapi/models/ReadinessResponse.d.ts +1 -1
  321. package/dist/openapi/models/ReadinessResponse.js +1 -1
  322. package/dist/openapi/models/RegisterUser422Response.d.ts +1 -1
  323. package/dist/openapi/models/RegisterUser422Response.js +1 -1
  324. package/dist/openapi/models/RegisterUserRequest.d.ts +1 -1
  325. package/dist/openapi/models/RegisterUserRequest.js +1 -1
  326. package/dist/openapi/models/{ForgotPasswordRequest.d.ts → ResendVerificationEmailRequest.d.ts} +10 -10
  327. package/dist/openapi/models/{ForgotPasswordRequest.js → ResendVerificationEmailRequest.js} +9 -9
  328. package/dist/openapi/models/ResetPasswordRequest.d.ts +1 -1
  329. package/dist/openapi/models/ResetPasswordRequest.js +1 -1
  330. package/dist/openapi/models/ResponseEnvelope.d.ts +1 -1
  331. package/dist/openapi/models/ResponseEnvelope.js +1 -1
  332. package/dist/openapi/models/RetryResponse.d.ts +1 -1
  333. package/dist/openapi/models/RetryResponse.js +1 -1
  334. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +1 -1
  335. package/dist/openapi/models/RetrySuccessEnvelope.js +1 -1
  336. package/dist/openapi/models/SseCompletionBase.d.ts +1 -1
  337. package/dist/openapi/models/SseCompletionBase.js +1 -1
  338. package/dist/openapi/models/SseEventType.d.ts +1 -1
  339. package/dist/openapi/models/SseEventType.js +1 -1
  340. package/dist/openapi/models/SseJobCompletedData.d.ts +1 -1
  341. package/dist/openapi/models/SseJobCompletedData.js +1 -1
  342. package/dist/openapi/models/SseJobFailedData.d.ts +1 -1
  343. package/dist/openapi/models/SseJobFailedData.js +1 -1
  344. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +1 -1
  345. package/dist/openapi/models/SseMultiOutputCompletion.js +1 -1
  346. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +1 -1
  347. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +1 -1
  348. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +1 -1
  349. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +1 -1
  350. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +1 -1
  351. package/dist/openapi/models/SseMultiOutputResultEntry.js +1 -1
  352. package/dist/openapi/models/SseOperationCompletedData.d.ts +1 -1
  353. package/dist/openapi/models/SseOperationCompletedData.js +1 -1
  354. package/dist/openapi/models/SseOperationCompletionResult.d.ts +1 -1
  355. package/dist/openapi/models/SseOperationCompletionResult.js +1 -1
  356. package/dist/openapi/models/SseOperationFailedData.d.ts +1 -1
  357. package/dist/openapi/models/SseOperationFailedData.js +1 -1
  358. package/dist/openapi/models/SseOperationProgressData.d.ts +1 -1
  359. package/dist/openapi/models/SseOperationProgressData.js +1 -1
  360. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +1 -1
  361. package/dist/openapi/models/SseSingleOutputCompletion.js +1 -1
  362. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +1 -1
  363. package/dist/openapi/models/SseWorkflowTerminalData.js +1 -1
  364. package/dist/openapi/models/TierRestrictionKind.d.ts +1 -1
  365. package/dist/openapi/models/TierRestrictionKind.js +1 -1
  366. package/dist/openapi/models/TierRestrictionResponse.d.ts +1 -1
  367. package/dist/openapi/models/TierRestrictionResponse.js +1 -1
  368. package/dist/openapi/models/UpdateProfile200Response.d.ts +1 -1
  369. package/dist/openapi/models/UpdateProfile200Response.js +1 -1
  370. package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +1 -1
  371. package/dist/openapi/models/UpdateProfile200ResponseData.js +1 -1
  372. package/dist/openapi/models/UpdateProfile422Response.d.ts +1 -1
  373. package/dist/openapi/models/UpdateProfile422Response.js +1 -1
  374. package/dist/openapi/models/UpdateProfileRequest.d.ts +1 -1
  375. package/dist/openapi/models/UpdateProfileRequest.js +1 -1
  376. package/dist/openapi/models/UploadConstraintsApplied.d.ts +1 -1
  377. package/dist/openapi/models/UploadConstraintsApplied.js +1 -1
  378. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +1 -1
  379. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +1 -1
  380. package/dist/openapi/models/UploadFile403Response.d.ts +1 -1
  381. package/dist/openapi/models/UploadFile403Response.js +1 -1
  382. package/dist/openapi/models/UploadFile422Response.d.ts +1 -1
  383. package/dist/openapi/models/UploadFile422Response.js +1 -1
  384. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +1 -1
  385. package/dist/openapi/models/UploadProbeMediaMetadata.js +1 -1
  386. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +1 -1
  387. package/dist/openapi/models/UploadProbeProcessingClass.js +1 -1
  388. package/dist/openapi/models/UploadProbeResponse.d.ts +1 -1
  389. package/dist/openapi/models/UploadProbeResponse.js +1 -1
  390. package/dist/openapi/models/UploadProbeStatus.d.ts +1 -1
  391. package/dist/openapi/models/UploadProbeStatus.js +1 -1
  392. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +1 -1
  393. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +1 -1
  394. package/dist/openapi/models/UploadResponse.d.ts +1 -1
  395. package/dist/openapi/models/UploadResponse.js +1 -1
  396. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +1 -1
  397. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +1 -1
  398. package/dist/openapi/models/UploadSource.d.ts +19 -1
  399. package/dist/openapi/models/UploadSource.js +3 -1
  400. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +1 -1
  401. package/dist/openapi/models/UploadSuccessEnvelope.js +1 -1
  402. package/dist/openapi/models/UploadThresholds.d.ts +1 -1
  403. package/dist/openapi/models/UploadThresholds.js +1 -1
  404. package/dist/openapi/models/UserTier.d.ts +1 -1
  405. package/dist/openapi/models/UserTier.js +1 -1
  406. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +1 -1
  407. package/dist/openapi/models/ValidationErrorEnvelope.js +1 -1
  408. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +1 -1
  409. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +1 -1
  410. package/dist/openapi/models/VerifyEmailRequest.d.ts +1 -1
  411. package/dist/openapi/models/VerifyEmailRequest.js +1 -1
  412. package/dist/openapi/models/WarningType.d.ts +1 -1
  413. package/dist/openapi/models/WarningType.js +1 -1
  414. package/dist/openapi/models/WebhookOperationContext.d.ts +1 -1
  415. package/dist/openapi/models/WebhookOperationContext.js +1 -1
  416. package/dist/openapi/models/WebhookPayload.d.ts +1 -1
  417. package/dist/openapi/models/WebhookPayload.js +1 -1
  418. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +1 -1
  419. package/dist/openapi/models/WorkflowCancelBillingEffect.js +1 -1
  420. package/dist/openapi/models/WorkflowCancelResponse.d.ts +1 -1
  421. package/dist/openapi/models/WorkflowCancelResponse.js +1 -1
  422. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +1 -1
  423. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +1 -1
  424. package/dist/openapi/models/WorkflowCreateRequest.d.ts +22 -1
  425. package/dist/openapi/models/WorkflowCreateRequest.js +4 -1
  426. package/dist/openapi/models/WorkflowCreateResponse.d.ts +1 -1
  427. package/dist/openapi/models/WorkflowCreateResponse.js +1 -1
  428. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +1 -1
  429. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +1 -1
  430. package/dist/openapi/models/WorkflowCreditSummary.d.ts +1 -1
  431. package/dist/openapi/models/WorkflowCreditSummary.js +1 -1
  432. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +1 -1
  433. package/dist/openapi/models/WorkflowDownloadResponse.js +1 -1
  434. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +1 -1
  435. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +1 -1
  436. package/dist/openapi/models/WorkflowEdge.d.ts +1 -1
  437. package/dist/openapi/models/WorkflowEdge.js +1 -1
  438. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +1 -1
  439. package/dist/openapi/models/WorkflowExpiredResponse.js +1 -1
  440. package/dist/openapi/models/WorkflowListResponse.d.ts +1 -1
  441. package/dist/openapi/models/WorkflowListResponse.js +1 -1
  442. package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +1 -1
  443. package/dist/openapi/models/WorkflowListSuccessEnvelope.js +1 -1
  444. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +1 -1
  445. package/dist/openapi/models/WorkflowPauseRequiredAction.js +1 -1
  446. package/dist/openapi/models/WorkflowPausedDetail.d.ts +1 -1
  447. package/dist/openapi/models/WorkflowPausedDetail.js +1 -1
  448. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +1 -1
  449. package/dist/openapi/models/WorkflowPausedDetailLinks.js +1 -1
  450. package/dist/openapi/models/WorkflowProcessing.d.ts +1 -1
  451. package/dist/openapi/models/WorkflowProcessing.js +1 -1
  452. package/dist/openapi/models/WorkflowResumeResponse.d.ts +1 -1
  453. package/dist/openapi/models/WorkflowResumeResponse.js +1 -1
  454. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +1 -1
  455. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +1 -1
  456. package/dist/openapi/models/WorkflowSource.d.ts +1 -1
  457. package/dist/openapi/models/WorkflowSource.js +1 -1
  458. package/dist/openapi/models/WorkflowStatus.d.ts +1 -1
  459. package/dist/openapi/models/WorkflowStatus.js +1 -1
  460. package/dist/openapi/models/WorkflowStatusResponse.d.ts +1 -1
  461. package/dist/openapi/models/WorkflowStatusResponse.js +1 -1
  462. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +1 -1
  463. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +1 -1
  464. package/dist/openapi/models/WorkflowSummary.d.ts +1 -1
  465. package/dist/openapi/models/WorkflowSummary.js +1 -1
  466. package/dist/openapi/models/WorkflowSummaryJob.d.ts +1 -1
  467. package/dist/openapi/models/WorkflowSummaryJob.js +1 -1
  468. package/dist/openapi/models/WorkflowWarning.d.ts +1 -1
  469. package/dist/openapi/models/WorkflowWarning.js +1 -1
  470. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +1 -1
  471. package/dist/openapi/models/WorkflowWarningSeverity.js +1 -1
  472. package/dist/openapi/models/index.d.ts +5 -1
  473. package/dist/openapi/models/index.js +5 -1
  474. package/dist/openapi/runtime.d.ts +1 -1
  475. package/dist/openapi/runtime.js +1 -1
  476. package/dist/operations/compress.d.ts +0 -21
  477. package/dist/operations/compress.js +0 -14
  478. package/dist/operations/compress.metadata.js +0 -31
  479. package/openapi/api.yaml +355 -95
  480. package/operation-capabilities/operation-capabilities.json +1 -1
  481. package/operations/schemas/compress.yaml +10 -54
  482. package/package.json +2 -2
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -0,0 +1,73 @@
1
+ /**
2
+ * GISL Compression API
3
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
+ *
5
+ * The version of the OpenAPI document: 2.170.0
6
+ *
7
+ *
8
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
9
+ * https://openapi-generator.tech
10
+ * Do not edit the class manually.
11
+ */
12
+ import type { CallbackEventType } from './CallbackEventType.js';
13
+ /**
14
+ * Email-channel completion notification. When a subscribed workflow
15
+ * event occurs, the API emails each recipient in `to` a link to the
16
+ * workflow's results — a **server-composed, short-lived presigned URL**
17
+ * to the same downloadable outputs as `GET /api/workflows/{id}/downloads`.
18
+ * The request carries recipients + event selection ONLY: the link's
19
+ * target, contents, and expiry are determined server-side and can never
20
+ * be supplied or influenced by the caller.
21
+ *
22
+ * The emailed link is a time-limited **bearer capability** — anyone who
23
+ * holds it (including anyone the email is forwarded to) can download
24
+ * those outputs until it expires; it grants no other account access and
25
+ * conveys no session. This is the same trust model as any presigned
26
+ * download URL.
27
+ *
28
+ * **Anti-abuse (security).** Because `POST /api/workflows` is callable
29
+ * with `optional` auth, an unconstrained recipient list would be an open
30
+ * mail-relay / spam-amplification vector. Recipients are therefore
31
+ * subject to **server-side anti-abuse controls** — the API restricts who
32
+ * may be emailed (the exact recipient policy, e.g. the authenticated
33
+ * account's own verified address(es), is API/product-owned and enforced
34
+ * server-side, NOT a caller-supplied setting) and applies send-rate
35
+ * limits; a request whose recipients fall outside the allowed set is
36
+ * rejected. This is part of what the `planned` gate covers until the
37
+ * dispatch engine + its abuse controls ship.
38
+ *
39
+ * @export
40
+ * @interface EmailNotify
41
+ */
42
+ export interface EmailNotify {
43
+ /**
44
+ * Recipient email addresses (1–10). At least one is required when
45
+ * `email` is present. Subject to the server-side recipient policy
46
+ * above — the API may reject or narrow recipients outside the
47
+ * allowed set (anti-abuse); a caller cannot email arbitrary third
48
+ * parties.
49
+ *
50
+ * @type {Array<string>}
51
+ * @memberof EmailNotify
52
+ */
53
+ to: Array<string>;
54
+ /**
55
+ * Which workflow events trigger the email. Reuses the
56
+ * `CallbackEventType` vocabulary shared with `callback_events`
57
+ * (webhook) — the notify surface does NOT fork the event enum.
58
+ * Defaults to terminal events only (mirrors the `callback_events`
59
+ * default); `operation.completed` is opt-in for granular progress.
60
+ *
61
+ * @type {Array<CallbackEventType>}
62
+ * @memberof EmailNotify
63
+ */
64
+ events?: Array<CallbackEventType>;
65
+ }
66
+ /**
67
+ * Check if a given object implements the EmailNotify interface.
68
+ */
69
+ export declare function instanceOfEmailNotify(value: object): value is EmailNotify;
70
+ export declare function EmailNotifyFromJSON(json: any): EmailNotify;
71
+ export declare function EmailNotifyFromJSONTyped(json: any, ignoreDiscriminator: boolean): EmailNotify;
72
+ export declare function EmailNotifyToJSON(json: any): EmailNotify;
73
+ export declare function EmailNotifyToJSONTyped(value?: EmailNotify | null, ignoreDiscriminator?: boolean): any;
@@ -0,0 +1,46 @@
1
+ /* tslint:disable */
2
+ /* eslint-disable */
3
+ /**
4
+ * GISL Compression API
5
+ * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
+ *
7
+ * The version of the OpenAPI document: 2.170.0
8
+ *
9
+ *
10
+ * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
11
+ * https://openapi-generator.tech
12
+ * Do not edit the class manually.
13
+ */
14
+ import { CallbackEventTypeFromJSON, CallbackEventTypeToJSON, } from './CallbackEventType.js';
15
+ /**
16
+ * Check if a given object implements the EmailNotify interface.
17
+ */
18
+ export function instanceOfEmailNotify(value) {
19
+ if (!('to' in value) || value['to'] === undefined)
20
+ return false;
21
+ return true;
22
+ }
23
+ export function EmailNotifyFromJSON(json) {
24
+ return EmailNotifyFromJSONTyped(json, false);
25
+ }
26
+ export function EmailNotifyFromJSONTyped(json, ignoreDiscriminator) {
27
+ if (json == null) {
28
+ return json;
29
+ }
30
+ return {
31
+ 'to': json['to'],
32
+ 'events': json['events'] == null ? undefined : (json['events'].map(CallbackEventTypeFromJSON)),
33
+ };
34
+ }
35
+ export function EmailNotifyToJSON(json) {
36
+ return EmailNotifyToJSONTyped(json, false);
37
+ }
38
+ export function EmailNotifyToJSONTyped(value, ignoreDiscriminator = false) {
39
+ if (value == null) {
40
+ return value;
41
+ }
42
+ return {
43
+ 'to': value['to'],
44
+ 'events': value['events'] == null ? undefined : (value['events'].map(CallbackEventTypeToJSON)),
45
+ };
46
+ }
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -4,7 +4,7 @@
4
4
  * GISL Compression API
5
5
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
6
6
  *
7
- * The version of the OpenAPI document: 2.162.0
7
+ * The version of the OpenAPI document: 2.170.0
8
8
  *
9
9
  *
10
10
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -2,7 +2,7 @@
2
2
  * GISL Compression API
3
3
  * REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
4
4
  *
5
- * The version of the OpenAPI document: 2.162.0
5
+ * The version of the OpenAPI document: 2.170.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).