Redeliveries.CreateAsync sends date_from with sub-second precision, causing 400 Bad Request

[Greybird]

Checklist

• I have looked into the Readme and have not found a suitable solution or answer.
• I have looked into the API documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have searched the Auth0 Community forums and have not found a suitable solution or answer.
• I agree to the terms within the Auth0 Code of Conduct.

Description

Calling client.EventStreams.Redeliveries.CreateAsync() with a DateFrom value always results in a 400 Bad Request from the Auth0 Management API.

The CreateEventStreamRedeliveryRequestContent.DateFrom property is typed as DateTime?. When serialized by the SDK's JsonUtils.Serialize, it produces an ISO 8601 string with sub-second precision (24 characters), e.g. 2026-07-01T00:00:00.000Z.

However, the POST /api/v2/event-streams/{id}/redeliver endpoint enforces a maximum of 20 characters for the date_from field, rejecting sub-second precision:

{
  "statusCode": 400,
  "error": "Bad Request",
  "message": "Payload validation error: 'String is too long (24 chars), maximum 20' on property date_from (An RFC-3339 date-time for redelivery start, inclusive. Does not allow sub-second precision).",
  "errorCode": "invalid_body"
}

The expected format is yyyy-MM-ddTHH:mm:ssZ (exactly 20 characters). Since DateFrom is a DateTime? and serialization is handled internally by the SDK, callers have no way to control the format — the method is unusable.

Expected: The SDK should serialize DateFrom (and DateTo) in yyyy-MM-ddTHH:mm:ssZ format, truncating sub-second precision before sending the request. This could be done via a custom JsonConverter on the property or by formatting in the client before serialization.

Related: This is the same endpoint family as Deliveries.ListAsync, which has a separate deserialization bug — see #1065.

Reproduction

Reproduces 100% of the time — any DateTime value with sub-second precision triggers it (and System.Text.Json always serializes with milliseconds).

1. Create a ManagementClient with valid credentials and scopes including update:event_deliveries.
2. Call Redeliveries.CreateAsync with any DateFrom:

await client.EventStreams.Redeliveries.CreateAsync(
    "est_your_stream_id",
    new CreateEventStreamRedeliveryRequestContent
    {
        DateFrom = new DateTime(2026, 7, 1, 0, 0, 0, DateTimeKind.Utc),
        Statuses = [EventStreamDeliveryStatusEnum.Failed]
    });

3. Observe the 400 response:

Auth0.ManagementApi.ManagementApiException
  StatusCode: 400
  RawResponse: {"statusCode":400,"error":"Bad Request","message":"Payload validation error: 'String is too long (24 chars), maximum 20' on property date_from (An RFC-3339 date-time for redelivery start, inclusive. Does not allow sub-second precision).","errorCode":"invalid_body"}

Note: even DateTime values with zero milliseconds are serialized as 2026-07-01T00:00:00.000Z (24 chars) by System.Text.Json.

Additional context

No response

auth0.net version

9.0.0

.NET version

10.0

[kailash-b]

Hi @Greybird 👋

Thanks for raising this.

Our Management SDKs are Fern generated.
We are checking if we can avoid custom-code and instead get this issue fixed at generation.

In case, we are unable to fix this at code-generation, we will review the PR you have already submitted.

We will keep this thread posted with any updates.
Thanks for your patience 🤝

[Greybird]

Hello @kailash-b ,
Thanks for the feedback, looking forward to get some news.
Just to clarify, the PR comes from an unrelated user.