@giveitsmaller/contracts 0.92.0 → 0.93.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 +1 -1
- package/availability/availability.json +2 -2
- package/code-builder/code-builder-metadata.json +3 -3
- package/dist/openapi/models/AccountLimitEntry.d.ts +1 -1
- package/dist/openapi/models/AccountLimitEntry.js +1 -1
- package/dist/openapi/models/AccountLimits.d.ts +1 -1
- package/dist/openapi/models/AccountLimits.js +1 -1
- package/dist/openapi/models/AccountLimitsLimits.d.ts +1 -1
- package/dist/openapi/models/AccountLimitsLimits.js +1 -1
- package/dist/openapi/models/AccountLimitsSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/AccountLimitsSuccessEnvelope.js +1 -1
- package/dist/openapi/models/AnonymousLimitExceededResponse.d.ts +1 -1
- package/dist/openapi/models/AnonymousLimitExceededResponse.js +1 -1
- package/dist/openapi/models/AnonymousOperationNotAllowedResponse.d.ts +1 -1
- package/dist/openapi/models/AnonymousOperationNotAllowedResponse.js +1 -1
- package/dist/openapi/models/AnonymousQuotaExhaustedResponse.d.ts +1 -1
- package/dist/openapi/models/AnonymousQuotaExhaustedResponse.js +1 -1
- package/dist/openapi/models/AudioWatermarkDecodeRequest.d.ts +1 -1
- package/dist/openapi/models/AudioWatermarkDecodeRequest.js +1 -1
- package/dist/openapi/models/AudioWatermarkDecodeResponse.d.ts +1 -1
- package/dist/openapi/models/AudioWatermarkDecodeResponse.js +1 -1
- package/dist/openapi/models/AuthErrorResponse.d.ts +1 -1
- package/dist/openapi/models/AuthErrorResponse.js +1 -1
- package/dist/openapi/models/AuthErrorType.d.ts +1 -1
- package/dist/openapi/models/AuthErrorType.js +1 -1
- package/dist/openapi/models/AuthRejectionEnvelope.d.ts +1 -1
- package/dist/openapi/models/AuthRejectionEnvelope.js +1 -1
- package/dist/openapi/models/AuthenticatedIdentity.d.ts +1 -1
- package/dist/openapi/models/AuthenticatedIdentity.js +1 -1
- package/dist/openapi/models/AvailabilityValue.d.ts +1 -1
- package/dist/openapi/models/AvailabilityValue.js +1 -1
- package/dist/openapi/models/BalanceExhaustedResponse.d.ts +1 -1
- package/dist/openapi/models/BalanceExhaustedResponse.js +1 -1
- package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.d.ts +1 -1
- package/dist/openapi/models/BalanceExhaustedResponseAllOfLinks.js +1 -1
- package/dist/openapi/models/BillingCheckoutRequest.d.ts +1 -1
- package/dist/openapi/models/BillingCheckoutRequest.js +1 -1
- package/dist/openapi/models/BillingCheckoutSession.d.ts +1 -1
- package/dist/openapi/models/BillingCheckoutSession.js +1 -1
- package/dist/openapi/models/BillingCheckoutSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/BillingCheckoutSuccessEnvelope.js +1 -1
- package/dist/openapi/models/CallbackEventType.d.ts +1 -1
- package/dist/openapi/models/CallbackEventType.js +1 -1
- package/dist/openapi/models/CancelAccountDeletion200Response.d.ts +1 -1
- package/dist/openapi/models/CancelAccountDeletion200Response.js +1 -1
- package/dist/openapi/models/CancelAccountDeletion200ResponseData.d.ts +1 -1
- package/dist/openapi/models/CancelAccountDeletion200ResponseData.js +1 -1
- package/dist/openapi/models/CapabilityCondition.d.ts +1 -1
- package/dist/openapi/models/CapabilityCondition.js +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf.d.ts +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf.js +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf1.d.ts +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf1.js +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf2.d.ts +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf2.js +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf3.d.ts +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf3.js +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf4.d.ts +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf4.js +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf5.d.ts +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf5.js +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf6.d.ts +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf6.js +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf7.d.ts +1 -1
- package/dist/openapi/models/CapabilityConditionOneOf7.js +1 -1
- package/dist/openapi/models/CapabilityConstraint.d.ts +1 -1
- package/dist/openapi/models/CapabilityConstraint.js +1 -1
- package/dist/openapi/models/CapabilityInputSpec.d.ts +1 -1
- package/dist/openapi/models/CapabilityInputSpec.js +1 -1
- package/dist/openapi/models/CapabilityProduces.d.ts +1 -1
- package/dist/openapi/models/CapabilityProduces.js +1 -1
- package/dist/openapi/models/CapabilityProducesOneOf.d.ts +1 -1
- package/dist/openapi/models/CapabilityProducesOneOf.js +1 -1
- package/dist/openapi/models/CapabilityProducesOneOf1.d.ts +1 -1
- package/dist/openapi/models/CapabilityProducesOneOf1.js +1 -1
- package/dist/openapi/models/CapabilityProducesOneOf2.d.ts +1 -1
- package/dist/openapi/models/CapabilityProducesOneOf2.js +1 -1
- package/dist/openapi/models/CeilingBasisValue.d.ts +1 -1
- package/dist/openapi/models/CeilingBasisValue.js +1 -1
- package/dist/openapi/models/ChangePasswordRequest.d.ts +1 -1
- package/dist/openapi/models/ChangePasswordRequest.js +1 -1
- package/dist/openapi/models/CheckoutSessionStatusResponse.d.ts +1 -1
- package/dist/openapi/models/CheckoutSessionStatusResponse.js +1 -1
- package/dist/openapi/models/CheckoutSessionStatusResponseData.d.ts +1 -1
- package/dist/openapi/models/CheckoutSessionStatusResponseData.js +1 -1
- package/dist/openapi/models/CodegenSource.d.ts +1 -1
- package/dist/openapi/models/CodegenSource.js +1 -1
- package/dist/openapi/models/CodegenSourceInput.d.ts +1 -1
- package/dist/openapi/models/CodegenSourceInput.js +1 -1
- package/dist/openapi/models/CodegenSourceJob.d.ts +1 -1
- package/dist/openapi/models/CodegenSourceJob.js +1 -1
- package/dist/openapi/models/CodegenSourceJobSource.d.ts +1 -1
- package/dist/openapi/models/CodegenSourceJobSource.js +1 -1
- package/dist/openapi/models/CodegenSourceOperation.d.ts +1 -1
- package/dist/openapi/models/CodegenSourceOperation.js +1 -1
- package/dist/openapi/models/CodegenUploadPlaceholder.d.ts +1 -1
- package/dist/openapi/models/CodegenUploadPlaceholder.js +1 -1
- package/dist/openapi/models/CompositionPlan.d.ts +1 -1
- package/dist/openapi/models/CompositionPlan.js +1 -1
- package/dist/openapi/models/CompositionPlanJob.d.ts +1 -1
- package/dist/openapi/models/CompositionPlanJob.js +1 -1
- package/dist/openapi/models/CompositionPlanOperation.d.ts +1 -1
- package/dist/openapi/models/CompositionPlanOperation.js +1 -1
- package/dist/openapi/models/ConfirmEmailChange200Response.d.ts +1 -1
- package/dist/openapi/models/ConfirmEmailChange200Response.js +1 -1
- package/dist/openapi/models/ConfirmEmailChange200ResponseData.d.ts +1 -1
- package/dist/openapi/models/ConfirmEmailChange200ResponseData.js +1 -1
- package/dist/openapi/models/ConfirmEmailChangeRequest.d.ts +1 -1
- package/dist/openapi/models/ConfirmEmailChangeRequest.js +1 -1
- package/dist/openapi/models/ConnectionSource.d.ts +1 -1
- package/dist/openapi/models/ConnectionSource.js +1 -1
- package/dist/openapi/models/ContactRequest.d.ts +1 -1
- package/dist/openapi/models/ContactRequest.js +1 -1
- package/dist/openapi/models/ContactSubject.d.ts +1 -1
- package/dist/openapi/models/ContactSubject.js +1 -1
- package/dist/openapi/models/ContactValidationErrorResponse.d.ts +1 -1
- package/dist/openapi/models/ContactValidationErrorResponse.js +1 -1
- package/dist/openapi/models/CreateApiKey201Response.d.ts +1 -1
- package/dist/openapi/models/CreateApiKey201Response.js +1 -1
- package/dist/openapi/models/CreateApiKey201ResponseData.d.ts +1 -1
- package/dist/openapi/models/CreateApiKey201ResponseData.js +1 -1
- package/dist/openapi/models/CreateApiKeyRequest.d.ts +1 -1
- package/dist/openapi/models/CreateApiKeyRequest.js +1 -1
- package/dist/openapi/models/CreateBillingCheckoutSession422Response.d.ts +1 -1
- package/dist/openapi/models/CreateBillingCheckoutSession422Response.js +1 -1
- package/dist/openapi/models/CreateExternalImport403Response.d.ts +1 -1
- package/dist/openapi/models/CreateExternalImport403Response.js +1 -1
- package/dist/openapi/models/CreateExternalImport422Response.d.ts +1 -1
- package/dist/openapi/models/CreateExternalImport422Response.js +1 -1
- package/dist/openapi/models/CreateWorkflow401Response.d.ts +1 -1
- package/dist/openapi/models/CreateWorkflow401Response.js +1 -1
- package/dist/openapi/models/CreateWorkflow403Response.d.ts +1 -1
- package/dist/openapi/models/CreateWorkflow403Response.js +1 -1
- package/dist/openapi/models/CreateWorkflow422Response.d.ts +1 -1
- package/dist/openapi/models/CreateWorkflow422Response.js +1 -1
- package/dist/openapi/models/CreditTransaction.d.ts +1 -1
- package/dist/openapi/models/CreditTransaction.js +1 -1
- package/dist/openapi/models/CreditTransactionSourceBucket.d.ts +1 -1
- package/dist/openapi/models/CreditTransactionSourceBucket.js +1 -1
- package/dist/openapi/models/CreditsBalanceResponse.d.ts +1 -1
- package/dist/openapi/models/CreditsBalanceResponse.js +1 -1
- package/dist/openapi/models/CreditsBalanceSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/CreditsBalanceSuccessEnvelope.js +1 -1
- package/dist/openapi/models/CreditsUsageResponse.d.ts +1 -1
- package/dist/openapi/models/CreditsUsageResponse.js +1 -1
- package/dist/openapi/models/CreditsUsageSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/CreditsUsageSuccessEnvelope.js +1 -1
- package/dist/openapi/models/Delivery.d.ts +1 -1
- package/dist/openapi/models/Delivery.js +1 -1
- package/dist/openapi/models/DeliveryOutputRef.d.ts +1 -1
- package/dist/openapi/models/DeliveryOutputRef.js +1 -1
- package/dist/openapi/models/DeliveryPlan.d.ts +1 -1
- package/dist/openapi/models/DeliveryPlan.js +1 -1
- package/dist/openapi/models/DeliveryPlanOutput.d.ts +1 -1
- package/dist/openapi/models/DeliveryPlanOutput.js +1 -1
- package/dist/openapi/models/DeliveryPlanReason.d.ts +1 -1
- package/dist/openapi/models/DeliveryPlanReason.js +1 -1
- package/dist/openapi/models/DeliverySelection.d.ts +1 -1
- package/dist/openapi/models/DeliverySelection.js +1 -1
- package/dist/openapi/models/DownloadBundle.d.ts +1 -1
- package/dist/openapi/models/DownloadBundle.js +1 -1
- package/dist/openapi/models/DroppedOption.d.ts +1 -1
- package/dist/openapi/models/DroppedOption.js +1 -1
- package/dist/openapi/models/EmailNotify.d.ts +1 -1
- package/dist/openapi/models/EmailNotify.js +1 -1
- package/dist/openapi/models/EmptySuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/EmptySuccessEnvelope.js +1 -1
- package/dist/openapi/models/EndpointProjection.d.ts +1 -1
- package/dist/openapi/models/EndpointProjection.js +1 -1
- package/dist/openapi/models/EndpointProjectionServersInner.d.ts +1 -1
- package/dist/openapi/models/EndpointProjectionServersInner.js +1 -1
- package/dist/openapi/models/ErrorEnvelope.d.ts +1 -1
- package/dist/openapi/models/ErrorEnvelope.js +1 -1
- package/dist/openapi/models/EstimateQuality.d.ts +1 -1
- package/dist/openapi/models/EstimateQuality.js +1 -1
- package/dist/openapi/models/EstimateRange.d.ts +1 -1
- package/dist/openapi/models/EstimateRange.js +1 -1
- package/dist/openapi/models/ExportAccountData200Response.d.ts +1 -1
- package/dist/openapi/models/ExportAccountData200Response.js +1 -1
- package/dist/openapi/models/ExportAccountData200ResponseData.d.ts +1 -1
- package/dist/openapi/models/ExportAccountData200ResponseData.js +1 -1
- package/dist/openapi/models/ExportAccountData200ResponseDataBilling.d.ts +1 -1
- package/dist/openapi/models/ExportAccountData200ResponseDataBilling.js +1 -1
- package/dist/openapi/models/ExportAccountData200ResponseDataBillingCheckoutSessionsInner.d.ts +1 -1
- package/dist/openapi/models/ExportAccountData200ResponseDataBillingCheckoutSessionsInner.js +1 -1
- package/dist/openapi/models/ExternalDestination.d.ts +1 -1
- package/dist/openapi/models/ExternalDestination.js +1 -1
- package/dist/openapi/models/ExternalImportCreatedResponse.d.ts +1 -1
- package/dist/openapi/models/ExternalImportCreatedResponse.js +1 -1
- package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/ExternalImportCreatedSuccessEnvelope.js +1 -1
- package/dist/openapi/models/ExternalImportRequest.d.ts +1 -1
- package/dist/openapi/models/ExternalImportRequest.js +1 -1
- package/dist/openapi/models/ExternalImportToken.d.ts +1 -1
- package/dist/openapi/models/ExternalImportToken.js +1 -1
- package/dist/openapi/models/ExternalSource.d.ts +1 -1
- package/dist/openapi/models/ExternalSource.js +1 -1
- package/dist/openapi/models/FeatureNotAvailableResponse.d.ts +1 -1
- package/dist/openapi/models/FeatureNotAvailableResponse.js +1 -1
- package/dist/openapi/models/FeatureTierRestrictedResponse.d.ts +1 -1
- package/dist/openapi/models/FeatureTierRestrictedResponse.js +1 -1
- package/dist/openapi/models/FeatureViolation.d.ts +1 -1
- package/dist/openapi/models/FeatureViolation.js +1 -1
- package/dist/openapi/models/GetProfile200Response.d.ts +1 -1
- package/dist/openapi/models/GetProfile200Response.js +1 -1
- package/dist/openapi/models/GetProfile200ResponseData.d.ts +1 -1
- package/dist/openapi/models/GetProfile200ResponseData.js +1 -1
- package/dist/openapi/models/ImageEncodeCapabilities.d.ts +1 -1
- package/dist/openapi/models/ImageEncodeCapabilities.js +1 -1
- package/dist/openapi/models/InputCeilingViolation.d.ts +86 -0
- package/dist/openapi/models/InputCeilingViolation.js +57 -0
- package/dist/openapi/models/JobDefinition.d.ts +1 -1
- package/dist/openapi/models/JobDefinition.js +1 -1
- package/dist/openapi/models/JobDownload.d.ts +1 -1
- package/dist/openapi/models/JobDownload.js +1 -1
- package/dist/openapi/models/JobInputV2.d.ts +1 -1
- package/dist/openapi/models/JobInputV2.js +1 -1
- package/dist/openapi/models/JobMediaClass.d.ts +1 -1
- package/dist/openapi/models/JobMediaClass.js +1 -1
- package/dist/openapi/models/JobOutputSource.d.ts +1 -1
- package/dist/openapi/models/JobOutputSource.js +1 -1
- package/dist/openapi/models/JobResponse.d.ts +1 -1
- package/dist/openapi/models/JobResponse.js +1 -1
- package/dist/openapi/models/JobStatus.d.ts +1 -1
- package/dist/openapi/models/JobStatus.js +1 -1
- package/dist/openapi/models/JobType.d.ts +1 -1
- package/dist/openapi/models/JobType.js +1 -1
- package/dist/openapi/models/LivenessResponse.d.ts +1 -1
- package/dist/openapi/models/LivenessResponse.js +1 -1
- package/dist/openapi/models/LoginUser200Response.d.ts +1 -1
- package/dist/openapi/models/LoginUser200Response.js +1 -1
- package/dist/openapi/models/LoginUser200ResponseData.d.ts +1 -1
- package/dist/openapi/models/LoginUser200ResponseData.js +1 -1
- package/dist/openapi/models/LoginUser200ResponseDataUser.d.ts +1 -1
- package/dist/openapi/models/LoginUser200ResponseDataUser.js +1 -1
- package/dist/openapi/models/LoginUser401Response.d.ts +1 -1
- package/dist/openapi/models/LoginUser401Response.js +1 -1
- package/dist/openapi/models/LoginUserRequest.d.ts +1 -1
- package/dist/openapi/models/LoginUserRequest.js +1 -1
- package/dist/openapi/models/LongFormConcurrencyLimitResponse.d.ts +1 -1
- package/dist/openapi/models/LongFormConcurrencyLimitResponse.js +1 -1
- package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.d.ts +1 -1
- package/dist/openapi/models/LongFormConcurrencyLimitResponseAllOfLinks.js +1 -1
- package/dist/openapi/models/MetadataResponse.d.ts +1 -1
- package/dist/openapi/models/MetadataResponse.js +1 -1
- package/dist/openapi/models/MetadataResponseDimensions.d.ts +1 -1
- package/dist/openapi/models/MetadataResponseDimensions.js +1 -1
- package/dist/openapi/models/MetadataResponseExif.d.ts +1 -1
- package/dist/openapi/models/MetadataResponseExif.js +1 -1
- package/dist/openapi/models/MetadataResponseExifGps.d.ts +1 -1
- package/dist/openapi/models/MetadataResponseExifGps.js +1 -1
- package/dist/openapi/models/MetadataSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/MetadataSuccessEnvelope.js +1 -1
- package/dist/openapi/models/MimeGroupSchema.d.ts +1 -1
- package/dist/openapi/models/MimeGroupSchema.js +1 -1
- package/dist/openapi/models/MultiInputSource.d.ts +1 -1
- package/dist/openapi/models/MultiInputSource.js +1 -1
- package/dist/openapi/models/MultipartCompleteRequest.d.ts +1 -1
- package/dist/openapi/models/MultipartCompleteRequest.js +1 -1
- package/dist/openapi/models/MultipartCompleteRequestPartsInner.d.ts +1 -1
- package/dist/openapi/models/MultipartCompleteRequestPartsInner.js +1 -1
- package/dist/openapi/models/MultipartCompleteResponse.d.ts +1 -1
- package/dist/openapi/models/MultipartCompleteResponse.js +1 -1
- package/dist/openapi/models/MultipartCompleteSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/MultipartCompleteSuccessEnvelope.js +1 -1
- package/dist/openapi/models/MultipartInitiateRequestMetadataHint.d.ts +1 -1
- package/dist/openapi/models/MultipartInitiateRequestMetadataHint.js +1 -1
- package/dist/openapi/models/MultipartInitiateResponse.d.ts +1 -1
- package/dist/openapi/models/MultipartInitiateResponse.js +1 -1
- package/dist/openapi/models/MultipartInitiateSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/MultipartInitiateSuccessEnvelope.js +1 -1
- package/dist/openapi/models/MultipartKeepaliveResponse.d.ts +1 -1
- package/dist/openapi/models/MultipartKeepaliveResponse.js +1 -1
- package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/MultipartKeepaliveSuccessEnvelope.js +1 -1
- package/dist/openapi/models/MultipartPartListing.d.ts +1 -1
- package/dist/openapi/models/MultipartPartListing.js +1 -1
- package/dist/openapi/models/MultipartPresignRequest.d.ts +1 -1
- package/dist/openapi/models/MultipartPresignRequest.js +1 -1
- package/dist/openapi/models/MultipartPresignResponse.d.ts +1 -1
- package/dist/openapi/models/MultipartPresignResponse.js +1 -1
- package/dist/openapi/models/MultipartPresignSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/MultipartPresignSuccessEnvelope.js +1 -1
- package/dist/openapi/models/MultipartStatusResponse.d.ts +1 -1
- package/dist/openapi/models/MultipartStatusResponse.js +1 -1
- package/dist/openapi/models/MultipartStatusSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/MultipartStatusSuccessEnvelope.js +1 -1
- package/dist/openapi/models/NotifyConfig.d.ts +1 -1
- package/dist/openapi/models/NotifyConfig.js +1 -1
- package/dist/openapi/models/OperationCapability.d.ts +1 -1
- package/dist/openapi/models/OperationCapability.js +1 -1
- package/dist/openapi/models/OperationDefinition.d.ts +1 -1
- package/dist/openapi/models/OperationDefinition.js +1 -1
- package/dist/openapi/models/OperationDownload.d.ts +1 -1
- package/dist/openapi/models/OperationDownload.js +1 -1
- package/dist/openapi/models/OperationInputModel.d.ts +1 -1
- package/dist/openapi/models/OperationInputModel.js +1 -1
- package/dist/openapi/models/OperationMessageParamsValue.d.ts +1 -1
- package/dist/openapi/models/OperationMessageParamsValue.js +1 -1
- package/dist/openapi/models/OperationResponse.d.ts +1 -1
- package/dist/openapi/models/OperationResponse.js +1 -1
- package/dist/openapi/models/OperationResult.d.ts +1 -1
- package/dist/openapi/models/OperationResult.js +1 -1
- package/dist/openapi/models/OperationResultMetadata.d.ts +1 -1
- package/dist/openapi/models/OperationResultMetadata.js +1 -1
- package/dist/openapi/models/OperationResultMetrics.d.ts +1 -1
- package/dist/openapi/models/OperationResultMetrics.js +1 -1
- package/dist/openapi/models/OperationSchemaDefinition.d.ts +1 -1
- package/dist/openapi/models/OperationSchemaDefinition.js +1 -1
- package/dist/openapi/models/OperationStatus.d.ts +1 -1
- package/dist/openapi/models/OperationStatus.js +1 -1
- package/dist/openapi/models/OperationType.d.ts +1 -1
- package/dist/openapi/models/OperationType.js +1 -1
- package/dist/openapi/models/OperationsSchemaResponse.d.ts +1 -1
- package/dist/openapi/models/OperationsSchemaResponse.js +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.d.ts +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeatures.js +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.d.ts +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDelivery.js +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.d.ts +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliveryMode.js +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.d.ts +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesDeliverySelection.js +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.d.ts +1 -1
- package/dist/openapi/models/OperationsSchemaResponseWorkflowFeaturesProcessing.js +1 -1
- package/dist/openapi/models/OptionSchema.d.ts +1 -1
- package/dist/openapi/models/OptionSchema.js +1 -1
- package/dist/openapi/models/OptionSchemaPerValueConstraintsValue.d.ts +1 -1
- package/dist/openapi/models/OptionSchemaPerValueConstraintsValue.js +1 -1
- package/dist/openapi/models/OutputProperties.d.ts +1 -1
- package/dist/openapi/models/OutputProperties.js +1 -1
- package/dist/openapi/models/OutputPropertiesIsAnimated.d.ts +1 -1
- package/dist/openapi/models/OutputPropertiesIsAnimated.js +1 -1
- package/dist/openapi/models/PerClassAvailabilityEntry.d.ts +1 -1
- package/dist/openapi/models/PerClassAvailabilityEntry.js +1 -1
- package/dist/openapi/models/PerRoleCardinalityEntry.d.ts +1 -1
- package/dist/openapi/models/PerRoleCardinalityEntry.js +1 -1
- package/dist/openapi/models/PerValueAvailabilityEntry.d.ts +1 -1
- package/dist/openapi/models/PerValueAvailabilityEntry.js +1 -1
- package/dist/openapi/models/PresignedUrlPart.d.ts +1 -1
- package/dist/openapi/models/PresignedUrlPart.js +1 -1
- package/dist/openapi/models/ProbePendingResponse.d.ts +1 -1
- package/dist/openapi/models/ProbePendingResponse.js +1 -1
- package/dist/openapi/models/ProbeUpload422Response.d.ts +1 -1
- package/dist/openapi/models/ProbeUpload422Response.js +1 -1
- package/dist/openapi/models/ProcessingClass.d.ts +1 -1
- package/dist/openapi/models/ProcessingClass.js +1 -1
- package/dist/openapi/models/ProcessingClassBandViolation.d.ts +1 -1
- package/dist/openapi/models/ProcessingClassBandViolation.js +1 -1
- package/dist/openapi/models/ProcessingClassConstraints.d.ts +1 -1
- package/dist/openapi/models/ProcessingClassConstraints.js +1 -1
- package/dist/openapi/models/ProcessingClassEntry.d.ts +1 -1
- package/dist/openapi/models/ProcessingClassEntry.js +1 -1
- package/dist/openapi/models/ProcessingClassEntryInputUniformity.d.ts +1 -1
- package/dist/openapi/models/ProcessingClassEntryInputUniformity.js +1 -1
- package/dist/openapi/models/ProcessingClassEntryResolutionBands.d.ts +1 -1
- package/dist/openapi/models/ProcessingClassEntryResolutionBands.js +1 -1
- package/dist/openapi/models/ProcessingClassExceedsBandResponse.d.ts +1 -1
- package/dist/openapi/models/ProcessingClassExceedsBandResponse.js +1 -1
- package/dist/openapi/models/ProcessingClassHint.d.ts +1 -1
- package/dist/openapi/models/ProcessingClassHint.js +1 -1
- package/dist/openapi/models/ProcessingClassReason.d.ts +1 -1
- package/dist/openapi/models/ProcessingClassReason.js +1 -1
- package/dist/openapi/models/ProcessingClassRejectReason.d.ts +1 -1
- package/dist/openapi/models/ProcessingClassRejectReason.js +1 -1
- package/dist/openapi/models/ProcessingPlan.d.ts +1 -1
- package/dist/openapi/models/ProcessingPlan.js +1 -1
- package/dist/openapi/models/ProcessingPlanJob.d.ts +1 -1
- package/dist/openapi/models/ProcessingPlanJob.js +1 -1
- package/dist/openapi/models/ReEncodeDecision.d.ts +1 -1
- package/dist/openapi/models/ReEncodeDecision.js +1 -1
- package/dist/openapi/models/ReadinessResponse.d.ts +1 -1
- package/dist/openapi/models/ReadinessResponse.js +1 -1
- package/dist/openapi/models/RegisterUser422Response.d.ts +1 -1
- package/dist/openapi/models/RegisterUser422Response.js +1 -1
- package/dist/openapi/models/RegisterUserRequest.d.ts +1 -1
- package/dist/openapi/models/RegisterUserRequest.js +1 -1
- package/dist/openapi/models/RequestAccountDeletion200Response.d.ts +1 -1
- package/dist/openapi/models/RequestAccountDeletion200Response.js +1 -1
- package/dist/openapi/models/RequestAccountDeletion200ResponseData.d.ts +1 -1
- package/dist/openapi/models/RequestAccountDeletion200ResponseData.js +1 -1
- package/dist/openapi/models/RequestAccountDeletionRequest.d.ts +1 -1
- package/dist/openapi/models/RequestAccountDeletionRequest.js +1 -1
- package/dist/openapi/models/ResendVerificationEmailRequest.d.ts +1 -1
- package/dist/openapi/models/ResendVerificationEmailRequest.js +1 -1
- package/dist/openapi/models/ResetPasswordRequest.d.ts +1 -1
- package/dist/openapi/models/ResetPasswordRequest.js +1 -1
- package/dist/openapi/models/ResolutionBand.d.ts +1 -1
- package/dist/openapi/models/ResolutionBand.js +1 -1
- package/dist/openapi/models/ResolutionBandCeiling.d.ts +1 -1
- package/dist/openapi/models/ResolutionBandCeiling.js +1 -1
- package/dist/openapi/models/ResolutionBandCeilingConstraints.d.ts +1 -1
- package/dist/openapi/models/ResolutionBandCeilingConstraints.js +1 -1
- package/dist/openapi/models/ResolutionBandCeilingDerivation.d.ts +1 -1
- package/dist/openapi/models/ResolutionBandCeilingDerivation.js +1 -1
- package/dist/openapi/models/ResponseEnvelope.d.ts +1 -1
- package/dist/openapi/models/ResponseEnvelope.js +1 -1
- package/dist/openapi/models/RetryResponse.d.ts +1 -1
- package/dist/openapi/models/RetryResponse.js +1 -1
- package/dist/openapi/models/RetrySuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/RetrySuccessEnvelope.js +1 -1
- package/dist/openapi/models/SseCompletionBase.d.ts +1 -1
- package/dist/openapi/models/SseCompletionBase.js +1 -1
- package/dist/openapi/models/SseConnectionLimitResponse.d.ts +1 -1
- package/dist/openapi/models/SseConnectionLimitResponse.js +1 -1
- package/dist/openapi/models/SseEventType.d.ts +1 -1
- package/dist/openapi/models/SseEventType.js +1 -1
- package/dist/openapi/models/SseJobCompletedData.d.ts +1 -1
- package/dist/openapi/models/SseJobCompletedData.js +1 -1
- package/dist/openapi/models/SseJobFailedData.d.ts +1 -1
- package/dist/openapi/models/SseJobFailedData.js +1 -1
- package/dist/openapi/models/SseMultiOutputCompletion.d.ts +1 -1
- package/dist/openapi/models/SseMultiOutputCompletion.js +1 -1
- package/dist/openapi/models/SseMultiOutputCompletionMetrics.d.ts +1 -1
- package/dist/openapi/models/SseMultiOutputCompletionMetrics.js +1 -1
- package/dist/openapi/models/SseMultiOutputCompletionWithKind.d.ts +1 -1
- package/dist/openapi/models/SseMultiOutputCompletionWithKind.js +1 -1
- package/dist/openapi/models/SseMultiOutputResultEntry.d.ts +1 -1
- package/dist/openapi/models/SseMultiOutputResultEntry.js +1 -1
- package/dist/openapi/models/SseOperationCompletedData.d.ts +1 -1
- package/dist/openapi/models/SseOperationCompletedData.js +1 -1
- package/dist/openapi/models/SseOperationCompletionResult.d.ts +1 -1
- package/dist/openapi/models/SseOperationCompletionResult.js +1 -1
- package/dist/openapi/models/SseOperationFailedData.d.ts +1 -1
- package/dist/openapi/models/SseOperationFailedData.js +1 -1
- package/dist/openapi/models/SseOperationProgressData.d.ts +1 -1
- package/dist/openapi/models/SseOperationProgressData.js +1 -1
- package/dist/openapi/models/SseSingleOutputCompletion.d.ts +1 -1
- package/dist/openapi/models/SseSingleOutputCompletion.js +1 -1
- package/dist/openapi/models/SseWorkflowTerminalData.d.ts +1 -1
- package/dist/openapi/models/SseWorkflowTerminalData.js +1 -1
- package/dist/openapi/models/TierRestrictionKind.d.ts +1 -1
- package/dist/openapi/models/TierRestrictionKind.js +1 -1
- package/dist/openapi/models/TierRestrictionResponse.d.ts +1 -1
- package/dist/openapi/models/TierRestrictionResponse.js +1 -1
- package/dist/openapi/models/UpdateProfile200Response.d.ts +1 -1
- package/dist/openapi/models/UpdateProfile200Response.js +1 -1
- package/dist/openapi/models/UpdateProfile200ResponseData.d.ts +1 -1
- package/dist/openapi/models/UpdateProfile200ResponseData.js +1 -1
- package/dist/openapi/models/UpdateProfile422Response.d.ts +1 -1
- package/dist/openapi/models/UpdateProfile422Response.js +1 -1
- package/dist/openapi/models/UpdateProfileRequest.d.ts +1 -1
- package/dist/openapi/models/UpdateProfileRequest.js +1 -1
- package/dist/openapi/models/UploadConstraintsApplied.d.ts +1 -1
- package/dist/openapi/models/UploadConstraintsApplied.js +1 -1
- package/dist/openapi/models/UploadDurationExceedsTierResponse.d.ts +1 -1
- package/dist/openapi/models/UploadDurationExceedsTierResponse.js +1 -1
- package/dist/openapi/models/UploadFile403Response.d.ts +1 -1
- package/dist/openapi/models/UploadFile403Response.js +1 -1
- package/dist/openapi/models/UploadFile422Response.d.ts +1 -1
- package/dist/openapi/models/UploadFile422Response.js +1 -1
- package/dist/openapi/models/UploadProbeMediaMetadata.d.ts +1 -1
- package/dist/openapi/models/UploadProbeMediaMetadata.js +1 -1
- package/dist/openapi/models/UploadProbeNotApplicableResponse.d.ts +1 -1
- package/dist/openapi/models/UploadProbeNotApplicableResponse.js +1 -1
- package/dist/openapi/models/UploadProbeNotReadyResponse.d.ts +1 -1
- package/dist/openapi/models/UploadProbeNotReadyResponse.js +1 -1
- package/dist/openapi/models/UploadProbeProcessingClass.d.ts +1 -1
- package/dist/openapi/models/UploadProbeProcessingClass.js +1 -1
- package/dist/openapi/models/UploadProbeResponse.d.ts +1 -1
- package/dist/openapi/models/UploadProbeResponse.js +1 -1
- package/dist/openapi/models/UploadProbeStatus.d.ts +1 -1
- package/dist/openapi/models/UploadProbeStatus.js +1 -1
- package/dist/openapi/models/UploadProbeSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/UploadProbeSuccessEnvelope.js +1 -1
- package/dist/openapi/models/UploadResponse.d.ts +1 -1
- package/dist/openapi/models/UploadResponse.js +1 -1
- package/dist/openapi/models/UploadSizeExceedsTierResponse.d.ts +1 -1
- package/dist/openapi/models/UploadSizeExceedsTierResponse.js +1 -1
- package/dist/openapi/models/UploadSource.d.ts +1 -1
- package/dist/openapi/models/UploadSource.js +1 -1
- package/dist/openapi/models/UploadSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/UploadSuccessEnvelope.js +1 -1
- package/dist/openapi/models/UploadThresholds.d.ts +1 -1
- package/dist/openapi/models/UploadThresholds.js +1 -1
- package/dist/openapi/models/UserTier.d.ts +1 -1
- package/dist/openapi/models/UserTier.js +1 -1
- package/dist/openapi/models/ValidationErrorEnvelope.d.ts +5 -2
- package/dist/openapi/models/ValidationErrorEnvelope.js +1 -1
- package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +8 -1
- package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +4 -1
- package/dist/openapi/models/VerifyEmailRequest.d.ts +1 -1
- package/dist/openapi/models/VerifyEmailRequest.js +1 -1
- package/dist/openapi/models/WarningType.d.ts +1 -1
- package/dist/openapi/models/WarningType.js +1 -1
- package/dist/openapi/models/WebhookOperationContext.d.ts +1 -1
- package/dist/openapi/models/WebhookOperationContext.js +1 -1
- package/dist/openapi/models/WebhookPayload.d.ts +1 -1
- package/dist/openapi/models/WebhookPayload.js +1 -1
- package/dist/openapi/models/WorkflowArchiveResponse.d.ts +1 -1
- package/dist/openapi/models/WorkflowArchiveResponse.js +1 -1
- package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/WorkflowArchiveSuccessEnvelope.js +1 -1
- package/dist/openapi/models/WorkflowCancelBillingEffect.d.ts +1 -1
- package/dist/openapi/models/WorkflowCancelBillingEffect.js +1 -1
- package/dist/openapi/models/WorkflowCancelResponse.d.ts +1 -1
- package/dist/openapi/models/WorkflowCancelResponse.js +1 -1
- package/dist/openapi/models/WorkflowCancelSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/WorkflowCancelSuccessEnvelope.js +1 -1
- package/dist/openapi/models/WorkflowCreateRequest.d.ts +1 -1
- package/dist/openapi/models/WorkflowCreateRequest.js +1 -1
- package/dist/openapi/models/WorkflowCreateResponse.d.ts +1 -1
- package/dist/openapi/models/WorkflowCreateResponse.js +1 -1
- package/dist/openapi/models/WorkflowCreateSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/WorkflowCreateSuccessEnvelope.js +1 -1
- package/dist/openapi/models/WorkflowCreditSummary.d.ts +1 -1
- package/dist/openapi/models/WorkflowCreditSummary.js +1 -1
- package/dist/openapi/models/WorkflowDownloadResponse.d.ts +1 -1
- package/dist/openapi/models/WorkflowDownloadResponse.js +1 -1
- package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/WorkflowDownloadSuccessEnvelope.js +1 -1
- package/dist/openapi/models/WorkflowEdge.d.ts +1 -1
- package/dist/openapi/models/WorkflowEdge.js +1 -1
- package/dist/openapi/models/WorkflowExpiredResponse.d.ts +1 -1
- package/dist/openapi/models/WorkflowExpiredResponse.js +1 -1
- package/dist/openapi/models/WorkflowListResponse.d.ts +1 -1
- package/dist/openapi/models/WorkflowListResponse.js +1 -1
- package/dist/openapi/models/WorkflowListSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/WorkflowListSuccessEnvelope.js +1 -1
- package/dist/openapi/models/WorkflowPauseRequiredAction.d.ts +1 -1
- package/dist/openapi/models/WorkflowPauseRequiredAction.js +1 -1
- package/dist/openapi/models/WorkflowPausedDetail.d.ts +1 -1
- package/dist/openapi/models/WorkflowPausedDetail.js +1 -1
- package/dist/openapi/models/WorkflowPausedDetailLinks.d.ts +1 -1
- package/dist/openapi/models/WorkflowPausedDetailLinks.js +1 -1
- package/dist/openapi/models/WorkflowProcessing.d.ts +1 -1
- package/dist/openapi/models/WorkflowProcessing.js +1 -1
- package/dist/openapi/models/WorkflowRestoreResponse.d.ts +1 -1
- package/dist/openapi/models/WorkflowRestoreResponse.js +1 -1
- package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/WorkflowRestoreSuccessEnvelope.js +1 -1
- package/dist/openapi/models/WorkflowResumeResponse.d.ts +1 -1
- package/dist/openapi/models/WorkflowResumeResponse.js +1 -1
- package/dist/openapi/models/WorkflowResumeSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/WorkflowResumeSuccessEnvelope.js +1 -1
- package/dist/openapi/models/WorkflowSource.d.ts +1 -1
- package/dist/openapi/models/WorkflowSource.js +1 -1
- package/dist/openapi/models/WorkflowStatus.d.ts +1 -1
- package/dist/openapi/models/WorkflowStatus.js +1 -1
- package/dist/openapi/models/WorkflowStatusResponse.d.ts +1 -1
- package/dist/openapi/models/WorkflowStatusResponse.js +1 -1
- package/dist/openapi/models/WorkflowStatusSuccessEnvelope.d.ts +1 -1
- package/dist/openapi/models/WorkflowStatusSuccessEnvelope.js +1 -1
- package/dist/openapi/models/WorkflowSummary.d.ts +1 -1
- package/dist/openapi/models/WorkflowSummary.js +1 -1
- package/dist/openapi/models/WorkflowSummaryJob.d.ts +1 -1
- package/dist/openapi/models/WorkflowSummaryJob.js +1 -1
- package/dist/openapi/models/WorkflowWarning.d.ts +1 -1
- package/dist/openapi/models/WorkflowWarning.js +1 -1
- package/dist/openapi/models/WorkflowWarningSeverity.d.ts +1 -1
- package/dist/openapi/models/WorkflowWarningSeverity.js +1 -1
- package/dist/openapi/models/index.d.ts +1 -0
- package/dist/openapi/models/index.js +1 -0
- package/dist/openapi/runtime.d.ts +1 -1
- package/dist/openapi/runtime.js +1 -1
- package/openapi/README.md +1 -1
- package/openapi/api.yaml +165 -12
- package/operation-capabilities/operation-capabilities.json +1 -1
- package/operations/schemas/merge.yaml +6 -0
- package/package.json +3 -3
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -101,6 +101,7 @@ export * from './FeatureViolation.js';
|
|
|
101
101
|
export * from './GetProfile200Response.js';
|
|
102
102
|
export * from './GetProfile200ResponseData.js';
|
|
103
103
|
export * from './ImageEncodeCapabilities.js';
|
|
104
|
+
export * from './InputCeilingViolation.js';
|
|
104
105
|
export * from './JobDefinition.js';
|
|
105
106
|
export * from './JobDownload.js';
|
|
106
107
|
export * from './JobInputV2.js';
|
|
@@ -103,6 +103,7 @@ export * from './FeatureViolation.js';
|
|
|
103
103
|
export * from './GetProfile200Response.js';
|
|
104
104
|
export * from './GetProfile200ResponseData.js';
|
|
105
105
|
export * from './ImageEncodeCapabilities.js';
|
|
106
|
+
export * from './InputCeilingViolation.js';
|
|
106
107
|
export * from './JobDefinition.js';
|
|
107
108
|
export * from './JobDownload.js';
|
|
108
109
|
export * from './JobInputV2.js';
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
package/dist/openapi/runtime.js
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **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.231.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
package/openapi/README.md
CHANGED
|
@@ -10,7 +10,7 @@
|
|
|
10
10
|
- **Generator:** [openapi-generator-cli](https://openapi-generator.tech/) v7.21.0
|
|
11
11
|
(Docker image: `openapitools/openapi-generator-cli:v7.21.0`)
|
|
12
12
|
- **Generator preset:** `typescript-fetch`, models only
|
|
13
|
-
- **Files:**
|
|
13
|
+
- **Files:** 277
|
|
14
14
|
|
|
15
15
|
## Contents
|
|
16
16
|
|
package/openapi/api.yaml
CHANGED
|
@@ -103,7 +103,7 @@ info:
|
|
|
103
103
|
of truth instead of hardcoding magic numbers. A runtime
|
|
104
104
|
`GET /api/uploads/limits` endpoint for dynamic discovery
|
|
105
105
|
(per-tier / per-environment overrides) is a deferred follow-up.
|
|
106
|
-
version: 2.
|
|
106
|
+
version: 2.231.0
|
|
107
107
|
contact:
|
|
108
108
|
name: API Support
|
|
109
109
|
|
|
@@ -2149,15 +2149,52 @@ paths:
|
|
|
2149
2149
|
refused by the worker after acceptance until the upload prober
|
|
2150
2150
|
emits them; the probe schema declares them
|
|
2151
2151
|
(`UploadProbeMediaMetadata`, card `lGeDDi4V`), and once a probe
|
|
2152
|
-
carries one, the API refuses that difference at create too.
|
|
2153
|
-
|
|
2154
|
-
|
|
2155
|
-
|
|
2156
|
-
`
|
|
2157
|
-
|
|
2158
|
-
|
|
2159
|
-
|
|
2160
|
-
|
|
2152
|
+
carries one, the API refuses that difference at create too.
|
|
2153
|
+
**A video merge WAITS for its inputs' upload probes**, for every
|
|
2154
|
+
caller (owner decision 755, the decision-734 pattern): while any
|
|
2155
|
+
`upload` input is unprobed the create is answered `probe_pending`
|
|
2156
|
+
(`job_ref` = the merge job's ref); after
|
|
2157
|
+
`video.probe_wait_bound_seconds` from that upload
|
|
2158
|
+
(`schemas/anonymous-policy.yaml`), or once its probe lands `ok`
|
|
2159
|
+
without the measured field, that AXIS fails open and the worker
|
|
2160
|
+
gate is its only check for it. An axis that IS known is still
|
|
2161
|
+
decided at create: the summed upload sizes are known without a
|
|
2162
|
+
probe, so a non-uniform set over 500 MiB is refused
|
|
2163
|
+
`MERGE_OVER_LIMIT` (`size_bytes`) even when a duration is missing. That bound is what keeps a probe that
|
|
2164
|
+
never lands from making a create that never succeeds (the
|
|
2165
|
+
2026-09-24 ruling on api's `nmYdwHAH`, which admitted unprobed
|
|
2166
|
+
inputs outright, is superseded by 755 within the window). **An
|
|
2167
|
+
input that is an upstream job's output** has no upload probe and
|
|
2168
|
+
is admitted, as before.
|
|
2169
|
+
- Video merge over the short-form limit (owner decision 755, card
|
|
2170
|
+
`E7iYw68p`). A video merge whose inputs are NOT concat-uniform
|
|
2171
|
+
(a difference in a stream attribute listed under
|
|
2172
|
+
`input_uniformity` above, NOT mixed audio topology, which
|
|
2173
|
+
`short_form_concat` cannot run at any length and keeps
|
|
2174
|
+
`INPUTS_NOT_CONCAT_UNIFORM`) can only
|
|
2175
|
+
run `short_form_concat`, so when their measured total exceeds that
|
|
2176
|
+
class's `max_total_duration` (`PT5M`) or
|
|
2177
|
+
`max_total_input_size_bytes` (500 MiB) it is refused at create.
|
|
2178
|
+
`ValidationErrorEnvelope` with `error: "MERGE_OVER_LIMIT"`; one
|
|
2179
|
+
`details[]` entry `{operation: "merge", field: "inputs",
|
|
2180
|
+
message, message_key, message_params, ceiling}` where `ceiling`
|
|
2181
|
+
is `InputCeilingViolation` with `bound_by: "merge"`, `axis`
|
|
2182
|
+
`duration_seconds` (`actual` = the summed probe durations,
|
|
2183
|
+
rounded UP to whole seconds) or `size_bytes`, and `maximum` the
|
|
2184
|
+
class ceiling in the same unit. Duration is reported when both
|
|
2185
|
+
exceed. `message_key` is `error.merge.combined_too_long`
|
|
2186
|
+
(duration) or `error.merge.combined_too_large` (size);
|
|
2187
|
+
`message_params` repeat `ceiling`. Client copy: "These clips are
|
|
2188
|
+
too long to merge together: {actual} in total, the limit is
|
|
2189
|
+
{maximum}. Trim them, or use clips with the same format and
|
|
2190
|
+
resolution, which can be merged at any length." This REPLACES
|
|
2191
|
+
`INPUTS_NOT_CONCAT_UNIFORM` for such a set, because shortening is
|
|
2192
|
+
the remedy that works. **Precedence:** a request with
|
|
2193
|
+
`re_encode_mode: never` that cannot stream-copy is answered
|
|
2194
|
+
`REQUIRES_REENCODE` first (its remedy, `auto` or `always`, is
|
|
2195
|
+
the caller's choice and may change the outcome); only then is
|
|
2196
|
+
the total checked. A concat-uniform set over the limit is not
|
|
2197
|
+
refused: it routes `long_form_re_encode`.
|
|
2161
2198
|
|
|
2162
2199
|
**Branch dispatch via the `error_type` discriminator** (per
|
|
2163
2200
|
[ADR-0018](../docs/decisions/0018-universal-422-error-type-discriminator.md)).
|
|
@@ -2181,7 +2218,9 @@ paths:
|
|
|
2181
2218
|
gate is on and a job's upload has not yet been probed. The gate
|
|
2182
2219
|
is on for a guest's video create, and for EVERY caller's
|
|
2183
2220
|
video->GIF `convert` of an `upload` source (owner decision 734,
|
|
2184
|
-
so `GIF_TOO_LONG` is decided at create)
|
|
2221
|
+
so `GIF_TOO_LONG` is decided at create) and video `merge` of
|
|
2222
|
+
`upload` inputs (owner decision 755, so `MERGE_OVER_LIMIT` is
|
|
2223
|
+
decided at create); in every case only until
|
|
2185
2224
|
`video.probe_wait_bound_seconds` after the upload.
|
|
2186
2225
|
|
|
2187
2226
|
The prior 422 shape is otherwise preserved unchanged — the
|
|
@@ -2252,6 +2291,54 @@ paths:
|
|
|
2252
2291
|
details:
|
|
2253
2292
|
- field: "workflow_edges"
|
|
2254
2293
|
message: "Workflow edges form a cycle."
|
|
2294
|
+
merge_over_limit:
|
|
2295
|
+
summary: Non-uniform video merge over the short-form total (owner decision 755)
|
|
2296
|
+
value:
|
|
2297
|
+
success: false
|
|
2298
|
+
error_type: "validation_error"
|
|
2299
|
+
error: "MERGE_OVER_LIMIT"
|
|
2300
|
+
message: "These clips are too long to merge together."
|
|
2301
|
+
details:
|
|
2302
|
+
- operation: "merge"
|
|
2303
|
+
field: "inputs"
|
|
2304
|
+
message: "These clips are too long to merge together: 412 s in total, the limit is 300 s. Trim them, or use clips with the same format and resolution, which can be merged at any length."
|
|
2305
|
+
message_key: "error.merge.combined_too_long"
|
|
2306
|
+
message_params:
|
|
2307
|
+
axis: "duration_seconds"
|
|
2308
|
+
actual: 412
|
|
2309
|
+
maximum: 300
|
|
2310
|
+
bound_by: "merge"
|
|
2311
|
+
input_mime: "video/mp4"
|
|
2312
|
+
ceiling:
|
|
2313
|
+
axis: "duration_seconds"
|
|
2314
|
+
actual: 412
|
|
2315
|
+
maximum: 300
|
|
2316
|
+
bound_by: "merge"
|
|
2317
|
+
input_mime: "video/mp4"
|
|
2318
|
+
input_exceeds_ceiling:
|
|
2319
|
+
summary: An input over a declared ceiling, bound by a later operation (cxTBYffD)
|
|
2320
|
+
value:
|
|
2321
|
+
success: false
|
|
2322
|
+
error_type: "validation_error"
|
|
2323
|
+
error: "VALIDATION_FAILED"
|
|
2324
|
+
message: "Validation failed for operation 'thumbnail' on job ref 'a'."
|
|
2325
|
+
details:
|
|
2326
|
+
- operation: "thumbnail"
|
|
2327
|
+
field: "source"
|
|
2328
|
+
message: "Input file size (128232024 bytes) exceeds the maximum 104857600 bytes supported for operation 'thumbnail' on 'application/epub+zip'."
|
|
2329
|
+
message_key: "error.input_exceeds_ceiling"
|
|
2330
|
+
message_params:
|
|
2331
|
+
axis: "size_bytes"
|
|
2332
|
+
actual: 128232024
|
|
2333
|
+
maximum: 104857600
|
|
2334
|
+
bound_by: "thumbnail"
|
|
2335
|
+
input_mime: "application/epub+zip"
|
|
2336
|
+
ceiling:
|
|
2337
|
+
axis: "size_bytes"
|
|
2338
|
+
actual: 128232024
|
|
2339
|
+
maximum: 104857600
|
|
2340
|
+
bound_by: "thumbnail"
|
|
2341
|
+
input_mime: "application/epub+zip"
|
|
2255
2342
|
feature_not_available:
|
|
2256
2343
|
summary: Workflow references planned features
|
|
2257
2344
|
value:
|
|
@@ -7562,7 +7649,10 @@ components:
|
|
|
7562
7649
|
`re_encode_mode: never` and incompatible inputs; caller
|
|
7563
7650
|
resolves by switching to `re_encode_mode: auto` or `always`),
|
|
7564
7651
|
`CYCLIC_WORKFLOW_EDGES` (cyclic/self explicit `workflow_edges`,
|
|
7565
|
-
per `g8PPkbNu`).
|
|
7652
|
+
per `g8PPkbNu`). **Planned, not yet emitted:** `MERGE_OVER_LIMIT`
|
|
7653
|
+
(a non-uniform video merge over `short_form_concat`'s total;
|
|
7654
|
+
`details[].ceiling` carries the numbers, owner decision 755; the
|
|
7655
|
+
API emits it once xuVTM06N ships, see the taxonomy row).
|
|
7566
7656
|
⚠️ **`INVALID_OPTIONS` is NOT a create-time wire code**, though
|
|
7567
7657
|
earlier text here said it was and the example showed it: the
|
|
7568
7658
|
API has always sent `VALIDATION_FAILED` for option failures
|
|
@@ -7639,6 +7729,69 @@ components:
|
|
|
7639
7729
|
`{ "min": 1, "max": 100, "given": 200 }`). See
|
|
7640
7730
|
`ErrorEnvelope.message_params`. Excludes cost
|
|
7641
7731
|
numbers.
|
|
7732
|
+
ceiling:
|
|
7733
|
+
$ref: '#/components/schemas/InputCeilingViolation'
|
|
7734
|
+
|
|
7735
|
+
InputCeilingViolation:
|
|
7736
|
+
type: object
|
|
7737
|
+
additionalProperties: false
|
|
7738
|
+
description: |
|
|
7739
|
+
Present on a `details[]` entry when the entry reports a measured
|
|
7740
|
+
quantity exceeding a declared ceiling, as data (cards
|
|
7741
|
+
[`cxTBYffD`](https://trello.com/c/cxTBYffD), `E7iYw68p`). It carries
|
|
7742
|
+
what `message` says in prose, so a client can show "22.4 MB, limit
|
|
7743
|
+
20 MiB" and branch on "too large" without reading English. The
|
|
7744
|
+
entry's `message_params` repeat these fields for the localised text.
|
|
7745
|
+
|
|
7746
|
+
Two uses today, told apart by the entry's `message_key`:
|
|
7747
|
+
- `error.input_exceeds_ceiling`: ONE input over an unbanded group's
|
|
7748
|
+
`max_input_size_bytes`, a pixel ceiling, or a duration ceiling.
|
|
7749
|
+
- `error.merge.combined_too_long` / `error.merge.combined_too_large`:
|
|
7750
|
+
the COMBINED inputs of a non-uniform video merge over
|
|
7751
|
+
`short_form_concat`'s total (`MERGE_OVER_LIMIT`, owner decision
|
|
7752
|
+
755). `axis` is the total's axis and `bound_by` is `merge`.
|
|
7753
|
+
|
|
7754
|
+
A job that merely routes to a higher processing class is not an
|
|
7755
|
+
error here: an escalation that finds no class able to take the input
|
|
7756
|
+
is `ProcessingClassExceedsBandResponse`, never this.
|
|
7757
|
+
|
|
7758
|
+
**Optional and additive.** Its absence on a size refusal means the
|
|
7759
|
+
server predates this field; fall back to `message`. Do not read
|
|
7760
|
+
absence as "not a ceiling refusal".
|
|
7761
|
+
required:
|
|
7762
|
+
- axis
|
|
7763
|
+
- actual
|
|
7764
|
+
- maximum
|
|
7765
|
+
- bound_by
|
|
7766
|
+
properties:
|
|
7767
|
+
axis:
|
|
7768
|
+
type: string
|
|
7769
|
+
x-string-vocabulary: open
|
|
7770
|
+
description: |
|
|
7771
|
+
Which quantity exceeded its ceiling. Values today:
|
|
7772
|
+
`size_bytes`, `pixels`, `duration_seconds`. The set is open:
|
|
7773
|
+
treat an unknown axis as "input too large" and show `message`.
|
|
7774
|
+
actual:
|
|
7775
|
+
type: integer
|
|
7776
|
+
format: int64
|
|
7777
|
+
minimum: 0
|
|
7778
|
+
description: The input's measured value on `axis` (bytes, pixels, or whole seconds rounded UP).
|
|
7779
|
+
maximum:
|
|
7780
|
+
type: integer
|
|
7781
|
+
format: int64
|
|
7782
|
+
minimum: 0
|
|
7783
|
+
description: The binding ceiling on `axis`, in the same unit as `actual`.
|
|
7784
|
+
bound_by:
|
|
7785
|
+
type: string
|
|
7786
|
+
description: |
|
|
7787
|
+
The operation whose ceiling binds. **Not always the operation
|
|
7788
|
+
that ingests the file**: in a `[compress, thumbnail]` job the
|
|
7789
|
+
thumbnail's tighter ceiling can refuse a file `compress`
|
|
7790
|
+
accepts, and then this is `thumbnail`. The smallest applicable
|
|
7791
|
+
ceiling across the job's operations is the one reported.
|
|
7792
|
+
input_mime:
|
|
7793
|
+
type: string
|
|
7794
|
+
description: The input's MIME type, as the ceiling was looked up.
|
|
7642
7795
|
|
|
7643
7796
|
AuthRejectionEnvelope:
|
|
7644
7797
|
type: object
|
|
@@ -200,6 +200,12 @@ operation:
|
|
|
200
200
|
ceiling_basis: # 607(d): proven at the declared value, or not yet (FORMAT.md §ceiling_basis)
|
|
201
201
|
max_total_input_size_bytes: proven
|
|
202
202
|
max_total_duration: proven
|
|
203
|
+
# OWNER DECISION 755 (E7iYw68p): a NON-UNIFORM set can only run this
|
|
204
|
+
# class (long_form_re_encode refuses it), so over these totals it is
|
|
205
|
+
# refused at create with MERGE_OVER_LIMIT and the numbers
|
|
206
|
+
# (details[].ceiling), instead of INPUTS_NOT_CONCAT_UNIFORM. The API
|
|
207
|
+
# waits for the inputs' probes to measure the total. A uniform set
|
|
208
|
+
# over them routes long_form_re_encode as before.
|
|
203
209
|
constraints:
|
|
204
210
|
max_total_duration: "PT5M"
|
|
205
211
|
max_total_input_size_bytes: 524288000 # 500 MiB combined (the stream-copy ceiling; was 1 GiB)
|
package/package.json
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@giveitsmaller/contracts",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"description": "Generated contract types for GISL (Give It Smaller). Generated from compression_contracts spec v2.
|
|
5
|
-
"gislContractsSpec": "v2.
|
|
3
|
+
"version": "0.93.0",
|
|
4
|
+
"description": "Generated contract types for GISL (Give It Smaller). Generated from compression_contracts spec v2.231.0.",
|
|
5
|
+
"gislContractsSpec": "v2.231.0",
|
|
6
6
|
"license": "Apache-2.0",
|
|
7
7
|
"homepage": "https://docs.giveitsmaller.com",
|
|
8
8
|
"bugs": {
|