bitwarden/server · error · BadRequestException

You cannot create a Send that is already expired. Adjust the

Error message

You cannot create a Send that is already expired. Adjust the expiration date and try again.

What it means

Thrown as BadRequestException (HTTP 400) from SendRequestModel.ValidateCreation() when the request's ExpirationDate is set and is at or before (now + 1 minute). The 1-minute buffer tolerates client/server clock skew. New Sends cannot be created already expired.

Source

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

        }

        return existingSend;
    }

    /// <summary>
    /// Validates that the request is internally consistent for send creation.
    /// </summary>
    /// <exception cref="BadRequestException">
    /// Thrown when the send's expiration date has already expired.
    /// </exception>
    public void ValidateCreation()
    {
        var now = DateTime.UtcNow;
        // Add 1 minute for a sane buffer and client clock float
        var nowPlus1Minute = now.AddMinutes(1);
        if (ExpirationDate.HasValue && ExpirationDate.Value <= nowPlus1Minute)
        {
            throw new BadRequestException("You cannot create a Send that is already expired. " +
                                          "Adjust the expiration date and try again.");
        }

        ValidateEdit();
    }

    /// <summary>
    /// Validates that the request is internally consistent for send administration.
    /// </summary>
    /// <exception cref="BadRequestException">
    /// Thrown when the send's deletion date has already expired or when its
    /// expiration occurs after its deletion.
    /// </exception>
    public void ValidateEdit()
    {
        var now = DateTime.UtcNow;
        // Add 1 minute for a sane buffer and client clock float
        var nowPlus1Minute = now.AddMinutes(1);

View on GitHub (pinned to e93b962371)

Solutions

1. Set ExpirationDate to a value comfortably in the future (e.g. now + 1 hour or more).
2. Send ExpirationDate in UTC (DateTime.UtcNow) to avoid timezone drift.
3. Account for the 1-minute skew buffer when computing the value.
4. If the Send should never expire, omit ExpirationDate (null).

Example fix

// before
model.ExpirationDate = DateTime.Now.AddSeconds(-5); // local, already past -> 400

// after
model.ExpirationDate = DateTime.UtcNow.AddHours(1); // UTC, future

// Client: validate expiration against the server's skew rule before create
var now = DateTime.UtcNow;
if (model.ExpirationDate.HasValue && model.ExpirationDate.Value <= now.AddMinutes(1)) {
    ShowUser("Expiration date must be in the future.");
    return;
}
await client.PostAsync("sends", JsonContent.Create(model));

When it happens

Trigger: POST /sends or POST /sends/file/v2 with ExpirationDate <= DateTime.UtcNow.AddMinutes(1). ValidateCreation() is called at the top of both creation actions.

Common situations: Client clock ahead of server so the chosen expiration is already in the past server-side; user picks 'expire now'; timezone mishandling sending local time as UTC; long network delay between picking and submitting.

Related errors

• You cannot have a Send with an expiration date in the past.
• You cannot have a Send with an expiration date greater than
• You cannot have a Send with a deletion date in the past. Adj
• You cannot have a Send with a deletion date that far into th
• Could not locate send

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