Skip to main content
Use SDK logging and error surfaces while you build and debug an integration. Keep request and response logging out of production logs unless your app has an explicit redaction and retention policy.

SDK Surface

Use the network observer as a development diagnostic tool. It can expose request metadata, response metadata, and payloads depending on platform, so avoid storing raw logs that may contain user content or credentials.

Parameters

Network Activity

Observe network activity only while debugging an integration, then unsubscribe or dispose the observer when the debug session ends.

Error Handling

SDK operations throw or emit platform-native errors. Convert those errors to SDK error enums before deciding whether to retry, show a user message, or end the session.

Common SDK Error Constants

A global mute (400313) is not a global ban (400312). The user stays signed in and the session continues; only the blocked action fails. Unsafe content (400314) means the request was rejected by content moderation, so sending the same content again fails the same way. Neither code ends the session, so handle both as a per-action error: tell the user why the action failed instead of signing them out.

Production Checklist

  • Disable broad network payload logging outside development builds.
  • Redact tokens, authorization headers, user identifiers, and message or post bodies before writing logs.
  • Keep retry logic bounded and avoid retrying authorization, global-ban, global-mute, or unsafe-content errors.
  • Show user-friendly messages in the app UI; keep SDK codes in developer logs and support diagnostics.
  • Unsubscribe or dispose observers when the screen, debug session, or application lifecycle no longer needs them.