Need to get exact reason for failure while submitting connection creation on CH using AI

Based on engineering assessment, the requested capability already exists and the reported behavior was identified as a regression/gap in the current implementation rather than a missing product feature.

Fixes for AS2 JSON upload scenarios have already been delivered, and additional improvements for remaining SFTP JSON upload error handling scenarios are in progress.

Closing this RFE as the request is being addressed through ongoing product fixes and enhancements.

Dear Vikram,

Thank you for submitting this RFE and clearly describing the issue you encountered while creating an AS2 relationship via JSON on CH using API. We appreciate you highlighting this from a real implementation perspective.

This request calls out a critical usability and diagnostics gap in the current connection‑creation API flow. When AS2 relationship creation fails, the API returns a generic error message (“An exception was thrown… Retry after sometime”), which does not provide actionable feedback. As a result, users are unable to determine whether the failure is due to invalid JSON structure, missing or incorrect fields, unsupported configurations, or backend validation errors—forcing repeated retries or support engagement.

Providing specific, descriptive error responses (for example, field‑level validation or configuration errors) would enable users to self‑correct issues in their JSON payloads, significantly reducing trial‑and‑error, support cases, and time to successful onboarding.

Questions

To scope this enhancement correctly and assess impact, the PM should clarify:

1. Error context

   • Does the failure occur consistently for the same JSON payload, or intermittently?

   • Are there specific fields or sections of the JSON that seem correlated with the failure?

2. Expected behavior

   • Would you expect validation errors returned synchronously (e.g., HTTP 4xx with details), or a structured error response indicating backend processing failures?

3. Level of detail

   • What level of error detail would be most useful?

     • Field‑level validation messages?

     • Error codes with documentation references?

     • Exact backend exception reason (abstracted)?

4. Security and exposure

   • Are there any concerns with exposing detailed error messages in API responses, or would sanitized, user‑friendly messages be sufficient?

5. Scope

   • Should this improved error handling apply only to AS2 connection creation, or more broadly to other connection and configuration APIs on CH?

Clarifying these points will help ensure the solution strikes the right balance between usability, security, and consistency across APIs.

Thanks again for raising this thoughtful enhancement request. Improving transparency and debuggability in APIs is critical for customer self‑service and faster onboarding, and your input helps drive meaningful improvements.

—
Manoj Panda
Senior Product Manager
IBM Sterling