Webhooks

The Art of Delayed Webhooks: Teaching LeanIX Automations to Wait

Thomas Schreiner

Thomas Schreiner

— 2 min read
Share

"There was a version conflict. Someone else modified this Fact Sheet while you were editing." If your users see this message regularly, your automations might be too eager. Here's how we teach them some patience.

The Problem: Automations That Are Too Fast

LeanIX webhooks are beautifully responsive. Change something, get an event, run your automation. Milliseconds. Elegant.

Except when it's not.

We keep running into two scenarios where instant automation causes friction:

Scenario 1: The Version Conflict Popup

User saves a Fact Sheet. Your automation immediately updates a field. User makes another change and hits save. Boom – version conflict. The Fact Sheet was modified between their two saves, and now they're staring at a warning dialog they didn't ask for.

Scenario 2: The Subscription Shuffle

You have a rule: "Only one Application Owner allowed." User wants to transfer ownership from Alice to Bob. They add Bob first, planning to remove Alice right after. But your automation fires instantly: "Adding more than one Application Owners is not allowed – removing the newer one!" And they cannot delete the old owner first, because it's a mandatory subscription and the fact sheet has already been approved.

Not ideal.

The Solution: Strategic Procrastination

What if your automation just... waited a bit? Gave users a grace period to finish what they're doing?

Here's the trick: HTTP 503 to the rescue.

When our webhook receives an event, we check the event's creation timestamp. If it's less than 10 minutes old, we respond with:

HTTP/1.1 503 Service Unavailable
Retry-After: 427

That Retry-After value is calculated: event creation time + 10 minutes – now. LeanIX sees the 503 and knows to retry later.

Even if LeanIX doesn't strictly honor the header (it retries roughly once per minute anyway), the math works out. After 10 minutes, the event finally gets processed – along with any subsequent events that queued up.

The Setup: Two Webhooks, Two Personalities

We don't want all automations to be lazy. Some things should happen immediately – data enrichment, external system syncs, notifications.

So we run two separate webhooks:

  • Live Webhook – Processes events instantly. For automations where speed matters.
  • Delayed Webhook – Implements the 503 trick. For automations where grace periods matter.

Same events, different timing, zero code duplication in LeanIX. You just subscribe both webhooks to the same event types and let the endpoint logic decide.

The Code (Simplified)

def handle_webhook(event):
    event_age = now() - event.createdAt
    delay_minutes = 10
    
    if event_age < timedelta(minutes=delay_minutes):
        retry_after = (delay_minutes * 60) - event_age.seconds
        return Response(
            status=503,
            headers={"Retry-After": str(retry_after)}
        )
    
    # Event is old enough – process it
    process_event(event)

Why This Works

  • No version conflicts – Users finish their edits before automation kicks in
  • Grace periods – Subscription shuffles complete before rules are enforced
  • No lost events – LeanIX's retry mechanism guarantees delivery
  • Flexible – Choose which automations need patience and which don't

Conclusion

Sometimes the best automation is the one that knows when to wait. A 10-minute delay might feel like an eternity in software terms, but for users making thoughtful changes to their architecture data, it's exactly the breathing room they need.

Your automations don't have to be the fastest. They just have to be the smartest.

Want to implement delayed webhooks in your LeanIX setup? Let's talk – we've got the patterns ready.

Read more