passbolt/passbolt_api · error · SubscriptionFormatException

The subscription key format is not valid.

Error message

The subscription key format is not valid.

What it means

SubscriptionsTable::handleErrors() throws SubscriptionFormatException when the Subscription entity has a validation error on the 'value' field, meaning the submitted subscription key string failed entity-level validation before any cryptographic check. The original validation messages are attached to the exception.

Solutions

  1. Submit the key verbatim as a single base64 string from passbolt; check length and no internal newlines.
  2. Sanitize input: trim and strip whitespace before createOrUpdate.
  3. Locally validate: `echo '<key>' | base64 -d | head -1` must show '-----BEGIN PGP MESSAGE-----'.
  4. Read the attached validation messages in the exception for the precise rule that failed.

Example fix

// before
$asciiKey = file_get_contents('key.txt'); // contains newlines
$this->Subscriptions->createOrUpdate($uac, $asciiKey);
// after
$asciiKey = preg_replace('/\s+/', '', trim(file_get_contents('key.txt')));
$this->Subscriptions->createOrUpdate($uac, $asciiKey);
Defensive patterns

Strategy: validation

Validate before calling

$clean = preg_replace('/\s+/', '', trim($asciiKey));
if ($clean === '' || base64_decode($clean, true) === false) {
    throw new \InvalidArgumentException('Subscription key must be valid base64');
}
$this->Subscriptions->createOrUpdate($uac, $clean);

Try / catch

try {
    $this->Subscriptions->createOrUpdate($uac, $asciiKey);
} catch (SubscriptionFormatException $e) {
    Log::error('Key format rejected: ' . json_encode($e->getErrors()));
}

Prevention

When it happens

Trigger: Calling create() or update() with a $asciiKey that fails the Subscription entity's 'value' validation rules — e.g. not valid base64, not a parsable armored signed message, or empty — so newEntity(['value' => $asciiKey]) carries errors.

Common situations: Pasting a truncated or whitespace-mangled key; submitting the raw armored block instead of base64; newline corruption from copying through HTML email; CLI heredoc quoting stripping characters.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors


AI-assisted analysis of passbolt/passbolt_api@31c1bbc10f (2026-09-17). Data as JSON: /api/errors/1a1507c0dc4f7809. Report an issue: GitHub.

Appendix: source

Thrown at plugins/PassboltEe/Subscription/src/Model/Table/SubscriptionsTable.php:213

        } else {
            return $this->create($asciiKey, $uac);
        }
    }

    /**
     * Throw Exceptions if errors were found in the validation.
     *
     * @param \Passbolt\Subscription\Model\Entity\Subscription $subscription Subscription entity to be validated.
     * @return void
     * @throws \Passbolt\Subscription\Error\Exception\Subscriptions\SubscriptionFormatException
     * @throws \Passbolt\Subscription\Error\Exception\Subscriptions\SubscriptionValidationException
     * @throws \Passbolt\Subscription\Error\Exception\Subscriptions\SubscriptionException
     */
    public function handleErrors(Subscription $subscription): void
    {
        $formatError = $subscription->getError('value');
        if ($formatError) {
            throw new SubscriptionFormatException(
                __('The subscription key format is not valid.'),
                $formatError
            );
        }
    }

    /**
     * @return string
     */
    public function getProperty(): string
    {
        return OrganizationSetting::UUID_NAMESPACE . 'ee.subscription';
    }

    /**
     * @return string
     */
    public function getPropertyId(): string

View on GitHub (pinned to 31c1bbc10f)