A harbor ferry /delay webhook Function must return HTTP 202 to the caller and also enqueue a notification message for staff. How should the developer structure outputs on that single function?

Azure Functions support multiple output bindings on a single function. For the harbor ferry /delay webhook, keep the HTTP trigger’s response path so the caller receives HTTP 202, and add a second output binding—such as Queue Storage or Event Hubs—to enqueue the staff notification in the same invocation. That structure satisfies both synchronous acknowledgment and asynchronous fan-out without redesigning the trigger or introducing another host.

Removing the HTTP trigger and relying only on a queue trigger eliminates the ability to return HTTP status codes to the webhook caller, which breaks the ferry API contract. Returning HTTP 202 only while forcing staff to poll Blob Storage manually for delay notes drops the enqueue requirement and invents an unreliable human polling process. Hosting the webhook on Azure Kubernetes Service with a sidecar that duplicates every response is an unnecessary platform change; the Functions multi-output binding pattern already covers dual response-plus-message needs.

Exam caveat: HTTP output and additional output bindings must be declared correctly for the language model in use (for example return type versus out parameters), and a failure writing the queue message can still surface after you intended to return 202 depending on how errors are handled—design for poison messages and retries. Operational check: call /delay with a test payload, assert the client receives 202, then verify a corresponding message appears on the staff queue or Event Hub with the expected delay fields within seconds.