Webhook Node

Legacy

This is part of the legacy Platform documentation.

In Seen's legacy Journey builder, the Webhook Node allows you to make requests with your data from Seen Platform to your systems after the video has been rendered.

To create a Webhook, drag and drop the Webhook Node to the Canvas, connect it to the previous node, configure your webhook, and click Save.

Remember to add the Webhook Node after the Player node.

The configuration menu consists of the following details:

General

URL

With the URL field, you will be able to define the endpoint of the request.

You can use any properties in your Workspace to personalise the endpoint URL. This can be useful in cases where you are required to use (e.g.) an ID as a part of the endpoint.

Method

With the Method dropdown, you will be able to define the request method.

Currently we support the following methods: POST, GET, PUT, DELETE, PATCH

Headers

With the Headers field(s) you will be able to add headers for your request as key-value pairs. You can add multiple Headers by clicking the Add a header button.

You can use any properties in your Workspace as the key or the value of the Header.

Request content

You are able to create your request content as JSON.

You can use any properties in your Workspace within the request content.

The dynamic content for the request is divided into two menus:

• Variables – You will find all your Workspace properties in this menu.
• Outputs – You will find the Journey specific outputs in this menu: Player link, Email thumbnail link.

Timeouts & Retries

Seen will wait up to 5 seconds for your endpoint to respond. If no response is received within this window, the request is considered failed.

If a request fails due to a timeout or a non-2xx response code, Seen will retry the same request up to 4 times. Every Journey Webhook Node uses this retry behaviour automatically, so there is nothing to configure.

Retry schedule

Retry	Wait before the attempt
1	30 seconds
2	1 minute
3	2 minutes
4	4 minutes

If every attempt fails, the full chain takes about 7.5 minutes.

Retry-After header

If your endpoint responds with 429 Too Many Requests or 503 Service Unavailable, it can include a Retry-After header to set how long Seen waits before the next attempt. Both formats are supported:

• Seconds: Retry-After: 120
• HTTP-date: Retry-After: Mon, 09 Nov 2026 12:00:00 GMT

Seen clamps the value to a minimum of 30 seconds and a maximum of 1 hour. If your endpoint asks for the maximum on every retry, the full chain can take up to about 4 hours.

Duplicate requests

Each retry sends the same request again: the same URL, the same body and the headers you configured. There is no extra header that marks a request as a retry.

Delivery is at-least-once, so your endpoint may receive the same request more than once, for example when it processed a request but its response did not reach Seen within the timeout. Make your endpoint handle duplicates safely, for example by including a unique identifier from your Workspace properties in the request content and skipping any identifier you have already processed.

Best Practice: Respond First, Process Later

Your webhook endpoint should follow a "fire and forget" pattern. Return a 200 OK response immediately upon receiving the request, then handle any heavy processing asynchronously in the background.

If your endpoint performs slow operations (database writes, API calls to other services, sending emails) before responding, you risk exceeding the 5-second timeout, which triggers unnecessary retries and potentially duplicate processing.

Recommended approach:

1. Receive the webhook request
2. Return 200 OK immediately
3. Process the payload asynchronously (e.g. via a message queue or background job)

Security

No Authentication

Use this if you are using an endpoint with no authentication header.

Basic Auth

Sends requests with username and password authentication. Requires HTTPS for security.

OAuth

OAuth 2.0 Client Credentials flow for server-to-server authentication. The system will automatically request and manage access tokens using the provided credentials.

Fill out the following fields to configure OAuth authentication:

• Token URL
• Client ID
• Client Secret
• Grant Type
• Scope

JWT to Token

JWT to Token flow for server-to-server authentication. The system will automatically request and manage access tokens using the provided credentials.

Fill out the following fields to configure JWT to Token authentication:

• JWT Token
• Token URL
• Method (POST, GET, PUT, PATCH)
• Token Key found on the response: add the JSON key where the Token should be located in the response