BongaTech Bulk SMS

Error Classification & Response Mapping

This chapter details how the SMS integration processes downstream server response anomalies, structural input layout mismatches, and nested form schema validation issues. It outlines the formatting of nested validation arrays into a clean error tracking summary.

Robust production systems do not simply assume a network call fails uniformly. They intercept and inspect backend exceptions, distinguishing between standard server execution errors and detailed constraint validation failures.

The integration module contains a dedicated error classification block designed to parse downstream validation dictionaries into human-readable strings.

Classifying Gateway Responses

The wrapper processes three main types of response exceptions:

1. Successful Outbound Routing (response.ok)

When the HTTP status falls within the 200-299 range, the module extracts the primary confirmation tracking token (messageId, id, or standard message) and marks the operation as true.

2. Standard Gateway Failures

If the request is rejected structurally but without deep schema error keys, the interface checks for a top-level description field (data.message or data.error) and passes it backward to the caller.

3. Nested Validation Errors (data.errors)

When the BongaTech validation handler rejects payload parameters (e.g., an unapproved sender ID string or an unsupported country code block), it returns a structured key-value validation object.

Dynamic Key-Value Flattening Architecture

To prevent structural nested arrays from bloating application logging views, the engine iterates over the runtime error dictionary dynamically. It matches each validation key against its array of violation notes, normalizes string arrays, and formats them into a single delimited summary block:

typescript
let errorMsg = data.message || data.error || '';
if (data.errors && typeof data.errors === 'object') {
  const detailedErrors = Object.entries(data.errors)
    .map(([field, msgs]) => `${field}: ${Array.isArray(msgs) ? msgs.join(', ') : String(msgs)}`)
    .join('; ');
  errorMsg = errorMsg ? `${errorMsg} (${detailedErrors})` : detailedErrors;
}

Response Processing Map

The following table outlines how upstream responses map to internal output values:

HTTP Status CodeUpstream Response ExampleResolved SmsResult Return
200 OK{"success": true, "messageId": "98412"}{"success": true, "messageId": "98412"}
400 Bad Request{"message": "Invalid Parameter", "errors": {"sender": ["The selected sender is invalid."]}}{"success": false, "error": "Invalid Parameter (sender: The selected sender is invalid.)"}
401 Unauthorized{"error": "Unauthorized Token Access"}{"success": false, "error": "Unauthorized Token Access"}
500 Internal ErrorRaw HTML text dump from proxy server{"success": false, "error": "API returned non-JSON response: \"...\" (Status: 500)"}

Logging & System Diagnostics

Every time a network response falls outside the successful response.ok range, the integration logs a deep diagnostic payload to standard error stream paths (console.error). This log includes the HTTP status, compiled error messages, parsed response records, target phone digits, and the sender profile metadata:

typescript
console.error('[BongaTech SMS Error] Failed API response:', {
  status: response.status,
  error: errorMsg,
  data,
  phone: formattedPhone,
  sender: senderId
});
Last updated: 7/16/2026
Error Classification & Response Mapping | BongaTech Bulk SMS Docs