diff --git a/develop-docs/sdk/expected-features/index.mdx b/develop-docs/sdk/expected-features/index.mdx
index 1df0b5c7db6e4..39b206fcdb9d5 100644
--- a/develop-docs/sdk/expected-features/index.mdx
+++ b/develop-docs/sdk/expected-features/index.mdx
@@ -251,7 +251,20 @@ Write events to disk before attempting to send, so that they can be retried in t
 
 ### Dealing With Network Failures
 
-When SDKs receive an `HTTP 2xx` status code response from Sentry, they **MUST** consider it as a successful send. If Sentry returns an `HTTP 4xx` (excluding `HTTP 429`) or `HTTP 5xx` status code, SDKs **MUST** discard the envelope and record a [client report](/sdk/telemetry/client-reports) with the discard reason `send_error`. For an `HTTP 429` response, SDKs **MUST NOT** record a client report to comply with the [rate limiting](/sdk/expected-features/rate-limiting/) rules, because the backend already records a client report for the rate limit. SDKs **MAY** retry sending the envelope when a network error occurs, such as:
+When SDKs receive an `HTTP 2xx` status code response from Sentry, they **MUST** consider it as a successful send.
+
+If Sentry returns an `HTTP 4xx` or `HTTP 5xx` status code, SDKs:
+
+- **MUST** discard the envelope
+- **MUST** record a [client report](/sdk/telemetry/client-reports) with the discard reason `send_error`, except for `HTTP 429` responses, see below.
+
+For an `HTTP 429` response, SDKs:
+
+- **MUST** respect the [rate limiting rules](/sdk/expected-features/rate-limiting/), such as correctly parsing the retry-header.
+- **MUST** drop the envelope, but **MUST NOT** record a [client report](/sdk/telemetry/client-reports), because the backend already does this. Doing this would double-count dropped envelopes.
+- **MUST NOT** retry sending the envelope.
+
+SDKs **MAY** retry sending the envelope when a network error occurs, such as:
 
 * Connection timeout
 * DSN resolution failure