Event-based webhooks
Subscribe external endpoints to relevant file, service, form, signature and process events.
Capability
Automation and webhooks
Connect Cloud actions through APIs and signed webhooks with retries, history and statistics.
Overview
Connect Cloud actions through APIs and signed webhooks with retries, history and statistics.
Features
What Automation and webhooks can do
HMAC request signatures
Verify that webhook payloads were generated by Apification and were not modified in transit.
Delivery history
Inspect destination URL, attempt time, response status and body for every webhook delivery.
Automatic and manual retries
Repeat temporary failures with controlled retry rules or trigger a new attempt from the portal.
API-driven operations
Automate creation and management of supported accounts, Cloud resources and configuration.
Idempotent commands
Attach a stable key to write operations so network retries do not repeat the business action.
Asynchronous processing
Run imports, transformations and provider jobs in the background without blocking the original request.
Detailed failure states
Keep provider, validation and processing errors associated with the job that produced them.
Usage and delivery statistics
Measure executions, successful or failed deliveries, retries and consumption over time.
Event lifecycle
Design for verification, retries and recovery
A reliable automation treats delivery as a stateful process rather than a single HTTP call.
-
01 Choose the event
Subscribe only to lifecycle changes the receiving system can act on.
-
02 Verify the request
Validate the HMAC signature before reading or persisting the payload.
-
03 Process idempotently
Use stable event and command identifiers to prevent duplicate business actions.
-
04 Observe and recover
Inspect delivery history and retry temporary failures without losing context.
Operational detail
How Automation and webhooks works in practice
Automation combines authenticated commands with signed event delivery, background processing and operational evidence so external systems can react without turning retries into duplicate work.
Events need an explicit contract
The receiver should know the event type, resource identity, account context, occurrence time and payload version it supports before automating a business action.
Delivery has a lifecycle
Attempts, responses, timing and retry state remain attached to one delivery so temporary outages can be distinguished from permanent validation errors.
Commands and jobs require different handling
Synchronous API validation can acknowledge a command while imports and transformations continue as background jobs whose final state arrives later.
Monitoring is part of the workflow
Success rates, repeated failures, processing duration and consumption should be reviewed together to detect broken destinations or inefficient automation.
Frequently asked questions
Questions about Automation and webhooks
The supported event catalogue covers relevant Cloud, processing, delivery, and service lifecycle changes.
Webhook requests include a signature generated with the configured secret, allowing the receiver to verify their authenticity.
The delivery log stores attempts, status, response, and timing information for diagnosis and controlled retries.
Receivers should not depend solely on arrival order. Use event timestamps, resource state and stable identifiers when ordering affects the resulting action.
Acknowledge only after the payload has been verified and accepted durably. Lengthy business processing should continue asynchronously.
Store the stable delivery or event identifier and make the resulting business operation idempotent before returning success.