Targets

A target is usually an endpoint that serves as a destination for the events generated by a publisher. A target can receive multiple events from either the same or different publishers.

Here are a couple of examples of the target:

• In UPI-based payment applications, events like invalid payment attempts, unusual account activities, and anomalies in transaction patterns are delivered immediately to the fraud detection software. Here, the event data is shared to a webhook endpoint (target) which helps the fraud detection software to act accordingly.

• In social media applications, events related to advertising campaigns, sponsored posts, and promotional activities are delivered to marketing software to assess campaign performances and optimize strategies. In this scenario, the event data is shared to Catalyst Circuits (target) which helps marketing software to process and act without human intervention.

Key Aspects

Targets are responsible for processing the incoming events according to predefined rules and filters within it. This processing in Signals may involve actions such as data extraction and transformation, dispatch, and triggering a downstream process.

Target Types

The platform supports the following various types of targets, which trigger downstream processes within them:

• Webhooks are HTTP callbacks that help you to share real-time data between applications. They are commonly used for event-driven integration between systems.

• Functions are configured to execute in response to received events. They consist of code snippets written in Java, Node.js and Python programming languages to perform specific tasks or execute business logic in targets.

• Circuits automate processes based on incoming events using predefined workflows. They allow you to design complex event-driven workflows without the need for coding.

A single webhook/function/circuit can be used multiple times in a Catalyst Project in different target configuration name with variations in the dispatch policy, retry policy or body setup.

Event Dispatch Timeouts

When an event is dispatched to a target, Signals wait for a specified period for the target to respond. If the target fails to respond within this timeframe, the event is marked as Failed.

Following are the time intervals for each target type:

Dispatch Policy

Catalyst Signals offer the flexibility in receiving events either individually in a queue or collectively as a batch. You can also customize each of these types.

• Instant - Events are received instantly every time they occur in the publisher system. You can set a customized Time To Live period for the events to remain in Signals before sending them to the target.

• Batch - Events are delivered collectively based on various dispatch methods and frequencies. The Time To Live period for events dispatched using this method is set to 24 hours by default and cannot be changed.

Learn more about the Types in the Dispatch policy.

Retry Policy

Whenever an event fails to communicate with the target, Signals allow up to 20 retry attempts for that specific event to reach the target. These retries happen automatically, and you can customize the retry counts or their frequency based on your use cases.

• Auto - In automatic frequency mode, the first retry attempt occurs one minute after the failed event. If the first retry was also a failure, the subsequent retries follow an exponential interval pattern based on the previous failure time.

For example, if an event fails to reach the target, the first retry happens one minute after the failure. If this retry fails, each following retry will occur at intervals that double the previous time, up to 10 minutes.

The intervals will be as follows: second retry - 2 minutes, third retry - 4 minutes, fourth retry - 8 minutes, fifth and subsequent retries - 10 minutes. This pattern continues until the event reaches the target or the configured retry count is reached.

• Manual - In this mode, you can manually set the frequency interval for the retry attempts. You can configure it either in terms of hours or minutes based on your requirement. This frequency should be compatible with the Time To Live period of the events and must not exceed it. The manual frequency can be configured between one minute and one hour.

Placeholders

The placeholders play a crucial role in defining the headers or parameters of the webhook associated with this target. The field is visible only when you have used dynamic values for the headers and parameters in a webhook and associated it to this target. For static values, you can directly add your values according to your use cases. However, for dynamic values, you must specify the JSON path of the key in the event schema.

Event Transformation

Event Schemas are automatically generated alongside the events and emitted to Signals. In the Targets page of Rules, you can customize the schemas before delivering them to the targets. You can either share the entire payload to the target or perform extraction and transformation to suit your business requirements.

• Extraction - This action allows you to retrieve a specific key from the existing event schema and construct a new schema only with that property. This filters out unnecessary details for your configured workflows and shares only the optimized event data to the targets.

• Transformation - This enables you to modify the key names and values within the event schema to align with your desired format. It provides the compatibility with your workflows or downstream processes in the target environment.

Step-by-step guide to extract and transform an event schema