Skip to main content

Diagnose an External Integration Failure

Diagnose an External Integration Failure

Overview

This guide will help you identify whether an integration failed before submission, in transit, at the provider, or during local persistence.

The incident has a failure stage and a safe next action rather than an uncontrolled retry.

Who can do this

You need access to Relevant transaction/inquiry access and authorized diagnostic/log.

Before you start

Have timestamp, company, terminal, user, local document number, external ID, action, sanitized error, and connectivity status.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open the failed workflow, its inquiry/history, notifications, and authorized logs.

Diagnose an External Integration Failure

Step 1: Confirm the intended company, environment, and endpoint

Step 2: Check local validation and permission failures

Step 3: Check connection, DNS/TLS, authentication, and provider availability

Step 4: Determine whether a request was submitted and capture its external ID

Step 5: Check provider acceptance/status separately from transport success

Step 6: Verify whether Muhasib stored or posted the local result

Step 7: Classify the failure before any retry

Check your work

Evidence identifies one local record, zero or one provider request, its status, and any mismatch requiring checking.

Take a moment to check your work before closing the window. This small check can save time later.

If something goes wrong

  • Never paste secrets or full private payloads into tickets.
  • Treat timeouts as unknown outcomes until provider/local history is checked.

What to do next

Back to top