Alright, I’ll bite. We’re trying to integrate Relevance AI into an internal tool for automating marketing campaign triggers. The premise is simple: our app sends a payload, Relevance AI processes it, and fires a webhook to our orchestration layer. Except it doesn’t. At least, not reliably.
I’ve seen the vendor docs and the usual "99.9% uptime" claims, but our logs show about a 70-75% success rate on webhook triggers over the last two weeks. The failures aren’t consistent—sometimes it’s a timeout, sometimes the payload seems to vanish into the ether, no retry, no error in their UI. We’re using their standard "Workflow" setup with a webhook node. Authentication is via secret key in the header, which is correct because the 75% that work prove the config isn’t completely broken.
Has anyone else run into this kind of flakiness? Specifically:
- Webhooks firing but your endpoint never receives the request (no server logs).
- Inconsistent delays—some fire in 2 seconds, others take 90+ seconds or not at all.
- Any pattern related to payload size or complexity? Ours are JSON, under 5KB.
We’re stuck between blaming our infrastructure (which handles other webhooks fine) and their service. Their support’s default answer is "check your endpoint," which is classic. Before I go down the rabbit hole of building a proxy just to log their outbound attempts, I’m curious if this is a known quirk or if we’ve just hit a bad node.
Data skeptic, not a data cynic.
I've encountered similar patterns with third-party webhook services. That 70-75% success rate is a classic symptom of insufficient retry logic and possibly a non-durable queue on their end. The fact that successful calls prove your auth is correct is a key diagnostic.
You should instrument your endpoint to log the exact request headers and timing. Often, the issue isn't a complete failure to send, but a network timeout or a 5xx response from your side that their system doesn't handle gracefully. Their 90+ second delays point to either queue saturation or a blocking operation in their workflow engine.
For payloads under 5KB, size is unlikely the culprit, but check for unexpected characters or nested structures that might cause serialization delays. I'd recommend implementing a dead-letter queue or a side-channel (like a simple polling fallback) for critical triggers until you get clarity from their support. Have you been able to correlate failures with your own infrastructure's load metrics?
Oh, the classic "blame your own infrastructure" phase. I love it. That 99.9% uptime claim is almost always about their API *accepting* your request, not about their system reliably *delivering* the webhook afterward. The queue is probably an afterthought.
Your 70-75% success rate is the tell. If your endpoint works fine for other services, the vanishing payloads point squarely to their side dropping messages or having a flaky outbound connection pool. The inconsistent delays scream "best-effort delivery" on their backend.
Before you spend weeks instrumenting your own endpoint, check if they have a webhook delivery log buried in their UI, or if you can enable some kind of event tracing. Most of these platforms have it but don't advertise it because, you know, it would show the failures. If they don't, that's your answer right there - they're not eating their own dog food.
FOSS advocate