@giveitsmaller/contracts 0.73.0 → 0.78.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.
- package/README.md +2 -2
- package/accepted-options/accepted-options.json +1 -1
- package/accepted-options/image-output-routes.json +16 -2
- package/asyncapi/README.md +1 -1
- package/asyncapi/events.yaml +353 -90
- package/availability/availability.json +142 -45
- package/code-builder/code-builder-metadata.json +205 -45
- package/dist/asyncapi/AnonymousSchema_217.d.ts +6 -0
- package/dist/asyncapi/AnonymousSchema_217.js +7 -0
- package/dist/asyncapi/ErrorCode.d.ts +1 -0
- package/dist/asyncapi/ErrorCode.js +1 -0
- package/dist/asyncapi/Failure.d.ts +3 -0
- package/dist/asyncapi/LongFormJobMessage.d.ts +1 -0
- package/dist/asyncapi/MultiOutputCompletion.d.ts +3 -0
- package/dist/asyncapi/OperationMetrics.d.ts +2 -0
- package/dist/asyncapi/SingleOutputCompletion.d.ts +3 -0
- package/dist/asyncapi/UploadProbeMediaMetadata.d.ts +14 -0
- package/dist/asyncapi/index.d.ts +1 -0
- package/dist/asyncapi/index.js +1 -0
- package/dist/openapi/models/AccountLimitEntry.d.ts +2 -2
- package/dist/openapi/models/AccountLimitEntry.js +2 -2
- package/dist/openapi/models/AccountLimits.d.ts +2 -2
- package/dist/openapi/models/AccountLimits.js +2 -2
- package/dist/openapi/models/AccountLimitsLimits.d.ts +14 -2
- package/dist/openapi/models/AccountLimitsLimits.js +6 -2
- package/dist/openapi/models/AccountLimitsSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/AccountLimitsSuccessEnvelope.js +2 -2
- package/dist/openapi/models/AnonymousOperationNotAllowedResponse.d.ts +145 -0
- package/dist/openapi/models/AnonymousOperationNotAllowedResponse.js +82 -0
- package/dist/openapi/models/AnonymousQuotaExhaustedResponse.d.ts +131 -0
- package/dist/openapi/models/AnonymousQuotaExhaustedResponse.js +77 -0
- package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +2 -2
- package/dist/openapi/models/AudioWatermarkDecodeRequest.js +2 -2
- package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +2 -2
- package/dist/openapi/models/AudioWatermarkDecodeResponse.js +2 -2
- package/dist/openapi/models/AuthErrorResponse.d.ts +14 -5
- package/dist/openapi/models/AuthErrorResponse.js +2 -2
- package/dist/openapi/models/AuthErrorType.d.ts +2 -2
- package/dist/openapi/models/AuthErrorType.js +2 -2
- package/dist/openapi/models/AuthRejectionEnvelope.d.ts +2 -2
- package/dist/openapi/models/AuthRejectionEnvelope.js +2 -2
- package/dist/openapi/models/AuthenticatedIdentity.d.ts +2 -2
- package/dist/openapi/models/AuthenticatedIdentity.js +2 -2
- package/dist/openapi/models/AvailabilityValue.d.ts +2 -2
- package/dist/openapi/models/AvailabilityValue.js +2 -2
- package/dist/openapi/models/BalanceExhaustedResponse.d.ts +14 -5
- package/dist/openapi/models/BalanceExhaustedResponse.js +2 -2
- package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +2 -2
- package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +2 -2
- package/dist/openapi/models/BillingCheckoutRequest.d.ts +2 -2
- package/dist/openapi/models/BillingCheckoutRequest.js +2 -2
- package/dist/openapi/models/BillingCheckoutSession.d.ts +2 -2
- package/dist/openapi/models/BillingCheckoutSession.js +2 -2
- package/dist/openapi/models/BillingCheckoutSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/BillingCheckoutSuccessEnvelope.js +2 -2
- package/dist/openapi/models/CallbackEventType.d.ts +2 -2
- package/dist/openapi/models/CallbackEventType.js +2 -2
- package/dist/openapi/models/CancelAccountDeletion200Response.d.ts +2 -2
- package/dist/openapi/models/CancelAccountDeletion200Response.js +2 -2
- package/dist/openapi/models/CancelAccountDeletion200ResponseData.d.ts +2 -2
- package/dist/openapi/models/CancelAccountDeletion200ResponseData.js +2 -2
- package/dist/openapi/models/CapabilityCondition.d.ts +2 -2
- package/dist/openapi/models/CapabilityCondition.js +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf.d.ts +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf.js +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf1.d.ts +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf1.js +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf2.d.ts +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf2.js +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf3.d.ts +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf3.js +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf4.d.ts +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf4.js +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf5.d.ts +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf5.js +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf6.d.ts +2 -2
- package/dist/openapi/models/CapabilityConditionOneOf6.js +2 -2
- package/dist/openapi/models/CapabilityConstraint.d.ts +2 -2
- package/dist/openapi/models/CapabilityConstraint.js +2 -2
- package/dist/openapi/models/CapabilityInputSpec.d.ts +2 -2
- package/dist/openapi/models/CapabilityInputSpec.js +2 -2
- package/dist/openapi/models/CapabilityProduces.d.ts +2 -2
- package/dist/openapi/models/CapabilityProduces.js +2 -2
- package/dist/openapi/models/CapabilityProducesOneOf.d.ts +2 -2
- package/dist/openapi/models/CapabilityProducesOneOf.js +2 -2
- package/dist/openapi/models/CapabilityProducesOneOf1.d.ts +2 -2
- package/dist/openapi/models/CapabilityProducesOneOf1.js +2 -2
- package/dist/openapi/models/CapabilityProducesOneOf2.d.ts +2 -2
- package/dist/openapi/models/CapabilityProducesOneOf2.js +2 -2
- package/dist/openapi/models/ChangePasswordRequest.d.ts +2 -2
- package/dist/openapi/models/ChangePasswordRequest.js +2 -2
- package/dist/openapi/models/CheckoutSessionStatusResponse.d.ts +46 -0
- package/dist/openapi/models/CheckoutSessionStatusResponse.js +54 -0
- package/dist/openapi/models/CheckoutSessionStatusResponseData.d.ts +50 -0
- package/dist/openapi/models/CheckoutSessionStatusResponseData.js +55 -0
- package/dist/openapi/models/CodegenSource.d.ts +5 -4
- package/dist/openapi/models/CodegenSource.js +2 -2
- package/dist/openapi/models/CodegenSourceInput.d.ts +2 -2
- package/dist/openapi/models/CodegenSourceInput.js +2 -2
- package/dist/openapi/models/CodegenSourceJob.d.ts +2 -2
- package/dist/openapi/models/CodegenSourceJob.js +2 -2
- package/dist/openapi/models/CodegenSourceJobSource.d.ts +2 -2
- package/dist/openapi/models/CodegenSourceJobSource.js +2 -2
- package/dist/openapi/models/CodegenSourceOperation.d.ts +2 -2
- package/dist/openapi/models/CodegenSourceOperation.js +2 -2
- package/dist/openapi/models/CodegenUploadPlaceholder.d.ts +2 -2
- package/dist/openapi/models/CodegenUploadPlaceholder.js +2 -2
- package/dist/openapi/models/CompositionPlan.d.ts +2 -2
- package/dist/openapi/models/CompositionPlan.js +2 -2
- package/dist/openapi/models/CompositionPlanJob.d.ts +2 -2
- package/dist/openapi/models/CompositionPlanJob.js +2 -2
- package/dist/openapi/models/CompositionPlanOperation.d.ts +2 -2
- package/dist/openapi/models/CompositionPlanOperation.js +2 -2
- package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +2 -2
- package/dist/openapi/models/ConfirmEmailChange200Response.js +2 -2
- package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +2 -2
- package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +2 -2
- package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +2 -2
- package/dist/openapi/models/ConfirmEmailChangeRequest.js +2 -2
- package/dist/openapi/models/ConnectionSource.d.ts +2 -2
- package/dist/openapi/models/ConnectionSource.js +2 -2
- package/dist/openapi/models/ContactRequest.d.ts +2 -2
- package/dist/openapi/models/ContactRequest.js +2 -2
- package/dist/openapi/models/ContactSubject.d.ts +2 -2
- package/dist/openapi/models/ContactSubject.js +2 -2
- package/dist/openapi/models/ContactValidationErrorResponse.d.ts +2 -2
- package/dist/openapi/models/ContactValidationErrorResponse.js +2 -2
- package/dist/openapi/models/CreateApiKey201Response.d.ts +2 -2
- package/dist/openapi/models/CreateApiKey201Response.js +2 -2
- package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +2 -2
- package/dist/openapi/models/CreateApiKey201ResponseData.js +2 -2
- package/dist/openapi/models/CreateApiKeyRequest.d.ts +2 -2
- package/dist/openapi/models/CreateApiKeyRequest.js +2 -2
- package/dist/openapi/models/CreateBillingCheckoutSession422Response.d.ts +2 -2
- package/dist/openapi/models/CreateBillingCheckoutSession422Response.js +2 -2
- package/dist/openapi/models/CreateExternalImport403Response.d.ts +2 -2
- package/dist/openapi/models/CreateExternalImport403Response.js +2 -2
- package/dist/openapi/models/CreateExternalImport422Response.d.ts +2 -2
- package/dist/openapi/models/CreateExternalImport422Response.js +2 -2
- package/dist/openapi/models/CreateWorkflow401Response.d.ts +14 -5
- package/dist/openapi/models/CreateWorkflow401Response.js +2 -2
- package/dist/openapi/models/CreateWorkflow403Response.d.ts +33 -0
- package/dist/openapi/models/CreateWorkflow403Response.js +57 -0
- package/dist/openapi/models/CreateWorkflow422Response.d.ts +2 -2
- package/dist/openapi/models/CreateWorkflow422Response.js +2 -2
- package/dist/openapi/models/CreditTransaction.d.ts +22 -12
- package/dist/openapi/models/CreditTransaction.js +2 -2
- package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +2 -2
- package/dist/openapi/models/CreditTransactionSourceBucket.js +2 -2
- package/dist/openapi/models/CreditsBalanceResponse.d.ts +2 -2
- package/dist/openapi/models/CreditsBalanceResponse.js +2 -2
- package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +2 -2
- package/dist/openapi/models/CreditsUsageResponse.d.ts +2 -2
- package/dist/openapi/models/CreditsUsageResponse.js +2 -2
- package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +2 -2
- package/dist/openapi/models/Delivery.d.ts +2 -2
- package/dist/openapi/models/Delivery.js +2 -2
- package/dist/openapi/models/DeliveryOutputRef.d.ts +2 -2
- package/dist/openapi/models/DeliveryOutputRef.js +2 -2
- package/dist/openapi/models/DeliveryPlan.d.ts +2 -2
- package/dist/openapi/models/DeliveryPlan.js +2 -2
- package/dist/openapi/models/DeliveryPlanOutput.d.ts +2 -2
- package/dist/openapi/models/DeliveryPlanOutput.js +2 -2
- package/dist/openapi/models/DeliveryPlanReason.d.ts +2 -2
- package/dist/openapi/models/DeliveryPlanReason.js +2 -2
- package/dist/openapi/models/DeliverySelection.d.ts +2 -2
- package/dist/openapi/models/DeliverySelection.js +2 -2
- package/dist/openapi/models/DownloadBundle.d.ts +2 -2
- package/dist/openapi/models/DownloadBundle.js +2 -2
- package/dist/openapi/models/DroppedOption.d.ts +2 -2
- package/dist/openapi/models/DroppedOption.js +2 -2
- package/dist/openapi/models/EmailNotify.d.ts +2 -2
- package/dist/openapi/models/EmailNotify.js +2 -2
- package/dist/openapi/models/EmptySuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/EmptySuccessEnvelope.js +2 -2
- package/dist/openapi/models/EndpointProjection.d.ts +2 -2
- package/dist/openapi/models/EndpointProjection.js +2 -2
- package/dist/openapi/models/EndpointProjectionServersInner.d.ts +2 -2
- package/dist/openapi/models/EndpointProjectionServersInner.js +2 -2
- package/dist/openapi/models/ErrorEnvelope.d.ts +14 -5
- package/dist/openapi/models/ErrorEnvelope.js +2 -2
- package/dist/openapi/models/EstimateQuality.d.ts +2 -2
- package/dist/openapi/models/EstimateQuality.js +2 -2
- package/dist/openapi/models/EstimateRange.d.ts +2 -2
- package/dist/openapi/models/EstimateRange.js +2 -2
- package/dist/openapi/models/ExportAccountData200Response.d.ts +2 -2
- package/dist/openapi/models/ExportAccountData200Response.js +2 -2
- package/dist/openapi/models/ExportAccountData200ResponseData.d.ts +5 -4
- package/dist/openapi/models/ExportAccountData200ResponseData.js +5 -4
- package/dist/openapi/models/ExportAccountData200ResponseDataBilling.d.ts +36 -0
- package/dist/openapi/models/ExportAccountData200ResponseDataBilling.js +42 -0
- package/dist/openapi/models/ExportAccountData200ResponseDataBillingCheckoutSessionsInner.d.ts +58 -0
- package/dist/openapi/models/ExportAccountData200ResponseDataBillingCheckoutSessionsInner.js +62 -0
- package/dist/openapi/models/ExternalDestination.d.ts +2 -2
- package/dist/openapi/models/ExternalDestination.js +2 -2
- package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +2 -2
- package/dist/openapi/models/ExternalImportCreatedResponse.js +2 -2
- package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +2 -2
- package/dist/openapi/models/ExternalImportRequest.d.ts +2 -2
- package/dist/openapi/models/ExternalImportRequest.js +2 -2
- package/dist/openapi/models/ExternalImportToken.d.ts +2 -2
- package/dist/openapi/models/ExternalImportToken.js +2 -2
- package/dist/openapi/models/ExternalSource.d.ts +2 -2
- package/dist/openapi/models/ExternalSource.js +2 -2
- package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +14 -5
- package/dist/openapi/models/FeatureNotAvailableResponse.js +2 -2
- package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +14 -5
- package/dist/openapi/models/FeatureTierRestrictedResponse.js +2 -2
- package/dist/openapi/models/FeatureViolation.d.ts +2 -2
- package/dist/openapi/models/FeatureViolation.js +2 -2
- package/dist/openapi/models/GetProfile200Response.d.ts +2 -2
- package/dist/openapi/models/GetProfile200Response.js +2 -2
- package/dist/openapi/models/GetProfile200ResponseData.d.ts +2 -2
- package/dist/openapi/models/GetProfile200ResponseData.js +2 -2
- package/dist/openapi/models/ImageEncodeCapabilities.d.ts +2 -2
- package/dist/openapi/models/ImageEncodeCapabilities.js +2 -2
- package/dist/openapi/models/JobDefinition.d.ts +2 -2
- package/dist/openapi/models/JobDefinition.js +2 -2
- package/dist/openapi/models/JobDownload.d.ts +2 -2
- package/dist/openapi/models/JobDownload.js +2 -2
- package/dist/openapi/models/JobInputV2.d.ts +2 -2
- package/dist/openapi/models/JobInputV2.js +2 -2
- package/dist/openapi/models/JobMediaClass.d.ts +2 -2
- package/dist/openapi/models/JobMediaClass.js +2 -2
- package/dist/openapi/models/JobOutputSource.d.ts +2 -2
- package/dist/openapi/models/JobOutputSource.js +2 -2
- package/dist/openapi/models/JobResponse.d.ts +2 -2
- package/dist/openapi/models/JobResponse.js +2 -2
- package/dist/openapi/models/JobStatus.d.ts +2 -2
- package/dist/openapi/models/JobStatus.js +2 -2
- package/dist/openapi/models/JobType.d.ts +2 -2
- package/dist/openapi/models/JobType.js +2 -2
- package/dist/openapi/models/LivenessResponse.d.ts +2 -2
- package/dist/openapi/models/LivenessResponse.js +2 -2
- package/dist/openapi/models/LoginUser200Response.d.ts +2 -2
- package/dist/openapi/models/LoginUser200Response.js +2 -2
- package/dist/openapi/models/LoginUser200ResponseData.d.ts +2 -2
- package/dist/openapi/models/LoginUser200ResponseData.js +2 -2
- package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +2 -2
- package/dist/openapi/models/LoginUser200ResponseDataUser.js +2 -2
- package/dist/openapi/models/LoginUser401Response.d.ts +14 -5
- package/dist/openapi/models/LoginUser401Response.js +2 -2
- package/dist/openapi/models/LoginUserRequest.d.ts +2 -2
- package/dist/openapi/models/LoginUserRequest.js +2 -2
- package/dist/openapi/models/LongFormConcurrencyLimitResponse.d.ts +14 -5
- package/dist/openapi/models/LongFormConcurrencyLimitResponse.js +2 -2
- package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.d.ts +2 -2
- package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.js +2 -2
- package/dist/openapi/models/MetadataResponse.d.ts +2 -2
- package/dist/openapi/models/MetadataResponse.js +2 -2
- package/dist/openapi/models/MetadataResponseDimensions.d.ts +2 -2
- package/dist/openapi/models/MetadataResponseDimensions.js +2 -2
- package/dist/openapi/models/MetadataResponseExif.d.ts +2 -2
- package/dist/openapi/models/MetadataResponseExif.js +2 -2
- package/dist/openapi/models/MetadataResponseExifGps.d.ts +2 -2
- package/dist/openapi/models/MetadataResponseExifGps.js +2 -2
- package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/MetadataSuccessEnvelope.js +2 -2
- package/dist/openapi/models/MimeGroupSchema.d.ts +39 -3
- package/dist/openapi/models/MimeGroupSchema.js +12 -2
- package/dist/openapi/models/MultiInputSource.d.ts +2 -2
- package/dist/openapi/models/MultiInputSource.js +2 -2
- package/dist/openapi/models/MultipartCompleteRequest.d.ts +2 -2
- package/dist/openapi/models/MultipartCompleteRequest.js +2 -2
- package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +2 -2
- package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +2 -2
- package/dist/openapi/models/MultipartCompleteResponse.d.ts +2 -2
- package/dist/openapi/models/MultipartCompleteResponse.js +2 -2
- package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +2 -2
- package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +2 -2
- package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +2 -2
- package/dist/openapi/models/MultipartInitiateResponse.d.ts +2 -2
- package/dist/openapi/models/MultipartInitiateResponse.js +2 -2
- package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +2 -2
- package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +2 -2
- package/dist/openapi/models/MultipartKeepaliveResponse.js +2 -2
- package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +2 -2
- package/dist/openapi/models/MultipartPartListing.d.ts +2 -2
- package/dist/openapi/models/MultipartPartListing.js +2 -2
- package/dist/openapi/models/MultipartPresignRequest.d.ts +2 -2
- package/dist/openapi/models/MultipartPresignRequest.js +2 -2
- package/dist/openapi/models/MultipartPresignResponse.d.ts +2 -2
- package/dist/openapi/models/MultipartPresignResponse.js +2 -2
- package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +2 -2
- package/dist/openapi/models/MultipartStatusResponse.d.ts +2 -2
- package/dist/openapi/models/MultipartStatusResponse.js +2 -2
- package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +2 -2
- package/dist/openapi/models/NotifyConfig.d.ts +9 -5
- package/dist/openapi/models/NotifyConfig.js +2 -2
- package/dist/openapi/models/OperationCapability.d.ts +2 -2
- package/dist/openapi/models/OperationCapability.js +2 -2
- package/dist/openapi/models/OperationDefinition.d.ts +2 -2
- package/dist/openapi/models/OperationDefinition.js +2 -2
- package/dist/openapi/models/OperationDownload.d.ts +6 -2
- package/dist/openapi/models/OperationDownload.js +2 -2
- package/dist/openapi/models/OperationInputModel.d.ts +2 -2
- package/dist/openapi/models/OperationInputModel.js +2 -2
- package/dist/openapi/models/OperationMessageParamsValue.d.ts +25 -0
- package/dist/openapi/models/OperationMessageParamsValue.js +31 -0
- package/dist/openapi/models/OperationResponse.d.ts +36 -2
- package/dist/openapi/models/OperationResponse.js +8 -2
- package/dist/openapi/models/OperationResult.d.ts +2 -2
- package/dist/openapi/models/OperationResult.js +2 -2
- package/dist/openapi/models/OperationResultMetadata.d.ts +29 -3
- package/dist/openapi/models/OperationResultMetadata.js +6 -2
- package/dist/openapi/models/OperationResultMetrics.d.ts +4 -4
- package/dist/openapi/models/OperationResultMetrics.js +2 -2
- package/dist/openapi/models/OperationSchemaDefinition.d.ts +5 -6
- package/dist/openapi/models/OperationSchemaDefinition.js +2 -2
- package/dist/openapi/models/OperationStatus.d.ts +2 -2
- package/dist/openapi/models/OperationStatus.js +2 -2
- package/dist/openapi/models/OperationType.d.ts +10 -4
- package/dist/openapi/models/OperationType.js +10 -4
- package/dist/openapi/models/OperationsSchemaResponse.d.ts +2 -2
- package/dist/openapi/models/OperationsSchemaResponse.js +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.d.ts +2 -2
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.js +2 -2
- package/dist/openapi/models/OptionSchema.d.ts +40 -3
- package/dist/openapi/models/OptionSchema.js +10 -2
- package/dist/openapi/models/OutputProperties.d.ts +2 -2
- package/dist/openapi/models/OutputProperties.js +2 -2
- package/dist/openapi/models/OutputPropertiesIsAnimated.d.ts +2 -2
- package/dist/openapi/models/OutputPropertiesIsAnimated.js +2 -2
- package/dist/openapi/models/PerClassAvailabilityEntry.d.ts +2 -2
- package/dist/openapi/models/PerClassAvailabilityEntry.js +2 -2
- package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +2 -2
- package/dist/openapi/models/PerRoleCardinalityEntry.js +2 -2
- package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +2 -2
- package/dist/openapi/models/PerValueAvailabilityEntry.js +2 -2
- package/dist/openapi/models/PresignedUrlPart.d.ts +2 -2
- package/dist/openapi/models/PresignedUrlPart.js +2 -2
- package/dist/openapi/models/ProbePendingResponse.d.ts +14 -5
- package/dist/openapi/models/ProbePendingResponse.js +2 -2
- package/dist/openapi/models/ProcessingClass.d.ts +2 -2
- package/dist/openapi/models/ProcessingClass.js +2 -2
- package/dist/openapi/models/ProcessingClassBandViolation.d.ts +13 -2
- package/dist/openapi/models/ProcessingClassBandViolation.js +5 -2
- package/dist/openapi/models/ProcessingClassConstraints.d.ts +2 -2
- package/dist/openapi/models/ProcessingClassConstraints.js +2 -2
- package/dist/openapi/models/ProcessingClassEntry.d.ts +16 -2
- package/dist/openapi/models/ProcessingClassEntry.js +8 -2
- package/dist/openapi/models/ProcessingClassEntryInputUniformity.d.ts +65 -0
- package/dist/openapi/models/ProcessingClassEntryInputUniformity.js +57 -0
- package/dist/openapi/models/ProcessingClassEntryResolutionBands.d.ts +66 -0
- package/dist/openapi/models/ProcessingClassEntryResolutionBands.js +56 -0
- package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +14 -5
- package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +2 -2
- package/dist/openapi/models/ProcessingClassHint.d.ts +2 -2
- package/dist/openapi/models/ProcessingClassHint.js +2 -2
- package/dist/openapi/models/ProcessingClassReason.d.ts +2 -2
- package/dist/openapi/models/ProcessingClassReason.js +2 -2
- package/dist/openapi/models/ProcessingClassRejectReason.d.ts +2 -2
- package/dist/openapi/models/ProcessingClassRejectReason.js +2 -2
- package/dist/openapi/models/ProcessingPlan.d.ts +2 -2
- package/dist/openapi/models/ProcessingPlan.js +2 -2
- package/dist/openapi/models/ProcessingPlanJob.d.ts +15 -2
- package/dist/openapi/models/ProcessingPlanJob.js +5 -2
- package/dist/openapi/models/ReEncodeDecision.d.ts +19 -8
- package/dist/openapi/models/ReEncodeDecision.js +19 -8
- package/dist/openapi/models/ReadinessResponse.d.ts +2 -2
- package/dist/openapi/models/ReadinessResponse.js +2 -2
- package/dist/openapi/models/RegisterUser422Response.d.ts +2 -2
- package/dist/openapi/models/RegisterUser422Response.js +2 -2
- package/dist/openapi/models/RegisterUserRequest.d.ts +2 -2
- package/dist/openapi/models/RegisterUserRequest.js +2 -2
- package/dist/openapi/models/RequestAccountDeletion200Response.d.ts +2 -2
- package/dist/openapi/models/RequestAccountDeletion200Response.js +2 -2
- package/dist/openapi/models/RequestAccountDeletion200ResponseData.d.ts +2 -2
- package/dist/openapi/models/RequestAccountDeletion200ResponseData.js +2 -2
- package/dist/openapi/models/RequestAccountDeletionRequest.d.ts +2 -2
- package/dist/openapi/models/RequestAccountDeletionRequest.js +2 -2
- package/dist/openapi/models/ResendVerificationEmailRequest.d.ts +2 -2
- package/dist/openapi/models/ResendVerificationEmailRequest.js +2 -2
- package/dist/openapi/models/ResetPasswordRequest.d.ts +2 -2
- package/dist/openapi/models/ResetPasswordRequest.js +2 -2
- package/dist/openapi/models/ResolutionBand.d.ts +44 -0
- package/dist/openapi/models/ResolutionBand.js +62 -0
- package/dist/openapi/models/ResolutionBandCeiling.d.ts +68 -0
- package/dist/openapi/models/ResolutionBandCeiling.js +57 -0
- package/dist/openapi/models/ResolutionBandCeilingConstraints.d.ts +32 -0
- package/dist/openapi/models/ResolutionBandCeilingConstraints.js +41 -0
- package/dist/openapi/models/ResolutionBandCeilingDerivation.d.ts +48 -0
- package/dist/openapi/models/ResolutionBandCeilingDerivation.js +51 -0
- package/dist/openapi/models/ResponseEnvelope.d.ts +2 -2
- package/dist/openapi/models/ResponseEnvelope.js +2 -2
- package/dist/openapi/models/RetryResponse.d.ts +2 -2
- package/dist/openapi/models/RetryResponse.js +2 -2
- package/dist/openapi/models/RetrySuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/RetrySuccessEnvelope.js +2 -2
- package/dist/openapi/models/SseCompletionBase.d.ts +2 -2
- package/dist/openapi/models/SseCompletionBase.js +2 -2
- package/dist/openapi/models/SseConnectionLimitResponse.d.ts +14 -5
- package/dist/openapi/models/SseConnectionLimitResponse.js +2 -2
- package/dist/openapi/models/SseEventType.d.ts +2 -2
- package/dist/openapi/models/SseEventType.js +2 -2
- package/dist/openapi/models/SseJobCompletedData.d.ts +2 -2
- package/dist/openapi/models/SseJobCompletedData.js +2 -2
- package/dist/openapi/models/SseJobFailedData.d.ts +2 -2
- package/dist/openapi/models/SseJobFailedData.js +2 -2
- package/dist/openapi/models/SseMultiOutputCompletion.d.ts +2 -2
- package/dist/openapi/models/SseMultiOutputCompletion.js +2 -2
- package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +2 -2
- package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +2 -2
- package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +2 -2
- package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +2 -2
- package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +6 -2
- package/dist/openapi/models/SseMultiOutputResultEntry.js +2 -2
- package/dist/openapi/models/SseOperationCompletedData.d.ts +2 -2
- package/dist/openapi/models/SseOperationCompletedData.js +2 -2
- package/dist/openapi/models/SseOperationCompletionResult.d.ts +2 -2
- package/dist/openapi/models/SseOperationCompletionResult.js +2 -2
- package/dist/openapi/models/SseOperationFailedData.d.ts +33 -2
- package/dist/openapi/models/SseOperationFailedData.js +8 -2
- package/dist/openapi/models/SseOperationProgressData.d.ts +2 -2
- package/dist/openapi/models/SseOperationProgressData.js +2 -2
- package/dist/openapi/models/SseSingleOutputCompletion.d.ts +2 -2
- package/dist/openapi/models/SseSingleOutputCompletion.js +2 -2
- package/dist/openapi/models/SseWorkflowTerminalData.d.ts +2 -2
- package/dist/openapi/models/SseWorkflowTerminalData.js +2 -2
- package/dist/openapi/models/TierRestrictionKind.d.ts +2 -2
- package/dist/openapi/models/TierRestrictionKind.js +2 -2
- package/dist/openapi/models/TierRestrictionResponse.d.ts +14 -5
- package/dist/openapi/models/TierRestrictionResponse.js +2 -2
- package/dist/openapi/models/UpdateProfile200Response.d.ts +2 -2
- package/dist/openapi/models/UpdateProfile200Response.js +2 -2
- package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +2 -2
- package/dist/openapi/models/UpdateProfile200ResponseData.js +2 -2
- package/dist/openapi/models/UpdateProfile422Response.d.ts +2 -2
- package/dist/openapi/models/UpdateProfile422Response.js +2 -2
- package/dist/openapi/models/UpdateProfileRequest.d.ts +2 -2
- package/dist/openapi/models/UpdateProfileRequest.js +2 -2
- package/dist/openapi/models/UploadConstraintsApplied.d.ts +2 -2
- package/dist/openapi/models/UploadConstraintsApplied.js +2 -2
- package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +14 -5
- package/dist/openapi/models/UploadDurationExceedsTierResponse.js +2 -2
- package/dist/openapi/models/UploadFile403Response.d.ts +2 -2
- package/dist/openapi/models/UploadFile403Response.js +2 -2
- package/dist/openapi/models/UploadFile422Response.d.ts +2 -2
- package/dist/openapi/models/UploadFile422Response.js +2 -2
- package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +107 -2
- package/dist/openapi/models/UploadProbeMediaMetadata.js +36 -2
- package/dist/openapi/models/UploadProbeProcessingClass.d.ts +4 -6
- package/dist/openapi/models/UploadProbeProcessingClass.js +4 -6
- package/dist/openapi/models/UploadProbeResponse.d.ts +2 -2
- package/dist/openapi/models/UploadProbeResponse.js +2 -2
- package/dist/openapi/models/UploadProbeStatus.d.ts +2 -2
- package/dist/openapi/models/UploadProbeStatus.js +2 -2
- package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/UploadProbeSuccessEnvelope.js +2 -2
- package/dist/openapi/models/UploadResponse.d.ts +2 -2
- package/dist/openapi/models/UploadResponse.js +2 -2
- package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +14 -5
- package/dist/openapi/models/UploadSizeExceedsTierResponse.js +2 -2
- package/dist/openapi/models/UploadSource.d.ts +2 -2
- package/dist/openapi/models/UploadSource.js +2 -2
- package/dist/openapi/models/UploadSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/UploadSuccessEnvelope.js +2 -2
- package/dist/openapi/models/UploadThresholds.d.ts +2 -2
- package/dist/openapi/models/UploadThresholds.js +2 -2
- package/dist/openapi/models/UserTier.d.ts +2 -2
- package/dist/openapi/models/UserTier.js +2 -2
- package/dist/openapi/models/ValidationErrorEnvelope.d.ts +19 -8
- package/dist/openapi/models/ValidationErrorEnvelope.js +2 -2
- package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +2 -2
- package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +2 -2
- package/dist/openapi/models/VerifyEmailRequest.d.ts +2 -2
- package/dist/openapi/models/VerifyEmailRequest.js +2 -2
- package/dist/openapi/models/WarningType.d.ts +2 -2
- package/dist/openapi/models/WarningType.js +2 -2
- package/dist/openapi/models/WebhookOperationContext.d.ts +2 -2
- package/dist/openapi/models/WebhookOperationContext.js +2 -2
- package/dist/openapi/models/WebhookPayload.d.ts +2 -2
- package/dist/openapi/models/WebhookPayload.js +2 -2
- package/dist/openapi/models/WorkflowArchiveResponse.d.ts +2 -2
- package/dist/openapi/models/WorkflowArchiveResponse.js +2 -2
- package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.js +2 -2
- package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +7 -6
- package/dist/openapi/models/WorkflowCancelBillingEffect.js +7 -6
- package/dist/openapi/models/WorkflowCancelResponse.d.ts +2 -2
- package/dist/openapi/models/WorkflowCancelResponse.js +2 -2
- package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +2 -2
- package/dist/openapi/models/WorkflowCreateRequest.d.ts +11 -14
- package/dist/openapi/models/WorkflowCreateRequest.js +2 -2
- package/dist/openapi/models/WorkflowCreateResponse.d.ts +2 -2
- package/dist/openapi/models/WorkflowCreateResponse.js +2 -2
- package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +2 -2
- package/dist/openapi/models/WorkflowCreditSummary.d.ts +2 -2
- package/dist/openapi/models/WorkflowCreditSummary.js +2 -2
- package/dist/openapi/models/WorkflowDownloadResponse.d.ts +2 -2
- package/dist/openapi/models/WorkflowDownloadResponse.js +2 -2
- package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +2 -2
- package/dist/openapi/models/WorkflowEdge.d.ts +2 -2
- package/dist/openapi/models/WorkflowEdge.js +2 -2
- package/dist/openapi/models/WorkflowExpiredResponse.d.ts +14 -5
- package/dist/openapi/models/WorkflowExpiredResponse.js +2 -2
- package/dist/openapi/models/WorkflowListResponse.d.ts +2 -2
- package/dist/openapi/models/WorkflowListResponse.js +2 -2
- package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/WorkflowListSuccessEnvelope.js +2 -2
- package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +18 -6
- package/dist/openapi/models/WorkflowPauseRequiredAction.js +19 -7
- package/dist/openapi/models/WorkflowPausedDetail.d.ts +6 -5
- package/dist/openapi/models/WorkflowPausedDetail.js +2 -2
- package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +7 -5
- package/dist/openapi/models/WorkflowPausedDetailLinks.js +2 -2
- package/dist/openapi/models/WorkflowProcessing.d.ts +2 -2
- package/dist/openapi/models/WorkflowProcessing.js +2 -2
- package/dist/openapi/models/WorkflowRestoreResponse.d.ts +2 -2
- package/dist/openapi/models/WorkflowRestoreResponse.js +2 -2
- package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.js +2 -2
- package/dist/openapi/models/WorkflowResumeResponse.d.ts +2 -2
- package/dist/openapi/models/WorkflowResumeResponse.js +2 -2
- package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +2 -2
- package/dist/openapi/models/WorkflowSource.d.ts +2 -2
- package/dist/openapi/models/WorkflowSource.js +2 -2
- package/dist/openapi/models/WorkflowStatus.d.ts +10 -5
- package/dist/openapi/models/WorkflowStatus.js +10 -5
- package/dist/openapi/models/WorkflowStatusResponse.d.ts +5 -3
- package/dist/openapi/models/WorkflowStatusResponse.js +2 -2
- package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +2 -2
- package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +2 -2
- package/dist/openapi/models/WorkflowSummary.d.ts +2 -2
- package/dist/openapi/models/WorkflowSummary.js +2 -2
- package/dist/openapi/models/WorkflowSummaryJob.d.ts +2 -2
- package/dist/openapi/models/WorkflowSummaryJob.js +2 -2
- package/dist/openapi/models/WorkflowWarning.d.ts +2 -2
- package/dist/openapi/models/WorkflowWarning.js +2 -2
- package/dist/openapi/models/WorkflowWarningSeverity.d.ts +2 -2
- package/dist/openapi/models/WorkflowWarningSeverity.js +2 -2
- package/dist/openapi/models/index.d.ts +14 -0
- package/dist/openapi/models/index.js +14 -0
- package/dist/openapi/runtime.d.ts +2 -2
- package/dist/openapi/runtime.js +2 -2
- package/dist/operations/archive.metadata.js +1 -0
- package/dist/operations/audio_overlay.metadata.js +1 -0
- package/dist/operations/audio_to_video.metadata.js +1 -0
- package/dist/operations/audio_watermark.metadata.js +4 -9
- package/dist/operations/custom_luma.metadata.js +1 -0
- package/dist/operations/image_watermark.metadata.js +1 -0
- package/dist/operations/merge.metadata.js +1 -0
- package/dist/operations/metadata-types.d.ts +2 -0
- package/dist/operations/split.metadata.js +12 -3
- package/dist/operations/text_watermark.metadata.js +1 -0
- package/dist/operations/video_text_watermark.metadata.js +2 -0
- package/dist/operations/video_watermark.metadata.js +1 -0
- package/openapi/README.md +1 -1
- package/openapi/api.yaml +1089 -172
- package/operation-capabilities/operation-capabilities.json +129 -1
- package/operations/schemas/audio_watermark.yaml +34 -33
- package/operations/schemas/compress.yaml +295 -177
- package/operations/schemas/convert.yaml +11 -0
- package/operations/schemas/merge.yaml +35 -1
- package/operations/schemas/split.yaml +144 -88
- package/operations/schemas/thumbnail.yaml +34 -26
- package/operations/schemas/video_text_watermark.yaml +112 -47
- package/operations/schemas/video_watermark.yaml +33 -28
- package/package.json +3 -3
|
@@ -2,19 +2,21 @@
|
|
|
2
2
|
/* eslint-disable */
|
|
3
3
|
/**
|
|
4
4
|
* GISL Compression API
|
|
5
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
5
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
7
|
+
* The version of the OpenAPI document: 2.213.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
11
11
|
* https://openapi-generator.tech
|
|
12
12
|
* Do not edit the class manually.
|
|
13
13
|
*/
|
|
14
|
+
import { mapValues } from '../runtime.js';
|
|
14
15
|
import { OperationStatusFromJSON, OperationStatusToJSON, } from './OperationStatus.js';
|
|
15
16
|
import { OperationResultMetadataFromJSON, OperationResultMetadataToJSON, } from './OperationResultMetadata.js';
|
|
16
17
|
import { OperationResultFromJSON, OperationResultToJSON, } from './OperationResult.js';
|
|
17
18
|
import { OperationTypeFromJSON, OperationTypeToJSON, } from './OperationType.js';
|
|
19
|
+
import { OperationMessageParamsValueFromJSON, OperationMessageParamsValueToJSON, } from './OperationMessageParamsValue.js';
|
|
18
20
|
/**
|
|
19
21
|
* Check if a given object implements the OperationResponse interface.
|
|
20
22
|
*/
|
|
@@ -43,6 +45,8 @@ export function OperationResponseFromJSONTyped(json, ignoreDiscriminator) {
|
|
|
43
45
|
'resultMetadata': json['result_metadata'] == null ? undefined : OperationResultMetadataFromJSON(json['result_metadata']),
|
|
44
46
|
'errorCode': json['error_code'] == null ? undefined : json['error_code'],
|
|
45
47
|
'errorMessage': json['error_message'] == null ? undefined : json['error_message'],
|
|
48
|
+
'messageKey': json['message_key'] == null ? undefined : json['message_key'],
|
|
49
|
+
'messageParams': json['message_params'] == null ? undefined : (mapValues(json['message_params'], OperationMessageParamsValueFromJSON)),
|
|
46
50
|
};
|
|
47
51
|
}
|
|
48
52
|
export function OperationResponseToJSON(json) {
|
|
@@ -61,5 +65,7 @@ export function OperationResponseToJSONTyped(value, ignoreDiscriminator = false)
|
|
|
61
65
|
'result_metadata': OperationResultMetadataToJSON(value['resultMetadata']),
|
|
62
66
|
'error_code': value['errorCode'],
|
|
63
67
|
'error_message': value['errorMessage'],
|
|
68
|
+
'message_key': value['messageKey'],
|
|
69
|
+
'message_params': value['messageParams'] == null ? undefined : (mapValues(value['messageParams'], OperationMessageParamsValueToJSON)),
|
|
64
70
|
};
|
|
65
71
|
}
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
/**
|
|
2
2
|
* GISL Compression API
|
|
3
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
3
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
5
|
+
* The version of the OpenAPI document: 2.213.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
/* eslint-disable */
|
|
3
3
|
/**
|
|
4
4
|
* GISL Compression API
|
|
5
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
5
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
7
|
+
* The version of the OpenAPI document: 2.213.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
/**
|
|
2
2
|
* GISL Compression API
|
|
3
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
3
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
5
|
+
* The version of the OpenAPI document: 2.213.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -16,7 +16,9 @@
|
|
|
16
16
|
* diagnostics never leak. New keys are **additive named cuts** (the
|
|
17
17
|
* `additionalProperties: false` closure is the point — an unmodelled
|
|
18
18
|
* key is a coordinated contract change, not a silent rollout). Twin of
|
|
19
|
-
* the AsyncAPI `OperationResultMetadata` (wire ↔ read parity)
|
|
19
|
+
* the AsyncAPI `OperationResultMetadata` (wire ↔ read parity), except
|
|
20
|
+
* `already_optimal` / `estimated_saving_pct`, which the API projects
|
|
21
|
+
* from the wire `OperationMetrics` where the worker emits them. Distinct
|
|
20
22
|
* from `OperationResult` (the deliverable output file): this carries
|
|
21
23
|
* small per-operation metadata, not the output. Per `EurbZLMH` (B1).
|
|
22
24
|
*
|
|
@@ -37,6 +39,30 @@ export interface OperationResultMetadata {
|
|
|
37
39
|
* @memberof OperationResultMetadata
|
|
38
40
|
*/
|
|
39
41
|
watermarkId?: string;
|
|
42
|
+
/**
|
|
43
|
+
* `true` when the operation completed by returning the ORIGINAL file
|
|
44
|
+
* unchanged, because compressing it would not have made it smaller
|
|
45
|
+
* (or the source was already efficiently encoded). The operation is
|
|
46
|
+
* a success, not a failure: `result` is the original. Show it as
|
|
47
|
+
* "already optimised", not as "same size". On an ordinary result it
|
|
48
|
+
* is absent or `false`; treat the two the same. Projected by the API from the wire
|
|
49
|
+
* `OperationMetrics.already_optimal` (ticket `roNRMilt`).
|
|
50
|
+
*
|
|
51
|
+
* @type {boolean}
|
|
52
|
+
* @memberof OperationResultMetadata
|
|
53
|
+
*/
|
|
54
|
+
alreadyOptimal?: boolean;
|
|
55
|
+
/**
|
|
56
|
+
* OPTIONAL, only with `already_optimal: true`: the worker's ESTIMATE
|
|
57
|
+
* of how much smaller, as a percentage of the input size, a re-encode
|
|
58
|
+
* would have made the file, when it declined before encoding. Absent
|
|
59
|
+
* when no estimate was made. An estimate, not a guarantee. Projected
|
|
60
|
+
* from the wire `OperationMetrics.estimated_saving_pct`.
|
|
61
|
+
*
|
|
62
|
+
* @type {number}
|
|
63
|
+
* @memberof OperationResultMetadata
|
|
64
|
+
*/
|
|
65
|
+
estimatedSavingPct?: number;
|
|
40
66
|
}
|
|
41
67
|
/**
|
|
42
68
|
* Check if a given object implements the OperationResultMetadata interface.
|
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
/* eslint-disable */
|
|
3
3
|
/**
|
|
4
4
|
* GISL Compression API
|
|
5
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
5
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
7
|
+
* The version of the OpenAPI document: 2.213.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -26,6 +26,8 @@ export function OperationResultMetadataFromJSONTyped(json, ignoreDiscriminator)
|
|
|
26
26
|
}
|
|
27
27
|
return {
|
|
28
28
|
'watermarkId': json['watermark_id'] == null ? undefined : json['watermark_id'],
|
|
29
|
+
'alreadyOptimal': json['already_optimal'] == null ? undefined : json['already_optimal'],
|
|
30
|
+
'estimatedSavingPct': json['estimated_saving_pct'] == null ? undefined : json['estimated_saving_pct'],
|
|
29
31
|
};
|
|
30
32
|
}
|
|
31
33
|
export function OperationResultMetadataToJSON(json) {
|
|
@@ -37,5 +39,7 @@ export function OperationResultMetadataToJSONTyped(value, ignoreDiscriminator =
|
|
|
37
39
|
}
|
|
38
40
|
return {
|
|
39
41
|
'watermark_id': value['watermarkId'],
|
|
42
|
+
'already_optimal': value['alreadyOptimal'],
|
|
43
|
+
'estimated_saving_pct': value['estimatedSavingPct'],
|
|
40
44
|
};
|
|
41
45
|
}
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
/**
|
|
2
2
|
* GISL Compression API
|
|
3
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
3
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
5
|
+
* The version of the OpenAPI document: 2.213.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -92,8 +92,8 @@ export interface OperationResultMetrics {
|
|
|
92
92
|
reEncodeDecision?: ReEncodeDecision;
|
|
93
93
|
/**
|
|
94
94
|
* Advisory explanation for `re_encode_decision` (e.g.
|
|
95
|
-
* `
|
|
96
|
-
* `
|
|
95
|
+
* `compatible_inputs`, `always_mode_forces_re_encode`,
|
|
96
|
+
* `input_video_codec_mismatch`, `long_form_stream_copy`).
|
|
97
97
|
* Free-form string — not an enum — so the Lambda can emit
|
|
98
98
|
* human-readable diagnostics that evolve without contract
|
|
99
99
|
* changes. Mirrors `OperationMetrics.re_encode_reason`.
|
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
/* eslint-disable */
|
|
3
3
|
/**
|
|
4
4
|
* GISL Compression API
|
|
5
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
5
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
7
|
+
* The version of the OpenAPI document: 2.213.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
/**
|
|
2
2
|
* GISL Compression API
|
|
3
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
3
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
5
|
+
* The version of the OpenAPI document: 2.213.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -36,10 +36,9 @@ export interface OperationSchemaDefinition {
|
|
|
36
36
|
/**
|
|
37
37
|
* Operation-level availability tag. Optional — when absent, the
|
|
38
38
|
* operation is treated as `stable` (parser obligation per
|
|
39
|
-
* ADR-0001 §1.4 / FORMAT.md §Availability Taxonomy).
|
|
40
|
-
*
|
|
41
|
-
*
|
|
42
|
-
* does not yet surface the field.
|
|
39
|
+
* ADR-0001 §1.4 / FORMAT.md §Availability Taxonomy). Echoed by
|
|
40
|
+
* `GET /api/operations/schema` whenever the operation schema
|
|
41
|
+
* declares it ([I3 `eCWIpug8`](https://trello.com/c/eCWIpug8)).
|
|
43
42
|
*
|
|
44
43
|
* @type {AvailabilityValue}
|
|
45
44
|
* @memberof OperationSchemaDefinition
|
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
/* eslint-disable */
|
|
3
3
|
/**
|
|
4
4
|
* GISL Compression API
|
|
5
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
5
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
7
|
+
* The version of the OpenAPI document: 2.213.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
/**
|
|
2
2
|
* GISL Compression API
|
|
3
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
3
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
5
|
+
* The version of the OpenAPI document: 2.213.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
/* eslint-disable */
|
|
3
3
|
/**
|
|
4
4
|
* GISL Compression API
|
|
5
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
5
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
7
|
+
* The version of the OpenAPI document: 2.213.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
/**
|
|
2
2
|
* GISL Compression API
|
|
3
|
-
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
3
|
+
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Free-text string fields: `x-string-vocabulary` (ticket [`Q79yjcFF`](https://trello.com/c/Q79yjcFF)).** A `type: string` field with no `enum` that names example values says, as data, what a client may do with them (the same marker is used in the AsyncAPI document): - `open` — a vocabulary that grows. Each published value keeps its meaning, the SET is not closed: switch on the values you know and handle an unknown one as the generic case (e.g. `ErrorEnvelope.error`). - `advisory` — explanatory text. Display or log it; **never switch on it** (e.g. `SseWorkflowTerminalData.reason`). - `none` — not a vocabulary at all (an expression or an identifier, e.g. `OptionSchema.pattern`). A field whose description hedges with \"common values\" or \"free-form\" must carry the marker; a test enforces it. **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.
|
|
5
|
+
* The version of the OpenAPI document: 2.213.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -10,6 +10,12 @@
|
|
|
10
10
|
* Do not edit the class manually.
|
|
11
11
|
*/
|
|
12
12
|
/**
|
|
13
|
+
* ⚠️ **HOMONYM:** `asyncapi/events.yaml` also declares an `OperationType` —
|
|
14
|
+
* the narrower event PAYLOAD vocabulary. This one is the CREATE surface.
|
|
15
|
+
* Same name, different membership; generated SDKs emit both, and the
|
|
16
|
+
* import path is the only distinguisher (not renamed — breaking;
|
|
17
|
+
* `bFy3zo5Y`). Relation asserted in `schemas/cross-document-enums.yaml`.
|
|
18
|
+
*
|
|
13
19
|
* Available operation types:
|
|
14
20
|
* - compress: Reduce file size (images, audio, video, documents)
|
|
15
21
|
* - thumbnail: Legacy thumbnail value. Generates a preview image
|
|
@@ -35,11 +41,11 @@
|
|
|
35
41
|
* - convert: Change file format (all types)
|
|
36
42
|
* - custom_luma: Apply a caller-uploaded luma matte to a base video for a custom luma-matte transition effect. Multi-input (`role: base` + `role: transition_mask`). `availability: planned` (no tier gate); dispatch returns `feature_not_available` (422) until Lambda ships. Distinct from FFmpeg `xfade=custom` (which is an expression, not an operation). Per ticket I29 (Trello EPUE5Vs1).
|
|
37
43
|
* - audio_overlay: Mix a secondary audio asset over a primary audio or video base (DJ tags, podcast intros/outros, station IDs, jingles). Multi-input (`role: base` + `role: overlay`). `availability: planned`; dispatch returns `feature_not_available` (422) until Lambda ships. **NOT** the same as `audio_watermark` — that operation is steganographic (imperceptible identifier embedded for ownership tracking), tracked separately by I20. Per ticket I19 (Trello Xr3Z4GBF).
|
|
38
|
-
* - audio_watermark: Embed a steganographic forensic watermark into an audio asset (or a video's audio track) — Cinavia / Resemble PerTh territory. Single-input. `availability: planned`
|
|
44
|
+
* - audio_watermark: Embed a steganographic forensic watermark into an audio asset (or a video's audio track) — Cinavia / Resemble PerTh territory. Single-input. `availability: planned` (no tier gate since 2026-09-23); dispatch returns `feature_not_available` (422) until Lambda ships. Pairs with `POST /api/audio-watermark/decode` for own-watermarks-only extraction. Per ticket I20 (Trello omiCq7Vn).
|
|
39
45
|
* - audio_to_video: Produce a video from an audio input plus an OPTIONAL still image overlay. Multi-input role-based with the first OPTIONAL role on the contract (`role: base` audio required, `role: overlay` image 0..1 — see `per_role_cardinality`). When overlay is omitted, the video uses a solid background colour. `availability: planned` — WITHDRAWN 2026-09-15: measured 0.300 s of encode per second of output PLUS A 7 s FIXED COST, so the advertised PT2H needs 2167 s against a 900 s platform maximum (0.300 x 7200 alone is 2160 — the intercept is what makes the figure 2167, and a consumer dividing 600 by 0.300 gets a 2000 s in-flight boundary where the real one is 1976 s). Returns `feature_not_available` (422) at workflow-create. An already-accepted workflow is not cancelled (availability is checked at create) and fails only when its output duration exceeds ~1976 s ON THE INPUT THE RATE WAS MEASURED WITH (a real photographic 1080p still plus looped real audio), where 0.300 s per second plus a 7 s fixed cost reaches the worker's 600 s cap — the 60 s and 120 s measured cells both COMPLETED. The driver is the STILL'S RESOLUTION, not duration alone: a 4K still is roughly 4x the rate (unmeasured), which would put the boundary near a quarter of that, and this schema places no constraint on the overlay's resolution. Per ticket [`SlluxMBN`](https://trello.com/c/SlluxMBN) + ADR-0015 (introduces `per_role_cardinality` vocab).
|
|
40
46
|
* - video_watermark: Apply an image overlay onto a base video via FFmpeg's `overlay` filter. Multi-input role-based (`role: base` video + `role: overlay` image, exactly one of each per `per_role_cardinality`). Re-encode required; audio stream-copy passthrough. Distinct from `image_watermark` (pure-Rust/image-only). `availability: planned` — WITHDRAWN 2026-09-15, operation AND `short_form`: a real 1080p source at the advertised PT5M / 500 MB was killed at 606 s by the worker's 600 s encode cap, no output. Returns `feature_not_available` (422) at workflow-create; an already-accepted workflow is not cancelled and fails only if it exceeds that cap; the 606 s kill is ONE measured point and nothing measured says where the boundary is. `long_form` and `multi_overlay_stack` were already `planned`. Per ticket [`4NrRPCgh`](https://trello.com/c/4NrRPCgh) + ADR-0013.
|
|
41
47
|
* - video_text_watermark: Render a text overlay onto a base video via FFmpeg's `drawtext` filter. Single-input — text and styling in options. Same `watermark_mode` (single/tiled), anchor + margin vocab as `text_watermark`. Re-encode required; audio stream-copy passthrough. `availability: planned` — WITHDRAWN 2026-09-15, operation AND `short_form`: a real 1080p source at the advertised PT5M was killed at 604 s by the worker's 600 s encode cap. Returns `feature_not_available` (422) at workflow-create. ⚠️ This entry previously read "until Lambda ships", which was wrong in a way that mattered: the worker SHIPPED and runs — it is the CEILING that cannot be served. Per ticket [`4NrRPCgh`](https://trello.com/c/4NrRPCgh) + ADR-0013.
|
|
42
|
-
* - split: Fan one input file into N outputs across GIF / PDF / audio / video MIME families. Single-input per-mime-group catalog (mirrors merge/convert): GIF uses `frame_range` (REQUIRED) + `output_format`; PDF uses `page_range` OR `page_groups` (mutually exclusive); audio + video use a `mode` discriminator (interval/count/cut_points) + numeric-seconds wire format + `precision` flag (fast/exact). 200-output hard cap per ADR-0009 §D5 with per-mode preflight math; output naming `output-001..output-200`. Long-form video routes to a separate `split-video-fargate` worker via `processing_class`. `availability: beta` for the `audio` and `video` mime_groups (workers live on staging — shape-stable + opt-in, MUST NOT 422); video activates BOTH classes (`video.processing_class.short_form: beta` AND `long_form: beta` — `split-video-fargate` deployed + wired on staging
|
|
48
|
+
* - split: Fan one input file into N outputs across GIF / PDF / audio / video MIME families. Single-input per-mime-group catalog (mirrors merge/convert): GIF uses `frame_range` (REQUIRED) + `output_format`; PDF uses `page_range` OR `page_groups` (mutually exclusive); audio + video use a `mode` discriminator (interval/count/cut_points) + numeric-seconds wire format + `precision` flag (fast/exact). 200-output hard cap per ADR-0009 §D5 with per-mode preflight math; output naming `output-001..output-200`. Long-form video routes to a separate `split-video-fargate` worker via `processing_class`. `availability: beta` for the `audio` and `video` mime_groups (workers live on staging — shape-stable + opt-in, MUST NOT 422); video activates BOTH classes (`video.processing_class.short_form: beta` AND `long_form: beta` — `split-video-fargate` deployed + wired on staging; it stays `beta` until a PRODUCTION `customer_path` run is recorded in `availability/prod-verification-log.yaml` per [`rcwvUKhI`](https://trello.com/c/rcwvUKhI)). The `image_gif` and `document_pdf` mime_groups stay `availability: planned` and dispatch returns `feature_not_available` (422) until their workers ship. Per ticket [`vKI0CFDu`](https://trello.com/c/vKI0CFDu) + ADR-0014.
|
|
43
49
|
* - passthrough: Inert lossless source operation. A single-input source job whose SOLE operation is `passthrough` emits its source bytes UNCHANGED — no compression, no Lambda. The API self-completes the job at publish (terminal output = the upload `{bucket, key}` unchanged). Its purpose is to feed an uploaded file into a multi-input operation LOSSLESSLY: because `JobInputV2.source` is narrowed to exclude upload-direct, an upload that must enter a `merge` / `archive` / `image_watermark` op enters via a `passthrough` source job referenced downstream by `{type: job_output, from: <id>}` — preserving billing / DAG / lineage. Distinct from `operations: []` (which keeps its implicit-compress meaning on a single-input upload job); `passthrough` is the EXPLICIT lossless path via the "non-empty `operations[]` without `compress` = compression opt-out" rule. Media-agnostic; no options. `availability: beta` — activated (the inputs[]-narrowing + passthrough self-complete mechanism is deployed API-side); workflow-create accepts `passthrough` source jobs and MUST NOT return `feature_not_available`. **Never published to SNS** — deliberately absent from the AsyncAPI routing enums (API self-completes; no `ops-passthrough` queue). Per ticket [`4som89Uh`](https://trello.com/c/4som89Uh) + ADR-0004 (planned→beta flip).
|
|
44
50
|
*
|
|
45
51
|
* - transform: Geometric/orientation transform — v1 = rotate (0/90/180/270) + flip (none/horizontal/vertical/both), ADR-0026. Single-input; `produces: same_as_input` (geometry preserves format/container). Chainable (NOT sole_op); canonical single-job chain order is `transform → convert → compress → thumbnail` (geometry before encode/derive so downstream width/height/fit refer to the final frame). Media groups: image (still jpeg/png/webp + animated `image_gif`), video (mp4/webm), document (PDF page-rotate only — no flip); audio not supported. ALL groups `availability: planned` (epic `fhiWebI0`) — workflow-create returns `feature_not_available` (422) until per-media Lambdas ship. A no-op transform (`rotate: 0` + `flip: none`) is rejected as `invalid_options`. The public operation type is `transform`; the API resolves an internal per-media SNS routing sub-type (`transform_image` / `transform_video` / `transform_document`) — those sub-types are routing-only and are NOT part of this public enum. Per ADR-0026.
|