bitwarden/server · error · BadRequestException

You cannot have a Send with an expiration date in the past.

Error message

You cannot have a Send with an expiration date in the past. Adjust the expiration date and try again.

What it means

Thrown as BadRequestException (HTTP 400) from SendRequestModel.ValidateEdit() when ExpirationDate is set and is at or before (now + 1 minute). During edits this can fire even though creation succeeded — e.g. editing an old Send whose expiration has since passed. Mirrors [475] but in the edit-validation path.

Source

Thrown at src/Api/Tools/Models/Request/SendRequestModel.cs:236

            if (DeletionDate.Value <= nowPlus1Minute)
            {
                throw new BadRequestException("You cannot have a Send with a deletion date in the past. " +
                                              "Adjust the deletion date and try again.");
            }

            if (DeletionDate.Value > now.AddDays(31))
            {
                throw new BadRequestException("You cannot have a Send with a deletion date that far " +
                                              "into the future. Adjust the Deletion Date to a value less than 31 days from now " +
                                              "and try again.");
            }
        }

        if (ExpirationDate.HasValue)
        {
            if (ExpirationDate.Value <= nowPlus1Minute)
            {
                throw new BadRequestException("You cannot have a Send with an expiration date in the past. " +
                                              "Adjust the expiration date and try again.");
            }

            if (DeletionDate.HasValue && ExpirationDate.Value > DeletionDate.Value)
            {
                throw new BadRequestException(
                    "You cannot have a Send with an expiration date greater than the deletion date. " +
                    "Adjust the expiration date and try again.");
            }
        }
    }

    private Send ToSendBase(Send existingSend, ISendAuthorizationService authorizationService)
    {
        existingSend.Key = Key;
        existingSend.ExpirationDate = ExpirationDate;
        existingSend.DeletionDate = DeletionDate!.Value;
        existingSend.MaxAccessCount = MaxAccessCount;

View on GitHub (pinned to e93b962371)

Solutions

  1. Set ExpirationDate to a future value or remove it (null) to disable expiration.
  2. Send ExpirationDate in UTC and respect the 1-minute buffer.
  3. If the Send is already expired, create a new one rather than editing.
  4. Refresh the expiration field in the edit UI to a future time before saving.

Example fix

// before: editing an expired send
PUT /sends/{id}  body: { ..., "expirationDate": "2020-01-01T00:00:00Z" } -> 400

// after
PUT /sends/{id}  body: { ..., "expirationDate": "2026-12-31T00:00:00Z" }
Defensive patterns

Strategy: validation

Validate before calling

// Client: validate expiration on edit
var now = DateTime.UtcNow;
if (model.ExpirationDate.HasValue && model.ExpirationDate.Value <= now.AddMinutes(1)) {
    // either push it forward or clear it
    model.ExpirationDate = null;
}
await client.PutAsync($"sends/{id}", JsonContent.Create(model));

Prevention

When it happens

Trigger: PUT /sends/{id} (or create) where ExpirationDate is non-null and <= DateTime.UtcNow.AddMinutes(1). Common when editing a Send that is about to expire or already expired but not yet deleted.

Common situations: Editing an aging Send whose expiration has elapsed; client clock skew; timezone bug; re-saving a Send near its expiration boundary.

Related errors


AI-assisted analysis of bitwarden/server@e93b962371 (2026-08-13). Data as JSON: /api/errors/38c526b685293bb9. Report an issue: GitHub.