docs(sdk): Clarify HTTP response codes considered successful (#13256)

* chore(sdk): Clarify HTTP response codes considered successful

* Apply suggestions from code review

Co-authored-by: Alex Krawiec <[email protected]>

---------

Co-authored-by: Alex Krawiec <[email protected]>

Author: markushi

develop-docs/sdk/expected-features/index.mdx

@@ -232,16 +232,17 @@ This feature is also known as 'Offline Caching'.
 
 Write events to disk before attempting to send, so that they can be retried in the event of a temporary network failure. Needs to implement a cap on the number of stored events. This is mostly useful on mobile and desktop(e.g: laptop) apps, where stable connectivity is often not available.
 
-#### Dealing with failures
+### Dealing With Network Failures
 
-It's important to note that retry is only considered in the event of a network failure. For example:
+An `HTTP 2xx` status code response from Sentry is considered a successful send. It's important to note that retry is only considered in the event of a network failure. For example:
 
 * Connection timeout
 * DSN resolution failure
 * Connection reset by peer
 
 Other failures, like those caused by processing the file in the SDK itself, the payload should be discarded since those are likely to end up on an endless retry.
-If the event reached Sentry and a HTTP response status code was received, even in the event of a `500` response, the event should be discarded.
+If the event reached Sentry and an HTTP response status code was received, even in the event of an `HTTP 500` status code, the event should be discarded.
+
 
 #### Additional capabilities