@giveitsmaller/contracts 0.39.0 → 0.41.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/accepted-options/accepted-options.json +3 -11
- package/accepted-options/image-output-routes.json +1 -1
- package/availability/availability.json +53 -17
- 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/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/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/CallbackEventType.d.ts +1 -1
- package/dist/openapi/models/CallbackEventType.js +1 -1
- package/dist/openapi/models/ChangePasswordRequest.d.ts +1 -1
- package/dist/openapi/models/ChangePasswordRequest.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/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/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/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/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/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/ForgotPasswordRequest.d.ts +1 -1
- package/dist/openapi/models/ForgotPasswordRequest.js +1 -1
- package/dist/openapi/models/ImageEncodeCapabilities.d.ts +1 -1
- package/dist/openapi/models/ImageEncodeCapabilities.js +1 -1
- 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/LoginUserRequest.d.ts +1 -1
- package/dist/openapi/models/LoginUserRequest.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/OperationDefinition.d.ts +1 -1
- package/dist/openapi/models/OperationDefinition.js +1 -1
- package/dist/openapi/models/OperationDownload.d.ts +24 -1
- package/dist/openapi/models/OperationDownload.js +5 -1
- package/dist/openapi/models/OperationInputModel.d.ts +1 -1
- package/dist/openapi/models/OperationInputModel.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/OptionSchema.d.ts +1 -1
- package/dist/openapi/models/OptionSchema.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/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/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/ResetPasswordRequest.d.ts +1 -1
- package/dist/openapi/models/ResetPasswordRequest.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/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/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 +1 -1
- package/dist/openapi/models/ValidationErrorEnvelope.js +1 -1
- package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.d.ts +1 -1
- package/dist/openapi/models/ValidationErrorEnvelopeDetailsInner.js +1 -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/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/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/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/runtime.d.ts +1 -1
- package/dist/openapi/runtime.js +1 -1
- package/dist/operations/convert.metadata.js +4 -8
- package/openapi/api.yaml +20 -1
- package/operation-capabilities/operation-capabilities.json +1 -1
- package/operations/schemas/convert.yaml +39 -22
- package/package.json +1 -1
|
@@ -742,13 +742,9 @@
|
|
|
742
742
|
"width"
|
|
743
743
|
],
|
|
744
744
|
"mp4": [
|
|
745
|
-
"auto_orient",
|
|
746
|
-
"color_profile",
|
|
747
745
|
"fit",
|
|
748
|
-
"height",
|
|
749
746
|
"metadata",
|
|
750
|
-
"output_format"
|
|
751
|
-
"width"
|
|
747
|
+
"output_format"
|
|
752
748
|
],
|
|
753
749
|
"png": [
|
|
754
750
|
"auto_orient",
|
|
@@ -769,13 +765,9 @@
|
|
|
769
765
|
"width"
|
|
770
766
|
],
|
|
771
767
|
"webm": [
|
|
772
|
-
"auto_orient",
|
|
773
|
-
"color_profile",
|
|
774
768
|
"fit",
|
|
775
|
-
"height",
|
|
776
769
|
"metadata",
|
|
777
|
-
"output_format"
|
|
778
|
-
"width"
|
|
770
|
+
"output_format"
|
|
779
771
|
],
|
|
780
772
|
"webp": [
|
|
781
773
|
"auto_orient",
|
|
@@ -1117,5 +1109,5 @@
|
|
|
1117
1109
|
}
|
|
1118
1110
|
}
|
|
1119
1111
|
},
|
|
1120
|
-
"schema_version": "2.
|
|
1112
|
+
"schema_version": "2.117.0"
|
|
1121
1113
|
}
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
{
|
|
2
|
-
"capabilities_version":
|
|
2
|
+
"capabilities_version": 136,
|
|
3
3
|
"endpoints": {
|
|
4
4
|
"DELETE /api/auth/api-keys/{apiKeyId}": {
|
|
5
5
|
"auth": "required",
|
|
@@ -2251,7 +2251,8 @@
|
|
|
2251
2251
|
"image/bmp",
|
|
2252
2252
|
"image/vnd.microsoft.icon",
|
|
2253
2253
|
"image/avif",
|
|
2254
|
-
"image/heic"
|
|
2254
|
+
"image/heic",
|
|
2255
|
+
"image/heif"
|
|
2255
2256
|
],
|
|
2256
2257
|
"options": {
|
|
2257
2258
|
"auto_orient": {
|
|
@@ -2374,6 +2375,9 @@
|
|
|
2374
2375
|
},
|
|
2375
2376
|
"image/heic": {
|
|
2376
2377
|
"availability": "beta"
|
|
2378
|
+
},
|
|
2379
|
+
"image/heif": {
|
|
2380
|
+
"availability": "beta"
|
|
2377
2381
|
}
|
|
2378
2382
|
}
|
|
2379
2383
|
},
|
|
@@ -2386,7 +2390,17 @@
|
|
|
2386
2390
|
"auto_orient": {
|
|
2387
2391
|
"availability": "planned",
|
|
2388
2392
|
"default": true,
|
|
2389
|
-
"
|
|
2393
|
+
"depends_on": {
|
|
2394
|
+
"output_format": [
|
|
2395
|
+
"jpeg",
|
|
2396
|
+
"png",
|
|
2397
|
+
"webp",
|
|
2398
|
+
"avif",
|
|
2399
|
+
"gif",
|
|
2400
|
+
"tiff"
|
|
2401
|
+
]
|
|
2402
|
+
},
|
|
2403
|
+
"description": "Bake EXIF orientation into the pixels (format-change route) \u2014 mirrors compress.image.auto_orient. `planned`. SCOPED via depends_on to the STILL-IMAGE targets only \u2014 the video targets (mp4/webm) carry no EXIF orientation. Declared HERE so the API re-validates the rewritten Output op.",
|
|
2390
2404
|
"honored_on": [
|
|
2391
2405
|
"format_change"
|
|
2392
2406
|
],
|
|
@@ -2406,7 +2420,17 @@
|
|
|
2406
2420
|
"color_profile": {
|
|
2407
2421
|
"availability": "planned",
|
|
2408
2422
|
"default": "keep",
|
|
2409
|
-
"
|
|
2423
|
+
"depends_on": {
|
|
2424
|
+
"output_format": [
|
|
2425
|
+
"jpeg",
|
|
2426
|
+
"png",
|
|
2427
|
+
"webp",
|
|
2428
|
+
"avif",
|
|
2429
|
+
"gif",
|
|
2430
|
+
"tiff"
|
|
2431
|
+
]
|
|
2432
|
+
},
|
|
2433
|
+
"description": "ICC colour-profile handling (format-change route) \u2014 mirrors compress.image.color_profile. `keep` (default)/`srgb`/`strip`. `planned`. SCOPED via depends_on to the STILL-IMAGE targets only \u2014 the video targets (mp4/webm) carry no ICC, so color_profile is not accepted for a gif\u2192video output (it would be inert). Declared HERE so the API re-validates the rewritten Output op.",
|
|
2410
2434
|
"honored_on": [
|
|
2411
2435
|
"format_change"
|
|
2412
2436
|
],
|
|
@@ -2424,7 +2448,7 @@
|
|
|
2424
2448
|
"logic": "or",
|
|
2425
2449
|
"width": "set"
|
|
2426
2450
|
},
|
|
2427
|
-
"description": "Resize mode. `max` (default) = fit within bounds, preserving aspect ratio and never upscaling; `crop`/`scale` = exact dimensions. Applies only when width or height is set.",
|
|
2451
|
+
"description": "Resize mode. `max` (default) = fit within bounds, preserving aspect ratio and never upscaling; `crop`/`scale` = exact dimensions. Applies only when width or height is set \u2014 and width/height are still-image-only here, so fit is transitively unreachable for the mp4/webm video targets.",
|
|
2428
2452
|
"honored_on": [
|
|
2429
2453
|
"format_change"
|
|
2430
2454
|
],
|
|
@@ -2436,7 +2460,17 @@
|
|
|
2436
2460
|
]
|
|
2437
2461
|
},
|
|
2438
2462
|
"height": {
|
|
2439
|
-
"
|
|
2463
|
+
"depends_on": {
|
|
2464
|
+
"output_format": [
|
|
2465
|
+
"jpeg",
|
|
2466
|
+
"png",
|
|
2467
|
+
"webp",
|
|
2468
|
+
"avif",
|
|
2469
|
+
"gif",
|
|
2470
|
+
"tiff"
|
|
2471
|
+
]
|
|
2472
|
+
},
|
|
2473
|
+
"description": "Resize-inside-Output: target height in pixels (1-16384; width*height <= max_output_pixels). Scoped to the still-image targets \u2014 resized gif\u2192video unproven, see `width`.",
|
|
2440
2474
|
"honored_on": [
|
|
2441
2475
|
"format_change"
|
|
2442
2476
|
],
|
|
@@ -2458,15 +2492,7 @@
|
|
|
2458
2492
|
]
|
|
2459
2493
|
},
|
|
2460
2494
|
"output_format": {
|
|
2461
|
-
"description": "Target format. The still-image targets (jpeg/png/webp/avif/gif/tiff) take the first frame / rasterise
|
|
2462
|
-
"per_value_availability": {
|
|
2463
|
-
"mp4": {
|
|
2464
|
-
"availability": "planned"
|
|
2465
|
-
},
|
|
2466
|
-
"webm": {
|
|
2467
|
-
"availability": "planned"
|
|
2468
|
-
}
|
|
2469
|
-
},
|
|
2495
|
+
"description": "Target format. The still-image targets (jpeg/png/webp/avif/gif/tiff) take the first frame / rasterise. `mp4` / `webm` are the GIF\u2192VIDEO transcode targets \u2014 the animated GIF becomes a muted, play-once video (`mp4` = H.264 / yuv420p / +faststart, plays everywhere; `webm` = VP9, smaller). STABLE \u2014 worker-proven on staging (lambdas PR #268, deployed git-6783cb9: gif\u2192mp4 ~70% smaller / gif\u2192webm ~84% smaller, valid containers + worker-set Content-Type, real decode-every-frame transcode). GIFs are silent (no audio stream); the GIF infinite-loop becomes a playback attribute (`<video loop>`) the player sets, NOT baked into the file.",
|
|
2470
2496
|
"required": true,
|
|
2471
2497
|
"type": "enum",
|
|
2472
2498
|
"values": [
|
|
@@ -2498,7 +2524,17 @@
|
|
|
2498
2524
|
"type": "integer"
|
|
2499
2525
|
},
|
|
2500
2526
|
"width": {
|
|
2501
|
-
"
|
|
2527
|
+
"depends_on": {
|
|
2528
|
+
"output_format": [
|
|
2529
|
+
"jpeg",
|
|
2530
|
+
"png",
|
|
2531
|
+
"webp",
|
|
2532
|
+
"avif",
|
|
2533
|
+
"gif",
|
|
2534
|
+
"tiff"
|
|
2535
|
+
]
|
|
2536
|
+
},
|
|
2537
|
+
"description": "Resize-inside-Output: target width in pixels (1-16384; width*height <= max_output_pixels). SCOPED via depends_on to the STILL-IMAGE targets \u2014 the bare gif\u2192video transcode proof (#268) did NOT prove resize-while-transcoding, so width/height are not accepted for the mp4/webm video targets (prove-before- flip; else the API would accept+route+bill a resized gif\u2192video the worker may not honour). Un-scope per-target when lambdas proves resized gif\u2192video.",
|
|
2502
2538
|
"honored_on": [
|
|
2503
2539
|
"format_change"
|
|
2504
2540
|
],
|
|
@@ -4568,7 +4604,7 @@
|
|
|
4568
4604
|
"sole_op": true
|
|
4569
4605
|
}
|
|
4570
4606
|
},
|
|
4571
|
-
"schema_version": "2.
|
|
4607
|
+
"schema_version": "2.117.0",
|
|
4572
4608
|
"source_commit": null,
|
|
4573
4609
|
"user_tier": null,
|
|
4574
4610
|
"workflow_features": {
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
* GISL Compression API
|
|
3
3
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
4
4
|
*
|
|
5
|
-
* The version of the OpenAPI document: 2.
|
|
5
|
+
* The version of the OpenAPI document: 2.117.0
|
|
6
6
|
*
|
|
7
7
|
*
|
|
8
8
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* GISL Compression API
|
|
5
5
|
* REST API for the GISL (Give It Smaller) file compression and processing service. **Architecture:** - Upload files to get a `file_id` - Create workflows referencing uploaded files with operations (compress, thumbnail, image_watermark, text_watermark, merge, archive, convert, custom_luma, audio_overlay, audio_watermark) - Poll status, stream SSE events, or receive webhook callbacks - Download results per operation output **Response envelope:** All mutation and query endpoints return `{ success: true, data: {...} }` on success and `{ success: false, error: \"...\", details: [...] }` on failure. Exceptions: `GET /api/operations/schema` returns raw JSON (per-tier private caching with ETag revalidation per ADR-0002 + I3), health probes return flat objects, and `POST /api/contact` returns 204 with no body. **Availability metadata.** This spec uses the `x-availability` vendor extension as **decorative documentation only**. Per [ADR-0001](../docs/decisions/0001-contract-first-availability.md) §1.5, the runtime endpoint `GET /api/operations/schema` (ticket I3) is the authoritative source; the sidecar `availability.json` (ticket I3b) is the authoritative companion (generated, never hand-edited; CI cross-checks runtime ⇄ sidecar). SDKs MUST NOT depend on `x-availability` reaching generated code — code-generators that surface vendor extensions may emit it as documentation, but consumers read availability from the runtime endpoint, not from the generated bindings. The 5-value vocabulary (`stable | beta | experimental | planned | deprecated`) is defined in the `AvailabilityValue` schema. See `schemas/FORMAT.md` §Availability Taxonomy for the operational rules (parser obligation: absent = stable; per-enum-value granularity is the `per_value_availability` primitive landed via ticket I17). **Localisation (per ticket [I26](https://trello.com/c/rcnqwgI4)).** Error responses + paused/blocked workflow statuses carry a localised human-readable `message` alongside a stable, never-localised `message_key`. Machine-readable fields (`error`, enum values, status codes) stay canonical English. - **Currently committed locales:** `en-GB` only (per ticket [`4GKyuYo6`](https://trello.com/c/4GKyuYo6)). The I26 carrier shape (`Accept-Language` + `Content-Language` + `Vary` headers + `locale` envelope field + `message_key` + `message_params`) is stable and exercised; the **catalog** of translated `message` strings is en-GB-only at runtime today. Additional locales (e.g. `pt-PT`) will be advertised by name when their catalogs ship — the request/response carrier shape does NOT change when a new locale lands. Treat unrequested locales as \"machine-code + `message_key` path is committed; localised `message` prose is not\" until this prose enumerates them by name. - **Request:** `Accept-Language` header per RFC 9110 §12.5.4 (q-value negotiation supported). The server selects the best-match locale from its supported list; falls back to `en-GB` when no match — which, until additional catalogs land, is every non-`en-GB` `Accept-Language`. - **Response:** `Content-Language: <locale>` echo on every localised response; `Vary: Accept-Language` on every response (CDN/cache correctness — different `Accept-Language` requests produce different responses). `Vary` is emitted unconditionally so the header contract does not flip when a second locale ships. - **Fallback locale:** `en-GB` (also the canonical locale for `message_key` translations and English `message` prose). - **SDK guidance:** switch on `error` (machine code) for typed error branches; surface `message_key` to client-side i18n catalogs (SDK companion work tracked at X19, cross-repo); display `message` for end-user UI; **never parse `message` for control flow** — it changes per locale. Carrier shape lives on `ErrorEnvelope` (envelope-level optional `message_key` + `message` + `locale` + `message_params`) and `ValidationErrorEnvelope` (also per-`details[]` entry). Existing 402 / 403 / 422 envelopes (`BalanceExhaustedResponse`, `FeatureNotAvailableResponse`, `FeatureTierRestrictedResponse`, `WorkflowPausedDetail`) inherit the convention. **Upload thresholds (per tickets [u0ar7Yye](https://trello.com/c/u0ar7Yye) + [58nBQLWQ](https://trello.com/c/58nBQLWQ)).** Canonical upload constants (single-shot cap, multipart chunk size, multipart concurrency default, multipart first-chunk size) live on the `UploadThresholds` schema with `const:`-pinned values. SDK generators emit these as typed binding constants so frontend / API / SDKs reference one source of truth instead of hardcoding magic numbers. A runtime `GET /api/uploads/limits` endpoint for dynamic discovery (per-tier / per-environment overrides) is a deferred follow-up.
|
|
6
6
|
*
|
|
7
|
-
* The version of the OpenAPI document: 2.
|
|
7
|
+
* The version of the OpenAPI document: 2.117.0
|
|
8
8
|
*
|
|
9
9
|
*
|
|
10
10
|
* NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
|