TLS 1.3 0-RTT lets a returning client send an encrypted request before the new handshake finishes. It can reduce waiting, but early data has weaker replay guarantees: the same request might be processed on another connection. For an API, the decision depends on what repeating that request would do.

Consider a hypothetical dashboard with two buttons: refresh a public price list and send an invoice. A second refresh may be harmless. A second invoice may reach a customer twice. A connection optimization should preserve that distinction.

What the zero refers to

In TLS 1.3, RFC 8446, early data travels in the client’s first flight using a pre-shared key. For web connection resumption, that key comes from an earlier connection. The handshake still happens; application data simply starts earlier.

Zero round-trip time does not mean zero network latency, instant server work, or a faster database. Nor does enabling TLS 1.3 automatically mean every connection uses early data. Both ends need the appropriate support and negotiation.

The specification also distinguishes confidentiality from replay protection. Encrypting a request does not establish that a server has never seen it before. Early data lacks the forward secrecy provided by a fresh Diffie–Hellman exchange, and TLS supplies no inherent guarantee against replay across connections.

Choose endpoints by their effects

The HTTP early-data standard, RFC 8470, makes the resource’s behavior central to the decision. A safe HTTP method is useful evidence, but some endpoints produce side effects even when called with GET.

For the hypothetical dashboard, review the handler rather than its route name. Does fetching the invoice screen merely read an existing document, or also create a new delivery job? Does opening an export page retrieve a file, or queue expensive work? These are different operations even if both URLs look like reads.

An endpoint review should therefore describe the consequence of duplication in plain language. “Returns the current public catalog” is a stronger basis for a decision than “uses GET.” “Creates a delivery record” calls for a different policy.

How 425 Too Early fits

MDN describes 425 Too Early as a server refusing to risk processing a potentially replayed request. It is a signal about processing conditions, rather than proof that the request’s credentials or content are invalid.

RFC 8470 requires an early-data retry following that response to avoid early data. The client can try again after the handshake. This gives a sensitive operation a normal path forward without accepting its early execution.

A reverse proxy adds another boundary. It uses Early-Data: 1 when forwarding a request before its client handshake completes. The origin needs that context: completing the proxy-to-origin handshake does not undo exposure on the earlier hop. Where a marked request cannot be processed safely, the standard requires rejection with 425.

A CDN’s setting has its own limits

Cloudflare’s documentation, updated October 16, 2026, illustrates why deployment details matter. It supports 0-RTT for GET, HEAD and OPTIONS, but not POST, and adds the early-data header for the origin.

Cloudflare also says the resumed connection runs between the client and Cloudflare, without extending to the origin server. Its setting is off by default. These are Cloudflare’s documented product behaviors, not universal properties of every TLS implementation.

For a team operating behind a CDN, check the actual edge configuration alongside the application. A dashboard toggle alone cannot describe what each origin route does.

Keep retry protection at the application layer

Webtamine’s guide to idempotency keys explains a separate question: how an API recognizes a repeated business operation. That remains useful when a client retries after a timeout, regardless of whether 0-RTT is enabled.

For the invoice example, write down which component owns the delivery decision, how a repeated attempt is recognized, and what response the caller receives. An idempotency key requires a real server-side contract; adding a header does not itself create one.

Before enabling early data, review endpoint side effects, the CDN’s signaling, and client handling of 425 together. A practical starting point is a narrowly defined set of read-only resources. Leave consequential actions on the ordinary handshake path until their replay behavior is understood.

Common questions

Is TLS 1.3 0-RTT encrypted?

Yes. Early data is encrypted, but its security properties differ from data sent after the handshake. Encryption alone does not prevent cross-connection replay.

Does every GET request qualify for early data?

No. A GET handler that triggers a consequential action still needs scrutiny. Its HTTP method does not prove that repeating the action is acceptable.

Does 425 Too Early mean an API is unavailable?

Not necessarily. The server may be declining early processing while allowing a subsequent request after the handshake.

Documentation checked October 22, 2026: TLS 1.3 (RFC 8446, August 2018); HTTP early data (RFC 8470, September 2018); MDN’s 425 reference; Cloudflare’s October 16, 2026 documentation.