A third-party tide API will POST storm alerts to a URL the municipal harbor owns. Which Azure Functions trigger best implements that webhook?
Select an answer to reveal the explanation.
Short Explanation
When a partner says “we’ll POST to your URL,” that’s a webhook—and in Functions-land that’s an HTTP trigger. Skip the polling timer; let the tide API knock on the door.
Full Explanation
When a third-party tide API will POST storm alerts to a URL the municipal harbor owns, the integration is a webhook. An HTTP-triggered Azure Function that accepts the vendor’s POST at a controlled route implements that contract directly: the partner calls your endpoint, and the function processes the alert body. Authorization level, route template, and optional auth keys are related configuration on the same HTTP trigger model.
A timer that polls the vendor’s status page every minute inverts push into pull, adds latency, and is not a webhook. A Blob Storage trigger on a container the vendor cannot write to never receives the partner’s POST and therefore cannot start from the tide alert. A Cosmos DB trigger on a database the harbor has not shared with the vendor likewise has no event source from the third party’s HTTP call.
Exam caveat: HTTP triggers alone do not prove the caller is the tide vendor—pair the webhook with authentication (function key, Easy Auth, or signed requests) appropriate to municipal security policy; anonymous POST endpoints are a common exam and production pitfall. Operational check: publish the function URL to a test harness that POSTs a sample storm payload, verify a 2xx and expected processing side effects, and confirm unauthorized calls are rejected when auth is enabled.