Build serverless APIs with Azure Functions triggers and bindings

Bundled into the existing Developing AI Cloud Solutions on Azure premium course — no separate purchase.

14-day money-back guarantee — no questions asked.

Included in this chapter:

Trigger	What starts one invocation	Who retries a failure	The published failure path
HTTP	One HTTP request matching the route and method	Not the runtime; the trigger is absent from Microsoft's retry table	The status code your code returns to the caller
Timer	One NCRONTAB (or TimeSpan) schedule occurrence	A function-level retry policy, if you add one	The next scheduled occurrence
Queue Storage	One Storage queue message	The binding extension, `maxDequeueCount` times (default 5)	The `<queue-name>-poison` queue
Blob Storage	One new or updated blob in the watched container	The binding extension, five tries by default	The `webjobs-blobtrigger-poison` queue
Service Bus	One message from a queue or a subscription	The binding extension; Service Bus redelivers on abandon	The entity's dead-letter queue
Event Grid	One delivered event (one invocation per array element)	The binding extension, configured on the event subscription	The event subscription's dead-letter destination
Cosmos DB	A batch of change-feed items from the monitored container	A function-level retry policy that the runtime enforces	The retry policy's `max_retry_count`, then the exception

Cheat sheet

The HTTP trigger's authLevel (anonymous, function, admin) controls key requirements for a serverless API
HTTP triggers define a route template and allowed HTTP methods for the request
A function has exactly one trigger but may declare many input and output bindings
The Timer trigger runs on a fixed NCRONTAB schedule
Blob triggers can poll or use an Event Grid source; the Event Grid source is the low-latency option
The Service Bus and Event Grid triggers bind a function directly to a queue/subscription or event stream
The Cosmos DB trigger consumes the change feed and requires a lease container
Storage Queue trigger poison-message handling
Input bindings read data into the function; output bindings write data out — declaratively, no client SDK code
Bindings are declared with decorators (Python v2 model) or function.json, referencing a connection app setting
An output binding can be fed by the function's return value
Binding expressions inject trigger metadata ({queueTrigger}, {name}) and app settings (%setting%)
A Cosmos DB input binding fetches items by id/partition key or a SQL query
A blob binding path uses a container/{name} pattern to bind the specific blob

Unlock with Premium — includes all practice exams and the complete study guide.

Cheat sheet