---
title: "Webhook Event Registry"
slug: webhook-event-registry
section: Integrations
status: stable
description: "The code-verified, canonical list of every Globus-emitted webhook event, its current handling status in the n8n Dispatcher, and the events that are emitted but have no handler and are not registered as intentional noOps."
last-updated: 2026-06-19
---

# Webhook Event Registry

# Canonical Webhook Event Registry

The code-verified, canonical list of every Globus-emitted webhook event, its current handling status in the n8n Dispatcher, and the events that are emitted but have no handler and are not registered as intentional noOps. This page is the ecosystem source of truth for event coverage; the live routing table lives on the Automation page .

## Purpose

This registry reconciles three sources: the BackOffice / Globus codebase (the source of every emitted event type), the n8n Dispatcher Event Router (the routing table that decides handler vs noOp), and the per-domain n8n Domain Handler workflows (the exact actions). It also records the Applicant Portal direct webhook handlers. Every event is classified as implemented, an intentional noOp, or Needs Action.

> **Grounding & ownership boundary**
>
> The classifications below reflect the audit against BackOffice (development branch), the n8n Dispatcher Event Router, the n8n Domain Handlers, and the Applicant Portal (decouplewebhooks branch) as of 2026-06-26. This docs page and its MCP sync are how the ecosystem registry is updated. The actual handler builds, noOp registrations, and the netsuite.* re-enable are changes to the n8n Dispatcher / Domain Handler workflows — they are owning-repo follow-up work, not changes in this docs-site repo. Handler IDs are the n8n workflow IDs.

## Implemented — n8n Handlers Active

Each domain routes to one n8n Domain Handler (workflow ID shown). The action column records the systems called, fields written, and emails sent per event.

## Applicant Portal — Direct Handlers

A subset of events is consumed directly by the Applicant Portal (decouplewebhooks branch), outside the n8n Dispatcher. Most are read-through syncs or log-only.

| Event(s) | Portal action |
| --- | --- |
| event | action |

_(row above is a template, repeated for each data row)_

## Intentional noOps

These domains are acknowledged in the dispatcher as deliberately unhandled. They are safe to ignore and require no action.

| Domain | Registered | Reason |
| --- | --- | --- |
| domain | registered | reason |

_(row above is a template, repeated for each data row)_

## Needs Action — Defined, Not noOp

These events are emitted by the BackOffice but have no handler registered in the n8n dispatcher and are not registered as noOps. Today they are silently dropped or cause delivery failures. Each carries a recommended disposition.

> **Recommended dispositions — pending owner confirmation**
>
> The disposition column is a recommendation based on each event's apparent intent, not a final decision. Confirm with the domain owner, then implement in the n8n Dispatcher / Domain Handler workflows (owning repo). "Build handler" means register a route and handler; "Register noOp" means add an explicit noOp acknowledgement; "Verify" means confirm coverage or intended consumer first.

| Event(s) | Recommended disposition | Notes |
| --- | --- | --- |
| event | disposition | note |

_(row above is a template, repeated for each data row)_

## netsuite.* Handler Status

The netsuite.* domain handler (rvLCpGsMjgkxNFPE) is currently inactive and has no noOp registration — it is in neither the implemented set nor the acknowledged-noOp set, so netsuite.invoice.created / updated events fall through.

> **Recommendation: re-enable**
>
> The handler has a concrete, defined target — it prepares invoice data from NetSuite and PUTs to /api/applications/:id/finance-summary on the Globus Hub via NetSuite Invoice Delivery. Because the downstream is real, the recommended disposition is to re-enable the handler rather than noOp it. If finance-summary delivery is intentionally deferred, register netsuite.* as an explicit dated noOp instead so it stops falling through silently. Either change is n8n Dispatcher repo work.

## Dispositions & Follow-Up

Summary of the actions this registry surfaces. Documentation (this page + MCP sync) is owned here; every implementation step below is owned by the n8n Dispatcher / Domain Handler repo and should be filed there, not as a task on the docs-site repo.

- Build handlers for the Needs-Action events marked Build handler (applicant / application lifecycle milestones, host expiry & status events, document state extensions, compliance, sevis_readiness, checkin, partner, travel_request, finance_payment, staff.notification, step.lock_changed).

- Register explicit dated noOps for the internal-only signals (applicant.assignment.*, applicant.next_action.invoked, application.flow_available / flow_ineligible_observed).

- Verify the ambiguous domains (catalog.program_* wildcard coverage; business_bundle.* consumer) before choosing handler vs noOp.

- Re-enable the netsuite.* handler (rvLCpGsMjgkxNFPE) or register it as an explicit noOp.