Deploy a focused handler
Give a small HTTP task its own source and configuration. Keep integration logic separate when it has a different purpose or change cycle from the rest of the application.
Runtime / Functions
Give one HTTP task its own deployment.
Deploy focused application logic behind an HTTP endpoint. Keep webhooks, validation and integrations separate from your main application.
- Input
- HTTP request from your integration
- Validate
- Authentication + payload schema
- Process
- Handler logic + dependency calls
- Output
- HTTP status + response body
- Retries
- Handle repeated requests in your code
Execution limits, resources and billing depend on the selected offer.
- Deployment input
- Function source and configuration
- Execution model
- HTTP invocation
- Best fit
- Webhooks, validation and integrations
Application architecture / Functions
Turn an incoming request into a useful result.
Validate the incoming request, run the handler and return a response. Handle caller retries in your code and keep durable state in an appropriate external service.
What this gives you
A focused endpoint with an explicit input, response and failure path.
Where it fits
What you can do with functions.
For webhooks and small HTTP tasks that fit the execution model of a published function offer.
Expose an invocation endpoint
Use the configured endpoint to call the handler from your application or an external system. Your handler owns input validation, request authentication and the response it returns.
Investigate execution behavior
Inspect function state and available logs to understand successful and failed calls. Exercise malformed input and unavailable dependencies as well as the expected request.
Choose around execution limits
Review the selected configuration for resources, timeout behavior and billing units. Keep durable data in an appropriate external service and design effects to handle caller retries.
In practice
Small tasks with a clear input and result.
Choose a function for a focused HTTP task that fits the selected execution limits and can be tested independently of the rest of your application.
A webhook handler
Receive an application event, validate the request and return a deliberate response to the sender.
Plan for
Request authentication, duplicate delivery and error responses.
A lightweight HTTP endpoint
Expose a small transformation or validation step as a separate request-driven workload.
Plan for
Input size, execution timeout and access to dependencies.
An integration step
Connect two application services with focused logic and explicit failure handling.
Plan for
Upstream timeouts, credentials and safe retries.
The workflow
From configuration to a running workload.
- 01
Check the runtime
Review supported configuration and execution constraints in the selected offer.
- 02
Deploy the function
Provide the required function configuration through the Resource Composer.
- 03
Test the invocation
Call the configured endpoint and verify both successful and failed requests.
Configuration checks
Prepare the operating environment.
- Confirm the supported runtime, resource limits and execution timeout.
- Define how callers authenticate and what constitutes a valid request.
- Test success, invalid input, duplicate requests and unavailable dependencies.
Responsibilities
Know what you maintain.
Functions / Questions
A few details before you start.
Is a function suitable for a long-running worker?
Compare the workload with the execution model and timeout of the offer. A container or VM can be a better fit when a service needs to keep running between requests.
How should I handle webhook retries?
Design the handler to recognize duplicate events and avoid repeating side effects. The caller may retry when a response is delayed or a connection fails.
How are functions billed?
Review the actual billing unit and included quantities in the selected offer. Invocation-based pricing, scale-to-zero and automatic scaling should only be assumed when specified there.
Connected products