Integration failures

Each outbound integration channel fails in its own characteristic way — this is the one place that gathers what each failure actually means and where to look.

What it is

• Webhooks — a delivery that doesn’t get a successful response is retried automatically every 10 minutes, up to six attempts in total, then given up on. A retry can arrive after your endpoint already processed the original delivery, so your own handling needs to treat repeated event ids idempotently.
• SFTP — once a server’s host-key fingerprint is pinned on first successful connection, any future connection presenting a different key is refused outright until a human re-confirms it — this is a fail-closed design, not a bug, since it’s exactly the same signal a genuine compromise would produce.
• EDI — a nightly run that errors writes its own run record marked as an error rather than failing silently; the run history shows exactly which day failed and why.
• The REST API — a client that exceeds its rate limit gets a mapped response naming the limit and when it resets, rather than a generic failure.

How to do it

1. For a repeatedly failing webhook, use Send test event under API & webhooks to isolate whether your endpoint is reachable and returning a success status at all, independent of production traffic.
2. For an SFTP fingerprint mismatch, verify the new host key with your own IT team out of band before re-pinning — never re-pin purely because the old one stopped matching.
3. For an EDI run error, open the run in your EDI history and re-run it for that date range once the underlying cause (typically a connectivity or credential issue at your SFTP destination) is fixed.
4. For a rate-limited API client, read the response’s limit and reset time and back off accordingly — retrying immediately just consumes more of the same budget.

How it integrates

None of these failure modes touch your underlying evidence or case data — a failed webhook delivery, a blocked SFTP connection, or a rate-limited API call all fail closed, never partially, and never as a silent data loss. Every delivery, connection test and pull is logged to its own activity feed (SFTP) or run history (EDI), so a failure investigation always has its own trail independent of asking anyone what happened.

Common problems

• A webhook worked for months and then stopped. Check whether your endpoint’s certificate expired, or your firewall rules changed — deliveries originate from europe-west2 and need to reach your endpoint over the public internet without being blocked.
• SFTP fails at the handshake with a fingerprint mismatch after your provider did routine maintenance. That can be a legitimate re-key on their side — confirm the new fingerprint with them directly before re-pinning, rather than assuming compromise or assuming it’s safe.
• My integration exceeded its rate limit during a legitimate bulk operation. Space out requests rather than retrying in a tight loop — the response tells you exactly when the limit resets.