@giveitsmaller/contracts 0.69.0 → 0.70.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 (516) hide show
  1. package/README.md +2 -2
  2. package/accepted-options/accepted-options.json +1 -1
  3. package/accepted-options/image-output-routes.json +1 -1
  4. package/availability/availability.json +5 -5
  5. package/code-builder/code-builder-metadata.json +5 -5
  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 +1 -1
  21. package/dist/openapi/models/AuthErrorType.js +1 -1
  22. package/dist/openapi/models/AuthRejectionEnvelope.d.ts +1 -1
  23. package/dist/openapi/models/AuthRejectionEnvelope.js +1 -1
  24. package/dist/openapi/models/AuthenticatedIdentity.d.ts +1 -1
  25. package/dist/openapi/models/AuthenticatedIdentity.js +1 -1
  26. package/dist/openapi/models/AvailabilityValue.d.ts +1 -1
  27. package/dist/openapi/models/AvailabilityValue.js +1 -1
  28. package/dist/openapi/models/BalanceExhaustedResponse.d.ts +1 -1
  29. package/dist/openapi/models/BalanceExhaustedResponse.js +1 -1
  30. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +1 -1
  31. package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +1 -1
  32. package/dist/openapi/models/BillingCheckoutRequest.d.ts +1 -1
  33. package/dist/openapi/models/BillingCheckoutRequest.js +1 -1
  34. package/dist/openapi/models/BillingCheckoutSession.d.ts +1 -1
  35. package/dist/openapi/models/BillingCheckoutSession.js +1 -1
  36. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.d.ts +1 -1
  37. package/dist/openapi/models/BillingCheckoutSuccessEnvelope.js +1 -1
  38. package/dist/openapi/models/CallbackEventType.d.ts +1 -1
  39. package/dist/openapi/models/CallbackEventType.js +1 -1
  40. package/dist/openapi/models/CancelAccountDeletion200Response.d.ts +1 -1
  41. package/dist/openapi/models/CancelAccountDeletion200Response.js +1 -1
  42. package/dist/openapi/models/CancelAccountDeletion200ResponseData.d.ts +1 -1
  43. package/dist/openapi/models/CancelAccountDeletion200ResponseData.js +1 -1
  44. package/dist/openapi/models/CapabilityCondition.d.ts +1 -1
  45. package/dist/openapi/models/CapabilityCondition.js +1 -1
  46. package/dist/openapi/models/CapabilityConditionOneOf.d.ts +1 -1
  47. package/dist/openapi/models/CapabilityConditionOneOf.js +1 -1
  48. package/dist/openapi/models/CapabilityConditionOneOf1.d.ts +1 -1
  49. package/dist/openapi/models/CapabilityConditionOneOf1.js +1 -1
  50. package/dist/openapi/models/CapabilityConditionOneOf2.d.ts +1 -1
  51. package/dist/openapi/models/CapabilityConditionOneOf2.js +1 -1
  52. package/dist/openapi/models/CapabilityConditionOneOf3.d.ts +1 -1
  53. package/dist/openapi/models/CapabilityConditionOneOf3.js +1 -1
  54. package/dist/openapi/models/CapabilityConditionOneOf4.d.ts +1 -1
  55. package/dist/openapi/models/CapabilityConditionOneOf4.js +1 -1
  56. package/dist/openapi/models/CapabilityConditionOneOf5.d.ts +1 -1
  57. package/dist/openapi/models/CapabilityConditionOneOf5.js +1 -1
  58. package/dist/openapi/models/CapabilityConditionOneOf6.d.ts +1 -1
  59. package/dist/openapi/models/CapabilityConditionOneOf6.js +1 -1
  60. package/dist/openapi/models/CapabilityConstraint.d.ts +1 -1
  61. package/dist/openapi/models/CapabilityConstraint.js +1 -1
  62. package/dist/openapi/models/CapabilityInputSpec.d.ts +1 -1
  63. package/dist/openapi/models/CapabilityInputSpec.js +1 -1
  64. package/dist/openapi/models/CapabilityProduces.d.ts +1 -1
  65. package/dist/openapi/models/CapabilityProduces.js +1 -1
  66. package/dist/openapi/models/CapabilityProducesOneOf.d.ts +1 -1
  67. package/dist/openapi/models/CapabilityProducesOneOf.js +1 -1
  68. package/dist/openapi/models/CapabilityProducesOneOf1.d.ts +1 -1
  69. package/dist/openapi/models/CapabilityProducesOneOf1.js +1 -1
  70. package/dist/openapi/models/CapabilityProducesOneOf2.d.ts +1 -1
  71. package/dist/openapi/models/CapabilityProducesOneOf2.js +1 -1
  72. package/dist/openapi/models/ChangePasswordRequest.d.ts +1 -1
  73. package/dist/openapi/models/ChangePasswordRequest.js +1 -1
  74. package/dist/openapi/models/CodegenSource.d.ts +1 -1
  75. package/dist/openapi/models/CodegenSource.js +1 -1
  76. package/dist/openapi/models/CodegenSourceInput.d.ts +1 -1
  77. package/dist/openapi/models/CodegenSourceInput.js +1 -1
  78. package/dist/openapi/models/CodegenSourceJob.d.ts +1 -1
  79. package/dist/openapi/models/CodegenSourceJob.js +1 -1
  80. package/dist/openapi/models/CodegenSourceJobSource.d.ts +1 -1
  81. package/dist/openapi/models/CodegenSourceJobSource.js +1 -1
  82. package/dist/openapi/models/CodegenSourceOperation.d.ts +1 -1
  83. package/dist/openapi/models/CodegenSourceOperation.js +1 -1
  84. package/dist/openapi/models/CodegenUploadPlaceholder.d.ts +1 -1
  85. package/dist/openapi/models/CodegenUploadPlaceholder.js +1 -1
  86. package/dist/openapi/models/CompositionPlan.d.ts +1 -1
  87. package/dist/openapi/models/CompositionPlan.js +1 -1
  88. package/dist/openapi/models/CompositionPlanJob.d.ts +1 -1
  89. package/dist/openapi/models/CompositionPlanJob.js +1 -1
  90. package/dist/openapi/models/CompositionPlanOperation.d.ts +1 -1
  91. package/dist/openapi/models/CompositionPlanOperation.js +1 -1
  92. package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +1 -1
  93. package/dist/openapi/models/ConfirmEmailChange200Response.js +1 -1
  94. package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +1 -1
  95. package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +1 -1
  96. package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +1 -1
  97. package/dist/openapi/models/ConfirmEmailChangeRequest.js +1 -1
  98. package/dist/openapi/models/ConnectionSource.d.ts +1 -1
  99. package/dist/openapi/models/ConnectionSource.js +1 -1
  100. package/dist/openapi/models/ContactRequest.d.ts +1 -1
  101. package/dist/openapi/models/ContactRequest.js +1 -1
  102. package/dist/openapi/models/ContactSubject.d.ts +1 -1
  103. package/dist/openapi/models/ContactSubject.js +1 -1
  104. package/dist/openapi/models/ContactValidationErrorResponse.d.ts +1 -1
  105. package/dist/openapi/models/ContactValidationErrorResponse.js +1 -1
  106. package/dist/openapi/models/CreateApiKey201Response.d.ts +1 -1
  107. package/dist/openapi/models/CreateApiKey201Response.js +1 -1
  108. package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +1 -1
  109. package/dist/openapi/models/CreateApiKey201ResponseData.js +1 -1
  110. package/dist/openapi/models/CreateApiKeyRequest.d.ts +1 -1
  111. package/dist/openapi/models/CreateApiKeyRequest.js +1 -1
  112. package/dist/openapi/models/CreateBillingCheckoutSession422Response.d.ts +1 -1
  113. package/dist/openapi/models/CreateBillingCheckoutSession422Response.js +1 -1
  114. package/dist/openapi/models/CreateExternalImport403Response.d.ts +1 -1
  115. package/dist/openapi/models/CreateExternalImport403Response.js +1 -1
  116. package/dist/openapi/models/CreateExternalImport422Response.d.ts +1 -1
  117. package/dist/openapi/models/CreateExternalImport422Response.js +1 -1
  118. package/dist/openapi/models/CreateWorkflow401Response.d.ts +1 -1
  119. package/dist/openapi/models/CreateWorkflow401Response.js +1 -1
  120. package/dist/openapi/models/CreateWorkflow422Response.d.ts +1 -1
  121. package/dist/openapi/models/CreateWorkflow422Response.js +1 -1
  122. package/dist/openapi/models/CreditTransaction.d.ts +24 -11
  123. package/dist/openapi/models/CreditTransaction.js +1 -1
  124. package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +1 -1
  125. package/dist/openapi/models/CreditTransactionSourceBucket.js +1 -1
  126. package/dist/openapi/models/CreditsBalanceResponse.d.ts +1 -1
  127. package/dist/openapi/models/CreditsBalanceResponse.js +1 -1
  128. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +1 -1
  129. package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +1 -1
  130. package/dist/openapi/models/CreditsUsageResponse.d.ts +1 -1
  131. package/dist/openapi/models/CreditsUsageResponse.js +1 -1
  132. package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +1 -1
  133. package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +1 -1
  134. package/dist/openapi/models/Delivery.d.ts +1 -1
  135. package/dist/openapi/models/Delivery.js +1 -1
  136. package/dist/openapi/models/DeliveryOutputRef.d.ts +1 -1
  137. package/dist/openapi/models/DeliveryOutputRef.js +1 -1
  138. package/dist/openapi/models/DeliveryPlan.d.ts +1 -1
  139. package/dist/openapi/models/DeliveryPlan.js +1 -1
  140. package/dist/openapi/models/DeliveryPlanOutput.d.ts +1 -1
  141. package/dist/openapi/models/DeliveryPlanOutput.js +1 -1
  142. package/dist/openapi/models/DeliveryPlanReason.d.ts +1 -1
  143. package/dist/openapi/models/DeliveryPlanReason.js +1 -1
  144. package/dist/openapi/models/DeliverySelection.d.ts +1 -1
  145. package/dist/openapi/models/DeliverySelection.js +1 -1
  146. package/dist/openapi/models/DownloadBundle.d.ts +1 -1
  147. package/dist/openapi/models/DownloadBundle.js +1 -1
  148. package/dist/openapi/models/DroppedOption.d.ts +1 -1
  149. package/dist/openapi/models/DroppedOption.js +1 -1
  150. package/dist/openapi/models/EmailNotify.d.ts +1 -1
  151. package/dist/openapi/models/EmailNotify.js +1 -1
  152. package/dist/openapi/models/EmptySuccessEnvelope.d.ts +1 -1
  153. package/dist/openapi/models/EmptySuccessEnvelope.js +1 -1
  154. package/dist/openapi/models/EndpointProjection.d.ts +1 -1
  155. package/dist/openapi/models/EndpointProjection.js +1 -1
  156. package/dist/openapi/models/EndpointProjectionServersInner.d.ts +1 -1
  157. package/dist/openapi/models/EndpointProjectionServersInner.js +1 -1
  158. package/dist/openapi/models/ErrorEnvelope.d.ts +1 -1
  159. package/dist/openapi/models/ErrorEnvelope.js +1 -1
  160. package/dist/openapi/models/EstimateQuality.d.ts +1 -1
  161. package/dist/openapi/models/EstimateQuality.js +1 -1
  162. package/dist/openapi/models/EstimateRange.d.ts +1 -1
  163. package/dist/openapi/models/EstimateRange.js +1 -1
  164. package/dist/openapi/models/ExportAccountData200Response.d.ts +1 -1
  165. package/dist/openapi/models/ExportAccountData200Response.js +1 -1
  166. package/dist/openapi/models/ExportAccountData200ResponseData.d.ts +1 -1
  167. package/dist/openapi/models/ExportAccountData200ResponseData.js +1 -1
  168. package/dist/openapi/models/ExternalDestination.d.ts +1 -1
  169. package/dist/openapi/models/ExternalDestination.js +1 -1
  170. package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +1 -1
  171. package/dist/openapi/models/ExternalImportCreatedResponse.js +1 -1
  172. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +1 -1
  173. package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +1 -1
  174. package/dist/openapi/models/ExternalImportRequest.d.ts +1 -1
  175. package/dist/openapi/models/ExternalImportRequest.js +1 -1
  176. package/dist/openapi/models/ExternalImportToken.d.ts +1 -1
  177. package/dist/openapi/models/ExternalImportToken.js +1 -1
  178. package/dist/openapi/models/ExternalSource.d.ts +1 -1
  179. package/dist/openapi/models/ExternalSource.js +1 -1
  180. package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +1 -1
  181. package/dist/openapi/models/FeatureNotAvailableResponse.js +1 -1
  182. package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +1 -1
  183. package/dist/openapi/models/FeatureTierRestrictedResponse.js +1 -1
  184. package/dist/openapi/models/FeatureViolation.d.ts +1 -1
  185. package/dist/openapi/models/FeatureViolation.js +1 -1
  186. package/dist/openapi/models/GetProfile200Response.d.ts +1 -1
  187. package/dist/openapi/models/GetProfile200Response.js +1 -1
  188. package/dist/openapi/models/GetProfile200ResponseData.d.ts +1 -1
  189. package/dist/openapi/models/GetProfile200ResponseData.js +1 -1
  190. package/dist/openapi/models/ImageEncodeCapabilities.d.ts +1 -1
  191. package/dist/openapi/models/ImageEncodeCapabilities.js +1 -1
  192. package/dist/openapi/models/JobDefinition.d.ts +1 -1
  193. package/dist/openapi/models/JobDefinition.js +1 -1
  194. package/dist/openapi/models/JobDownload.d.ts +1 -1
  195. package/dist/openapi/models/JobDownload.js +1 -1
  196. package/dist/openapi/models/JobInputV2.d.ts +1 -1
  197. package/dist/openapi/models/JobInputV2.js +1 -1
  198. package/dist/openapi/models/JobMediaClass.d.ts +1 -1
  199. package/dist/openapi/models/JobMediaClass.js +1 -1
  200. package/dist/openapi/models/JobOutputSource.d.ts +1 -1
  201. package/dist/openapi/models/JobOutputSource.js +1 -1
  202. package/dist/openapi/models/JobResponse.d.ts +1 -1
  203. package/dist/openapi/models/JobResponse.js +1 -1
  204. package/dist/openapi/models/JobStatus.d.ts +1 -1
  205. package/dist/openapi/models/JobStatus.js +1 -1
  206. package/dist/openapi/models/JobType.d.ts +1 -1
  207. package/dist/openapi/models/JobType.js +1 -1
  208. package/dist/openapi/models/LivenessResponse.d.ts +1 -1
  209. package/dist/openapi/models/LivenessResponse.js +1 -1
  210. package/dist/openapi/models/LoginUser200Response.d.ts +1 -1
  211. package/dist/openapi/models/LoginUser200Response.js +1 -1
  212. package/dist/openapi/models/LoginUser200ResponseData.d.ts +1 -1
  213. package/dist/openapi/models/LoginUser200ResponseData.js +1 -1
  214. package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +1 -1
  215. package/dist/openapi/models/LoginUser200ResponseDataUser.js +1 -1
  216. package/dist/openapi/models/LoginUser401Response.d.ts +1 -1
  217. package/dist/openapi/models/LoginUser401Response.js +1 -1
  218. package/dist/openapi/models/LoginUserRequest.d.ts +1 -1
  219. package/dist/openapi/models/LoginUserRequest.js +1 -1
  220. package/dist/openapi/models/LongFormConcurrencyLimitResponse.d.ts +1 -1
  221. package/dist/openapi/models/LongFormConcurrencyLimitResponse.js +1 -1
  222. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.d.ts +1 -1
  223. package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.js +1 -1
  224. package/dist/openapi/models/MetadataResponse.d.ts +1 -1
  225. package/dist/openapi/models/MetadataResponse.js +1 -1
  226. package/dist/openapi/models/MetadataResponseDimensions.d.ts +1 -1
  227. package/dist/openapi/models/MetadataResponseDimensions.js +1 -1
  228. package/dist/openapi/models/MetadataResponseExif.d.ts +1 -1
  229. package/dist/openapi/models/MetadataResponseExif.js +1 -1
  230. package/dist/openapi/models/MetadataResponseExifGps.d.ts +1 -1
  231. package/dist/openapi/models/MetadataResponseExifGps.js +1 -1
  232. package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +1 -1
  233. package/dist/openapi/models/MetadataSuccessEnvelope.js +1 -1
  234. package/dist/openapi/models/MimeGroupSchema.d.ts +1 -1
  235. package/dist/openapi/models/MimeGroupSchema.js +1 -1
  236. package/dist/openapi/models/MultiInputSource.d.ts +1 -1
  237. package/dist/openapi/models/MultiInputSource.js +1 -1
  238. package/dist/openapi/models/MultipartCompleteRequest.d.ts +1 -1
  239. package/dist/openapi/models/MultipartCompleteRequest.js +1 -1
  240. package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +1 -1
  241. package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +1 -1
  242. package/dist/openapi/models/MultipartCompleteResponse.d.ts +1 -1
  243. package/dist/openapi/models/MultipartCompleteResponse.js +1 -1
  244. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +1 -1
  245. package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +1 -1
  246. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +1 -1
  247. package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +1 -1
  248. package/dist/openapi/models/MultipartInitiateResponse.d.ts +1 -1
  249. package/dist/openapi/models/MultipartInitiateResponse.js +1 -1
  250. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +1 -1
  251. package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +1 -1
  252. package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +1 -1
  253. package/dist/openapi/models/MultipartKeepaliveResponse.js +1 -1
  254. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +1 -1
  255. package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +1 -1
  256. package/dist/openapi/models/MultipartPartListing.d.ts +1 -1
  257. package/dist/openapi/models/MultipartPartListing.js +1 -1
  258. package/dist/openapi/models/MultipartPresignRequest.d.ts +1 -1
  259. package/dist/openapi/models/MultipartPresignRequest.js +1 -1
  260. package/dist/openapi/models/MultipartPresignResponse.d.ts +1 -1
  261. package/dist/openapi/models/MultipartPresignResponse.js +1 -1
  262. package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +1 -1
  263. package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +1 -1
  264. package/dist/openapi/models/MultipartStatusResponse.d.ts +1 -1
  265. package/dist/openapi/models/MultipartStatusResponse.js +1 -1
  266. package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +1 -1
  267. package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +1 -1
  268. package/dist/openapi/models/NotifyConfig.d.ts +1 -1
  269. package/dist/openapi/models/NotifyConfig.js +1 -1
  270. package/dist/openapi/models/OperationCapability.d.ts +1 -1
  271. package/dist/openapi/models/OperationCapability.js +1 -1
  272. package/dist/openapi/models/OperationDefinition.d.ts +1 -1
  273. package/dist/openapi/models/OperationDefinition.js +1 -1
  274. package/dist/openapi/models/OperationDownload.d.ts +1 -1
  275. package/dist/openapi/models/OperationDownload.js +1 -1
  276. package/dist/openapi/models/OperationInputModel.d.ts +1 -1
  277. package/dist/openapi/models/OperationInputModel.js +1 -1
  278. package/dist/openapi/models/OperationResponse.d.ts +1 -1
  279. package/dist/openapi/models/OperationResponse.js +1 -1
  280. package/dist/openapi/models/OperationResult.d.ts +1 -1
  281. package/dist/openapi/models/OperationResult.js +1 -1
  282. package/dist/openapi/models/OperationResultMetadata.d.ts +1 -1
  283. package/dist/openapi/models/OperationResultMetadata.js +1 -1
  284. package/dist/openapi/models/OperationResultMetrics.d.ts +1 -1
  285. package/dist/openapi/models/OperationResultMetrics.js +1 -1
  286. package/dist/openapi/models/OperationSchemaDefinition.d.ts +1 -1
  287. package/dist/openapi/models/OperationSchemaDefinition.js +1 -1
  288. package/dist/openapi/models/OperationStatus.d.ts +1 -1
  289. package/dist/openapi/models/OperationStatus.js +1 -1
  290. package/dist/openapi/models/OperationType.d.ts +1 -1
  291. package/dist/openapi/models/OperationType.js +1 -1
  292. package/dist/openapi/models/OperationsSchemaResponse.d.ts +1 -1
  293. package/dist/openapi/models/OperationsSchemaResponse.js +1 -1
  294. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +1 -1
  295. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +1 -1
  296. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +1 -1
  297. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +1 -1
  298. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +1 -1
  299. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +1 -1
  300. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +1 -1
  301. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +1 -1
  302. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.d.ts +1 -1
  303. package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.js +1 -1
  304. package/dist/openapi/models/OptionSchema.d.ts +1 -1
  305. package/dist/openapi/models/OptionSchema.js +1 -1
  306. package/dist/openapi/models/OutputProperties.d.ts +1 -1
  307. package/dist/openapi/models/OutputProperties.js +1 -1
  308. package/dist/openapi/models/OutputPropertiesIsAnimated.d.ts +1 -1
  309. package/dist/openapi/models/OutputPropertiesIsAnimated.js +1 -1
  310. package/dist/openapi/models/PerClassAvailabilityEntry.d.ts +1 -1
  311. package/dist/openapi/models/PerClassAvailabilityEntry.js +1 -1
  312. package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +1 -1
  313. package/dist/openapi/models/PerRoleCardinalityEntry.js +1 -1
  314. package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +1 -1
  315. package/dist/openapi/models/PerValueAvailabilityEntry.js +1 -1
  316. package/dist/openapi/models/PresignedUrlPart.d.ts +1 -1
  317. package/dist/openapi/models/PresignedUrlPart.js +1 -1
  318. package/dist/openapi/models/ProbePendingResponse.d.ts +1 -1
  319. package/dist/openapi/models/ProbePendingResponse.js +1 -1
  320. package/dist/openapi/models/ProcessingClass.d.ts +1 -1
  321. package/dist/openapi/models/ProcessingClass.js +1 -1
  322. package/dist/openapi/models/ProcessingClassBandViolation.d.ts +1 -1
  323. package/dist/openapi/models/ProcessingClassBandViolation.js +1 -1
  324. package/dist/openapi/models/ProcessingClassConstraints.d.ts +1 -1
  325. package/dist/openapi/models/ProcessingClassConstraints.js +1 -1
  326. package/dist/openapi/models/ProcessingClassEntry.d.ts +1 -1
  327. package/dist/openapi/models/ProcessingClassEntry.js +1 -1
  328. package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +1 -1
  329. package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +1 -1
  330. package/dist/openapi/models/ProcessingClassHint.d.ts +1 -1
  331. package/dist/openapi/models/ProcessingClassHint.js +1 -1
  332. package/dist/openapi/models/ProcessingClassReason.d.ts +1 -1
  333. package/dist/openapi/models/ProcessingClassReason.js +1 -1
  334. package/dist/openapi/models/ProcessingClassRejectReason.d.ts +1 -1
  335. package/dist/openapi/models/ProcessingClassRejectReason.js +1 -1
  336. package/dist/openapi/models/ProcessingPlan.d.ts +1 -1
  337. package/dist/openapi/models/ProcessingPlan.js +1 -1
  338. package/dist/openapi/models/ProcessingPlanJob.d.ts +1 -1
  339. package/dist/openapi/models/ProcessingPlanJob.js +1 -1
  340. package/dist/openapi/models/ReEncodeDecision.d.ts +1 -1
  341. package/dist/openapi/models/ReEncodeDecision.js +1 -1
  342. package/dist/openapi/models/ReadinessResponse.d.ts +1 -1
  343. package/dist/openapi/models/ReadinessResponse.js +1 -1
  344. package/dist/openapi/models/RegisterUser422Response.d.ts +1 -1
  345. package/dist/openapi/models/RegisterUser422Response.js +1 -1
  346. package/dist/openapi/models/RegisterUserRequest.d.ts +1 -1
  347. package/dist/openapi/models/RegisterUserRequest.js +1 -1
  348. package/dist/openapi/models/RequestAccountDeletion200Response.d.ts +1 -1
  349. package/dist/openapi/models/RequestAccountDeletion200Response.js +1 -1
  350. package/dist/openapi/models/RequestAccountDeletion200ResponseData.d.ts +1 -1
  351. package/dist/openapi/models/RequestAccountDeletion200ResponseData.js +1 -1
  352. package/dist/openapi/models/RequestAccountDeletionRequest.d.ts +1 -1
  353. package/dist/openapi/models/RequestAccountDeletionRequest.js +1 -1
  354. package/dist/openapi/models/ResendVerificationEmailRequest.d.ts +1 -1
  355. package/dist/openapi/models/ResendVerificationEmailRequest.js +1 -1
  356. package/dist/openapi/models/ResetPasswordRequest.d.ts +1 -1
  357. package/dist/openapi/models/ResetPasswordRequest.js +1 -1
  358. package/dist/openapi/models/ResponseEnvelope.d.ts +1 -1
  359. package/dist/openapi/models/ResponseEnvelope.js +1 -1
  360. package/dist/openapi/models/RetryResponse.d.ts +1 -1
  361. package/dist/openapi/models/RetryResponse.js +1 -1
  362. package/dist/openapi/models/RetrySuccessEnvelope.d.ts +1 -1
  363. package/dist/openapi/models/RetrySuccessEnvelope.js +1 -1
  364. package/dist/openapi/models/SseCompletionBase.d.ts +1 -1
  365. package/dist/openapi/models/SseCompletionBase.js +1 -1
  366. package/dist/openapi/models/SseEventType.d.ts +1 -1
  367. package/dist/openapi/models/SseEventType.js +1 -1
  368. package/dist/openapi/models/SseJobCompletedData.d.ts +1 -1
  369. package/dist/openapi/models/SseJobCompletedData.js +1 -1
  370. package/dist/openapi/models/SseJobFailedData.d.ts +1 -1
  371. package/dist/openapi/models/SseJobFailedData.js +1 -1
  372. package/dist/openapi/models/SseMultiOutputCompletion.d.ts +1 -1
  373. package/dist/openapi/models/SseMultiOutputCompletion.js +1 -1
  374. package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +1 -1
  375. package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +1 -1
  376. package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +1 -1
  377. package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +1 -1
  378. package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +1 -1
  379. package/dist/openapi/models/SseMultiOutputResultEntry.js +1 -1
  380. package/dist/openapi/models/SseOperationCompletedData.d.ts +1 -1
  381. package/dist/openapi/models/SseOperationCompletedData.js +1 -1
  382. package/dist/openapi/models/SseOperationCompletionResult.d.ts +1 -1
  383. package/dist/openapi/models/SseOperationCompletionResult.js +1 -1
  384. package/dist/openapi/models/SseOperationFailedData.d.ts +1 -1
  385. package/dist/openapi/models/SseOperationFailedData.js +1 -1
  386. package/dist/openapi/models/SseOperationProgressData.d.ts +1 -1
  387. package/dist/openapi/models/SseOperationProgressData.js +1 -1
  388. package/dist/openapi/models/SseSingleOutputCompletion.d.ts +1 -1
  389. package/dist/openapi/models/SseSingleOutputCompletion.js +1 -1
  390. package/dist/openapi/models/SseWorkflowTerminalData.d.ts +1 -1
  391. package/dist/openapi/models/SseWorkflowTerminalData.js +1 -1
  392. package/dist/openapi/models/TierRestrictionKind.d.ts +1 -1
  393. package/dist/openapi/models/TierRestrictionKind.js +1 -1
  394. package/dist/openapi/models/TierRestrictionResponse.d.ts +1 -1
  395. package/dist/openapi/models/TierRestrictionResponse.js +1 -1
  396. package/dist/openapi/models/UpdateProfile200Response.d.ts +1 -1
  397. package/dist/openapi/models/UpdateProfile200Response.js +1 -1
  398. package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +1 -1
  399. package/dist/openapi/models/UpdateProfile200ResponseData.js +1 -1
  400. package/dist/openapi/models/UpdateProfile422Response.d.ts +1 -1
  401. package/dist/openapi/models/UpdateProfile422Response.js +1 -1
  402. package/dist/openapi/models/UpdateProfileRequest.d.ts +1 -1
  403. package/dist/openapi/models/UpdateProfileRequest.js +1 -1
  404. package/dist/openapi/models/UploadConstraintsApplied.d.ts +1 -1
  405. package/dist/openapi/models/UploadConstraintsApplied.js +1 -1
  406. package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +1 -1
  407. package/dist/openapi/models/UploadDurationExceedsTierResponse.js +1 -1
  408. package/dist/openapi/models/UploadFile403Response.d.ts +1 -1
  409. package/dist/openapi/models/UploadFile403Response.js +1 -1
  410. package/dist/openapi/models/UploadFile422Response.d.ts +1 -1
  411. package/dist/openapi/models/UploadFile422Response.js +1 -1
  412. package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +1 -1
  413. package/dist/openapi/models/UploadProbeMediaMetadata.js +1 -1
  414. package/dist/openapi/models/UploadProbeProcessingClass.d.ts +1 -1
  415. package/dist/openapi/models/UploadProbeProcessingClass.js +1 -1
  416. package/dist/openapi/models/UploadProbeResponse.d.ts +1 -1
  417. package/dist/openapi/models/UploadProbeResponse.js +1 -1
  418. package/dist/openapi/models/UploadProbeStatus.d.ts +1 -1
  419. package/dist/openapi/models/UploadProbeStatus.js +1 -1
  420. package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +1 -1
  421. package/dist/openapi/models/UploadProbeSuccessEnvelope.js +1 -1
  422. package/dist/openapi/models/UploadResponse.d.ts +1 -1
  423. package/dist/openapi/models/UploadResponse.js +1 -1
  424. package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +1 -1
  425. package/dist/openapi/models/UploadSizeExceedsTierResponse.js +1 -1
  426. package/dist/openapi/models/UploadSource.d.ts +1 -1
  427. package/dist/openapi/models/UploadSource.js +1 -1
  428. package/dist/openapi/models/UploadSuccessEnvelope.d.ts +1 -1
  429. package/dist/openapi/models/UploadSuccessEnvelope.js +1 -1
  430. package/dist/openapi/models/UploadThresholds.d.ts +1 -1
  431. package/dist/openapi/models/UploadThresholds.js +1 -1
  432. package/dist/openapi/models/UserTier.d.ts +1 -1
  433. package/dist/openapi/models/UserTier.js +1 -1
  434. package/dist/openapi/models/ValidationErrorEnvelope.d.ts +1 -1
  435. package/dist/openapi/models/ValidationErrorEnvelope.js +1 -1
  436. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +1 -1
  437. package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +1 -1
  438. package/dist/openapi/models/VerifyEmailRequest.d.ts +1 -1
  439. package/dist/openapi/models/VerifyEmailRequest.js +1 -1
  440. package/dist/openapi/models/WarningType.d.ts +1 -1
  441. package/dist/openapi/models/WarningType.js +1 -1
  442. package/dist/openapi/models/WebhookOperationContext.d.ts +1 -1
  443. package/dist/openapi/models/WebhookOperationContext.js +1 -1
  444. package/dist/openapi/models/WebhookPayload.d.ts +1 -1
  445. package/dist/openapi/models/WebhookPayload.js +1 -1
  446. package/dist/openapi/models/WorkflowArchiveResponse.d.ts +1 -1
  447. package/dist/openapi/models/WorkflowArchiveResponse.js +1 -1
  448. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.d.ts +1 -1
  449. package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.js +1 -1
  450. package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +1 -1
  451. package/dist/openapi/models/WorkflowCancelBillingEffect.js +1 -1
  452. package/dist/openapi/models/WorkflowCancelResponse.d.ts +1 -1
  453. package/dist/openapi/models/WorkflowCancelResponse.js +1 -1
  454. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +1 -1
  455. package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +1 -1
  456. package/dist/openapi/models/WorkflowCreateRequest.d.ts +17 -1
  457. package/dist/openapi/models/WorkflowCreateRequest.js +1 -1
  458. package/dist/openapi/models/WorkflowCreateResponse.d.ts +1 -1
  459. package/dist/openapi/models/WorkflowCreateResponse.js +1 -1
  460. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +1 -1
  461. package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +1 -1
  462. package/dist/openapi/models/WorkflowCreditSummary.d.ts +1 -1
  463. package/dist/openapi/models/WorkflowCreditSummary.js +1 -1
  464. package/dist/openapi/models/WorkflowDownloadResponse.d.ts +1 -1
  465. package/dist/openapi/models/WorkflowDownloadResponse.js +1 -1
  466. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +1 -1
  467. package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +1 -1
  468. package/dist/openapi/models/WorkflowEdge.d.ts +1 -1
  469. package/dist/openapi/models/WorkflowEdge.js +1 -1
  470. package/dist/openapi/models/WorkflowExpiredResponse.d.ts +1 -1
  471. package/dist/openapi/models/WorkflowExpiredResponse.js +1 -1
  472. package/dist/openapi/models/WorkflowListResponse.d.ts +1 -1
  473. package/dist/openapi/models/WorkflowListResponse.js +1 -1
  474. package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +1 -1
  475. package/dist/openapi/models/WorkflowListSuccessEnvelope.js +1 -1
  476. package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +1 -1
  477. package/dist/openapi/models/WorkflowPauseRequiredAction.js +1 -1
  478. package/dist/openapi/models/WorkflowPausedDetail.d.ts +1 -1
  479. package/dist/openapi/models/WorkflowPausedDetail.js +1 -1
  480. package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +1 -1
  481. package/dist/openapi/models/WorkflowPausedDetailLinks.js +1 -1
  482. package/dist/openapi/models/WorkflowProcessing.d.ts +1 -1
  483. package/dist/openapi/models/WorkflowProcessing.js +1 -1
  484. package/dist/openapi/models/WorkflowRestoreResponse.d.ts +1 -1
  485. package/dist/openapi/models/WorkflowRestoreResponse.js +1 -1
  486. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.d.ts +1 -1
  487. package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.js +1 -1
  488. package/dist/openapi/models/WorkflowResumeResponse.d.ts +1 -1
  489. package/dist/openapi/models/WorkflowResumeResponse.js +1 -1
  490. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +1 -1
  491. package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +1 -1
  492. package/dist/openapi/models/WorkflowSource.d.ts +1 -1
  493. package/dist/openapi/models/WorkflowSource.js +1 -1
  494. package/dist/openapi/models/WorkflowStatus.d.ts +1 -1
  495. package/dist/openapi/models/WorkflowStatus.js +1 -1
  496. package/dist/openapi/models/WorkflowStatusResponse.d.ts +1 -1
  497. package/dist/openapi/models/WorkflowStatusResponse.js +1 -1
  498. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +1 -1
  499. package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +1 -1
  500. package/dist/openapi/models/WorkflowSummary.d.ts +1 -1
  501. package/dist/openapi/models/WorkflowSummary.js +1 -1
  502. package/dist/openapi/models/WorkflowSummaryJob.d.ts +1 -1
  503. package/dist/openapi/models/WorkflowSummaryJob.js +1 -1
  504. package/dist/openapi/models/WorkflowWarning.d.ts +1 -1
  505. package/dist/openapi/models/WorkflowWarning.js +1 -1
  506. package/dist/openapi/models/WorkflowWarningSeverity.d.ts +1 -1
  507. package/dist/openapi/models/WorkflowWarningSeverity.js +1 -1
  508. package/dist/openapi/runtime.d.ts +1 -1
  509. package/dist/openapi/runtime.js +1 -1
  510. package/dist/operations/audio_to_video.metadata.js +1 -1
  511. package/dist/operations/video_watermark.metadata.js +2 -2
  512. package/openapi/api.yaml +78 -15
  513. package/operation-capabilities/operation-capabilities.json +3 -3
  514. package/operations/schemas/audio_to_video.yaml +1 -1
  515. package/operations/schemas/video_watermark.yaml +2 -2
  516. package/package.json +3 -3
@@ -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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
@@ -164,27 +164,40 @@ export interface CreditTransaction {
164
164
  * non-UUID identifiers and this is NOT constrained to
165
165
  * `UuidV7`.
166
166
  *
167
- * 🔴 **FOR A `top_up` FROM CHECKOUT THIS IS THE CHECKOUT
167
+ * 🔴 **FOR A CREDIT-PACK PURCHASE THIS IS THE CHECKOUT
168
168
  * SESSION ID (`cs_...`) — THE IDENTIFIER THE CLIENT ACTUALLY
169
- * HOLDS.** It is returned as
169
+ * HOLDS**, paired with a `reference_type` of
170
+ * `stripe_checkout_session`. It is returned as
170
171
  * `BillingCheckoutSession.session_id` when the session is
171
172
  * created, and it is the handle that makes the asynchronous
172
173
  * credit grant observable. See `POST /api/billing/checkout`.
173
174
  *
175
+ * 🔴 **THE ROW IS AN `adjustment`, NOT A `top_up`.** Filter on
176
+ * `reference_type` — not on `type` — or the poll described on
177
+ * checkout matches nothing.
178
+ *
179
+ * ⚠️ **Populated only when the provider callback carries a
180
+ * session id.** It is written straight from that callback, so
181
+ * a callback without one leaves both `reference_type` and
182
+ * `reference_id` `null` rather than inventing a correlator.
183
+ * Treat absence as "not correlatable", never as "not granted".
184
+ *
174
185
  * ⚠️ **This description previously named a Stripe PAYMENT
175
186
  * INTENT id.** A client never receives one — checkout returns
176
187
  * `checkout_url` and `session_id` and nothing else — so the
177
188
  * only correlator this contract named was one the caller
178
189
  * could not obtain.
179
190
  *
180
- * 🔴 **NOT YET POPULATED ON THE PACK-PURCHASE PATH.**
181
- * `compression_api` measured 2026-08-28: the pack grant writes
182
- * a free-text description naming the SKU and leaves
183
- * `reference_type` / `reference_id` empty, so **two purchases
184
- * of the same pack are indistinguishable**. Reservations do
185
- * populate them. Until the session id is wired through, a
186
- * `top_up` row carries no correlator and the polling strategy
187
- * described on checkout has nothing to match on.
191
+ * ⚠️ **AND IT THEN SAID THE PACK PATH LEFT THIS FIELD EMPTY
192
+ * "until the session id is wired through".** It is wired:
193
+ * measured on `compression_api` `origin/main` (`8c136261`),
194
+ * `CheckoutSessionCompletedHandler::fulfillPack` passes
195
+ * `referenceType: 'stripe_checkout_session'` and
196
+ * `referenceId: $sessionId`. Both values reach the wire
197
+ * through `GetCreditUsageQueryHandler`. **A stale "not yet"
198
+ * retires a shipped capability and nothing detects it** — the
199
+ * claim reads as caution, and a client that believes it stops
200
+ * looking.
188
201
  *
189
202
  * @type {string}
190
203
  * @memberof CreditTransaction
@@ -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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.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.199.0
7
+ * The version of the OpenAPI document: 2.201.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.199.0
5
+ * The version of the OpenAPI document: 2.201.0
6
6
  *
7
7
  *
8
8
  * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).