TLDR#
Vulcan Forge allows for end-to-end automations with external systems at both stages of processing an SVM transaction: before and after submitting the transaction to the blockchain.Transaction Processing Stages and Webhooks#
Vulcan Forge supports the setup of 3 types of webhooks.1. Missing Signature Webhooks#
Webhooks executed for all blockchain accounts for which signatures cannot be collected at the time an SVM transaction is prepared.These webhooks can be used for automating the offline signing flow. Receiving systems can automate the follow-on completion of the transaction processing flow by calling the Sign Transaction endpoint once all conditions have been met that allow the receiver to either:generate signature(s) on its side and submit it to Vulcan Forge to attach to the transaction OR
let the system generate the signatures if the accounts (for which the signatures are missing) are setup as a managed account in Vulcan Forge, and the caller has access to them.
2. Pre Transaction Submit Webhooks#
Webhooks executed for all blockchain accounts that signed an SVM transaction. The execution of these webhooks occurs after the transaction is simulated and before it is submitted to the SVM network.This is the only type of webhooks which can stop the processing flow. See the webhook configuration section for more details. Thus they can be used as a mechanism to enforce policies validations.3. Post Transaction Submit Webhooks#
Webhooks executed for all blockchain accounts involved an SVM transaction. The execution of these webhooks occurs after the transaction is submitted to the blockchain.Webhooks processing flow#
This diagram illustrates at which point each set of webhooks will be executed at:Webhook Configuration#
The schema for a webhook configuration can be found here.External Validations#
Vulcan Forge clients can choose to use the preTransactionSubmitWebhooks not just as a notification mechanism but also as a way to implement custom validations/policies. If these validations / policies do not complete successfully, if the Pre Transaction Submit webhook is setup with doNotSubmitTransactionOnFailure=true, this results in the whole transaction being rejected. This applies if at least 1 such webhook fails.Authentication#
The webhook endpoints have to be configured with one (and only one) of the following authentication mechanisms:1.
API Key Authentication
See the apiKeyAuthConfig field in the webhook config schema for more details.
2.
OAuth2 Authentication
See the oauth2AuthConfig field in the webhook config schema for more details.
The following OAuth2 authentication flows are supported:
The system executes the webhooks applicable for each stage in parallel. It records the start time of the execution call and the end time for it (if the the webhook endpoint returns within the max allowed timeout).Webhook timeouts#
The system implements a default timeout (reflected in the default value for the timeout field in the webhook config schema). This means that once the timeout is reached, the system gives up on waiting for a response from the webhook. If the webhook responds within the allowed timeout, its HTTP Response Code is also logged.The execution time for the webhook is especially important for the Pre Transaction Submit webhooks, for these reasons:their execution sits inside the HTTP request processing pipeline: the longer these webhooks take, the longer the wait to get a response, for the Vulcan Forge client that submitted the request to the endpoint that creates the SVM transaction.
For transactions submitted with a messageLifetimeStrategy=RECENT_BLOCKHASH the system has a very short amount of time between when the blockhash is timestamped in the transaction at the Prepare stage and the moment the transaction is submitted/lands to the network for processing.
if the webhook is setup with doNotSubmitTransactionOnFailure=true, if the webhook does not return within the allowed timeout, the system considers this scenario as a failure.
As such, it is important for these webhooks to be fast and reliable.It is important to note also that if the system detects that some of the configs across the entire set of webhooks that has to be executed share the same endpointUrl, the system will only execute these webhooks once, per each distinct endpointUrl.If the logic for implementing external validation policies is more involved, a performance optimization can be considered where the logic is split over up to 3 different webhooks (the max allowed # of webhook configs allowed per account & type of webhook). These webhooks are then executed in parallel and if either of them fails, the transaction will be rejected.Favor API Key Authentication#
Webhooks setup OAuth2 for authentication have a handicap in terms of total execution time: instead of the needing to execute just 1 HTTP request to the webhook endpoint, the system needs to execute an additional HTTP request (before the webhook endpointUrl is hit) in order to fetch a bearer token from the OAuth2 provider.As such, especially for Pre Transaction Submit webhooks, it is recommended to use API Key authentication.The system stores in its offchain database, these authentication credentials in encrypted format. And at the time an endpoint does its processing, the credentials are read and decrypted on the fly before webhook executions.Webhook payloads#
The payload provided to the webhooks provides all the transaction information available at the time the webhook is called.As such, the payloads are different depending on the execution stage:Missing Signature Webhooks
Pre Transaction Submit Webhooks
Post Transaction Submit Webhooks
Modified at 2026-04-05 17:58:50