Skip to main content

Transaction Errors

Every diagnosed webhook failure is tagged with a stable code. Codes never change once issued - only new ones are added. Codes appear in two places at runtime:

  • On the Transaction.Message column for failed rows, prefixed in square brackets (for example [DSWBHK020] Status code: 502.). See the Errors page.
  • In NLog / Application Insights logs as errorCode={ErrorCode} on the structured log line.

Retried codes are picked up automatically by the retry job (3 attempts, exponential backoff with jitter, then the row stays Failed for the next pass). Fix configuration codes need a connector or partner setup change first - the in-pipeline policy does not retry them, but the DB-retry job picks Failed rows up on the next pass. Undiagnosed failure shapes should be sent to support so a rule can be added.

Each section pairs 💡 (what it means) with 🛠️ (what to do).

Quick lookup

CodeGoes toStatusRetry
DSWBHK001Webhook not allowedBackOfficeNotAllowedfix config
DSWBHK002Empty or malformed URLWrongUrlfix config
DSWBHK003Wrong connector typeInvalidBackOfficeTypefix config
DSWBHK010Partner endpoint timeoutFailedretried
DSWBHK020Partner HTTP failureFailedretried
DSWBHK030Circuit breaker openFailedretried
DSUNK001UndiagnosedFailedundiagnosed

Webhook not allowed

⚙️DSWBHK001fix configuration
💡
The connector is flagged as not allowed to send appointments to a back-office.
🛠️
In the connector settings, enable Send appointment to web service.

Empty or malformed URL

⚙️DSWBHK002fix configuration
💡
The connector's web-service address is empty or malformed.
🛠️
Set a valid https://... URL for the webhook endpoint in the connector settings.

Wrong connector type

⚙️DSWBHK003fix configuration
💡
The connector type cannot be cast to Webhook - typically a stale row from an older connector definition.
🛠️
Recreate the connector with type Webhook. The status column is the signal; raw text is suppressed in the transaction message.

Partner endpoint timeout

🔁DSWBHK010retried automatically
💡
The partner endpoint did not respond within the request timeout (TimeoutException).
🛠️
Check partner endpoint availability and response time. The retry job will pick up Failed rows after the configured TTL.

Partner HTTP failure

🔁DSWBHK020retried automatically
💡
A non-transient HTTP failure (typically a permanent 4xx other than 401/403/429), or a transient 429/5xx after retries were exhausted. The raw status code and message are included in the transaction row.
🛠️
If the status is 4xx, fix the request shape (e.g. payload schema, content-type, authentication scope) - these don't self-heal. If 5xx, check the partner endpoint.

Circuit breaker open

🔁DSWBHK030retried automatically
💡
The per-(tenant, connector) circuit breaker is open - prior failures already exhausted the in-pipeline retries, and this call was short-circuited before reaching the partner.
🛠️
Self-healing - the breaker half-opens after its break duration, and the DB-retry job re-picks Failed rows. No action needed unless the underlying partner endpoint is still unavailable.

Undiagnosed

🚨DSUNK001undiagnosed
💡
No diagnostic rule matched the exception. The exception is recorded verbatim on the transaction row and logged as errorCode=DSUNK001 so it can be triaged into a new rule.
🛠️
If this fires repeatedly, send the transaction ID and error message to Dime.Scheduler support so a typed rule can be added.

Cross-cutting codes

These are emitted by the shared connector layer and may also surface on webhook transactions when the failure happens before the delivery code runs. Their definitions live with the Business Central transaction errors:

  • DSCFG001 - BackOfficeNotAllowed (shared, mirrors DSWBHK001 semantics).
  • DSCFG002-DSCFG008 - connector-configuration validation failures (argument, null reference, invalid system cast, malformed URL, rejected credentials).
  • DSHTTP001 - generic HTTP transient (the shared transient rule before it's specialised into DSWBHK020).
  • DSDB001-DSDB004 - database / persistence transients during transaction-row writes.