# Signals ## Getting Started -------------------------------------------------------------------------------- title: "Introduction" description: "Learn about getting started with Catalyst Signals that helps you establish seamless communication between decoupled applications." last_updated: "2026-03-18T07:41:08.641Z" source: "https://docs.catalyst.zoho.com/en/signals/getting-started/introduction/" service: "Signals" -------------------------------------------------------------------------------- # What is Catalyst Signals? Catalyst Signals is a cutting-edge event bus service that transforms how organizations adopt Event-Driven Architectures (EDAs) to streamline operations and improve efficiency. It enables near-instantaneous communication between decoupled applications and services, ensuring your workflows remain responsive, scalable, and reliable. Signals simplifies event-driven architectures by eliminating the need for extensive coding or complex configurations. Its intuitive interface makes it easy for users across different technical backgrounds to design and manage event flows between {{%link href="/en/signals/help/publishers/key-aspects/"%}}Publishers{{%/link%}} and {{%link href="/en/signals/help/targets/key-aspects/"%}}Targets{{%/link%}}. ### Predefined Publishers and Schemas Catalyst Signals comes with a rich collection of predefined publishers from Zoho services and Catalyst’s own CloudScale services, including {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-authentication"%}}Authentication{{%/link%}}, {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-cache"%}}Cache{{%/link%}}, {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-data-store"%}}Data Store{{%/link%}}, {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-file-store"%}}File Store{{%/link%}} and {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-stratus"%}}Stratus{{%/link%}}. These services come along with default events associated with their schemas, eliminating the need for manual schema creation. For Zoho service like {{%link href="https://www.zoho.com/en-in/crm/"%}}CRM{{%/link%}}, even custom modules are kept in sync to ensure compatibility during event transformations and webhook configurations. Even for custom publishers, you can generate schema from {{%link href="/en/signals/help/publishers/create-publisher/custom-publishers/#live"%}}live event payloads{{%/link%}}. By removing the friction of schema setup, Catalyst Signals enables quick onboarding of business-critical workflows across applications. ### Flexible and Robust Event Orchestration Once events are captured, Catalyst Signals gives you full control over how they’re processed and routed. You can define smart rules to filter and transform events, assign delivery modes, configure retries, and route events to multiple targets like {{%link href="/en/signals/help/webhooks/key-aspects/"%}}webhooks{{%/link%}}, {{%link href="/en/serverless/help/functions/event-functions/"%}}functions{{%/link%}} or {{%link href="/en/serverless/help/circuits/implementation/"%}}circuits{{%/link%}}. Failures during delivery can now automatically trigger Application Alerts integrated from Catalyst DevOps. This enables teams to receive real-time email notifications and take immediate action about failed events. Additionally, Connections from Catalyst's Security & Identity services (under CloudScale) are built into the Webhook configuration, ensuring events are delivered securely to authorized endpoints with minimal effort. Each function or circuit receiving a Signal can be monitored independently using the logs available in their respective consoles, offering deeper visibility and traceability in event flow execution. ### Empowering Digital Transformation Catalyst Signals acts as a *Catalyst* for businesses modernizing their systems and embracing digital transformation. By combining Signals with other Catalyst components organizations can build scalable, loosely coupled systems that rapidly adapt to changes. Whether you’re automating internal workflows, reacting to user behavior, or synchronizing data across distributed systems, Catalyst Signals offers a flexible, low-maintenance foundation to optimize operations and drive innovation at scale. ### Architecture Let's walk you through the outright architecture of Signals to connect with multiple cloud environments to process and deliver real-time data. An {{%link href="/en/signals/help/events/"%}}event{{%/link%}} is a JSON-formatted message that represents a change or occurrence in a system. The {{%link href="/en/signals/help/targets/key-aspects/"%}}Target{{%/link%}} applications listen to these events from the {{%link href="/en/signals/help/publishers/key-aspects/"%}}Publisher{{%/link%}} to perform orchestrations. In this process, the event from one software source acts as a trigger for workflows in different software. Targets receive event details through {{%link href="/en/signals/help/webhooks/key-aspects/"%}}Webhooks{{%/link%}}, {{%link href="/en/serverless/help/functions/event-functions/"%}}Functions{{%/link%}}, and {{%link href="/en/serverless/help/circuits/introduction/"%}}Circuits{{%/link%}}. Imagine that you have a travel and hospitality company called **Travel Bureau**. It has an online platform for booking accommodations, flights, and other travel related services. The company uses multiple services for handling different aspects of reservation management, customer service and support, personalized recommendations, and more. <!-- Here's an overview of Signals implementation for the Travel Bureau. --> <!-- IMAGE --> - **Booking Service**: When a user makes a booking on the company's platform, it publishes a 'New Booking' event to the Catalyst Signals. - **Reservation Management**: The Reservation Service subscribes to the 'New Booking' event. Upon receiving the event, it collects the details from it, such as reservation dates, customer preferences, and service selections. With these details, it updates and manages the reservation in real-time. - **Customer Service and Support**: The Customer Service also subscribes to the 'New Booking' event. Once the booking is completed, it reaches out to the user and inquires about any specific requirements, requests, and complaints, if any. - **Personalized Recommendations**: The Recommendation Engine listens for the 'New Booking' event with the user's preferences and service selections. It generates personalized recommendations for accommodations, activities, and destinations based on it. This helps in enhancing the user experience and increasing conversion rates. Catalyst Signals connects these software sources to deliver outstanding end-user experiences and optimize operations through real-time event processing and intelligent automation. Continue on to the next page to learn about the core elements and other features of Signals in detail. -------------------------------------------------------------------------------- title: "Ecosystem" description: "Learn about getting started with Catalyst Signals that helps you establish seamless communication between decoupled applications." last_updated: "2026-03-18T07:41:08.644Z" source: "https://docs.catalyst.zoho.com/en/signals/getting-started/ecosystem/" service: "Signals" -------------------------------------------------------------------------------- # Ecosystem of Signals {{%fieldset title="Elements"%}} {{%fieldset-card icon="signal-events-icon" path="/en/signals/help/events/" title="Events"%}} A significant occurrence of action or change within an application.{{%/fieldset-card%}} {{%fieldset-card icon="signal-publishers-icon" path="/en/signals/help/publishers/key-aspects/" title="Publishers"%}}A publisher is the primary source of events.{{%/fieldset-card%}} {{%fieldset-card icon="signal-rules-icon" path="/en/signals/help/rules/key-aspects/" title="Rules"%}}It guides the ingestion of incoming events from publisher to target. {{%/fieldset-card%}} {{%fieldset-card icon="signal-target-icon" path="/en/signals/help/targets/key-aspects/" title="Targets"%}}An endpoint or application that serves as a destination for events.{{%/fieldset-card%}} {{%fieldset-card icon="signal-webhook-icon" path="/en/signals/help/webhooks/key-aspects/" title="Webhooks"%}}An HTTP-based callback function that allows event-driven communication between decoupled apps.{{%/fieldset-card%}} {{%/fieldset%}} As depicted above, Catalyst Signals comprises of various elements, each with a specific functionality and scope. {{%link href="/en/signals/help/events/"%}}{{%bold%}}Events{{%/bold%}}{{%/link%}}: This refers to any significant occurrence of action or change within an environment or application. {{%link href="/en/signals/help/publishers/key-aspects/"%}}{{%bold%}}Publisher{{%/bold%}}{{%/link%}}: It acts as a source from where events will be published. The component helps in authenticating and managing the list of sources. It can either be any of the Zoho products, or a custom product. {{%link href="/en/signals/help/rules/key-aspects/"%}}{{%bold%}}Rules{{%/bold%}}{{%/link%}}: They establish a relationship between the Publisher and the Target. This relationship is based on the rule containing filters that determine when and where to convey the events from the Publisher. {{%link href="/en/signals/help/targets/key-aspects/"%}}{{%bold%}}Targets{{%/bold%}}{{%/link%}}: A target is usually an endpoint that serves as a destination for the events generated by a Publisher. Signals support three types of targets: Webhooks, {{%link href="/en/serverless/help/functions/introduction/"%}}Functions{{%/link%}} and {{%link href="/en/serverless/help/circuits/introduction/"%}}Circuits{{%/link%}}. {{%link href="/en/signals/help/webhooks/key-aspects/"%}}{{%bold%}}Webhooks{{%/bold%}}{{%/link%}}: This is one of the majorly used target types to which the event details are shared with. The component holds the necessary configurations for a webhook to be used in Signals. -------------------------------------------------------------------------------- title: "Benefits" description: "Learn about getting started with Catalyst Signals that helps you establish seamless communication between decoupled applications." last_updated: "2026-03-18T07:41:08.652Z" source: "https://docs.catalyst.zoho.com/en/signals/getting-started/benefits/" service: "Signals" -------------------------------------------------------------------------------- # Benefits ### Serverless Management Catalyst Signals streamlines event-driven development through serverless architecture. This approach eliminates the need for infrastructure management and focus solely on crafting and deploying the event-driven applications. With Catalyst Signals, you can easily handle event processing and delivery, which results in accelerating the development cycle and boosting productivity. ### No-Code Event Management The platform facilitates connections and integrations between any applications or services, including the third-party ones. You can configure easy, streamlined workflows and transfer data between these systems without writing code. Setting up custom publishers and their events is also code-free. Additionally, you can customize the event schemas based on your requirements for each {{%link href="/en/signals/help/targets/key-aspects/"%}}Target{{%/link%}} in a {{%link href="/en/signals/help/rules/key-aspects/"%}}Rule{{%/link%}} without any coding. ### Scalable and Resilient Experience unparalleled scalability and resilience with Catalyst Signals. Its robust infrastructure effortlessly manages millions of events, ensuring optimal performance even under the most demanding workloads. It helps you stay agile and responsive while adapting to dynamic requirements with ease. ### Modernization of Monolithic Architectures Catalyst Signals simplifies the transformation of monolithic architectures by introducing seamless workflow decoupling and high-performance event broadcasting. This modernization initiative enhances agility, enabling swift adaptation and innovation in a rapidly changing landscape. ### Ad-hoc Integrations The trouble-free ad-hoc integrations between {{%link href="/en/signals/help/publishers/key-aspects/"%}}Publishers{{%/link%}} and {{%link href="/en/signals/help/targets/key-aspects/"%}}Targets{{%/link%}} allow you to process and deliver real-time data across diverse cloud environments. Catalyst Signals reduces development efforts and enhances operational efficiency as you need not configure workflows or handle integrations between applications through code. This will help organizations to quickly adapt to the various business needs and thrive in dynamic market conditions. ### Centralized Management Gain control with a centralized framework for tracking, monitoring, and managing events through the {{%link href="/en/signals/help/logs/"%}}Logs{{%/link%}} and {{%link href="/en/signals/help/dasbhoard/"%}}Dashboard{{%/link%}}. Make your performance optimization simpler and ensure compliance with your application requirements. With this deeper insight into event {{%link href="/en/signals/help/rules/key-aspects/"%}}rules{{%/link%}}, you can enhance operational efficiency and foster proactive decision-making across your event-driven architecture landscape. -------------------------------------------------------------------------------- title: "Use Cases" description: "Learn about getting started with Catalyst Signals that helps you establish seamless communication between decoupled applications." last_updated: "2026-03-18T07:41:08.652Z" source: "https://docs.catalyst.zoho.com/en/signals/getting-started/use-cases/" service: "Signals" -------------------------------------------------------------------------------- # Real-Life Use Cases Catalyst Signals presents a multitude of benefits across various scenarios to meet diverse needs. This section provides you with a glimpse into the versatility and potential of real-time event processing and dynamic scalability with Signals. ### 1. Lead Qualification Automation #### Scenario Upon completion of a {{%link href="https://www.zoho.com/survey/help/"%}}Zoho Survey{{%/link%}} response, you need to automate lead qualification in {{%link href="https://www.zoho.com/crm/help/"%}}Zoho CRM{{%/link%}}. #### Solution Zoho Survey (publisher) sends a **Response Completion** event to a {{%link href="/en/quickml/help/pipeline-endpoints/"%}}Quick ML endpoint{{%/link%}} (target) that is configured as a {{%link href="/en/signals/help/webhooks/key-aspects/"%}}webhook{{%/link%}} in Signals. Quick ML assesses lead qualification based on various criteria, including demographic information and behavior patterns. ### 2. Advanced Lead Enrichment #### Scenario To enhance lead data after creating a lead in {{%link href="https://www.zoho.com/crm/help/"%}}Zoho CRM{{%/link%}} to refine lead nurturing. #### Solution Zoho CRM (publisher) triggers a **New Lead Created** event to a {{%link href="/en/serverless/help/functions/introduction/"%}}Catalyst Function{{%/link%}} (target) through Signals. The function uses {{%link href="/en/smartbrowz/"%}}Catalyst SmartBrowz{{%/link%}} to scrape company details to enrich the lead data. Additionally, you can prioritize leads based on this data for higher conversion potential. ### 3. Automate Record Creation #### Scenario A customer portal application developed in Catalyst needs to automatically create records in the {{%link href="https://www.zoho.com/crm/help/"%}}Zoho CRM{{%/link%}} Deals module whenever an order is placed. #### Solution The Customer Portal Application (publisher) sends an Order Placed event to a REST API URL of {{%link href="https://www.zoho.com/crm/developer/docs/functions/"%}}Zoho CRM Functions{{%/link%}} (target), which is configured as a webhook in Signals. Using the received event details, the function creates a deal record in Zoho CRM. ### 4. Data Extraction and Approval Process #### Scenario Whenever a document is uploaded in an insurance company, you need to perform automatic data extraction and approval based on its contents using Optical Character Recognition (OCR). #### Solution The Insurance Company (publisher) sends a Document Uploaded event to {{%link href="/en/serverless/help/functions/introduction/"%}}Catalyst Functions{{%/link%}}(target) via Signals. The function uses {{%link href="/en/zia-services/"%}}Zia Services{{%/link%}} for OCR processing and automates the approval process based on the validation results. ### 5. Feedback Classification for Dynamic Decision-Making #### Scenario Whenever feedback is submitted on your business website, you need to classify it as positive, negative, or neutral for active decision-making. #### Solution The website (publisher) sends a Feedback Submitted event to the {{%link href="/en/serverless/help/functions/introduction/"%}}Catalyst Functions{{%/link%}} (target) via Signals. The function uses the Text Analytics feature of {{%link href="/en/zia-services/"%}}Zia Services{{%/link%}} to classify the feedback based on overall text sentiment. ### 6. Product Replacement in E-Commerce #### Scenario To streamline product replacement processes in an online platform and update the inventory and issuing dispatch products daily at a specific time. #### Solution The online platform (publisher) emits the Product Replacement events for each replacement request. These events are collected and delivered to {{%link href="/en/serverless/help/circuits/introduction/"%}}Catalyst Circuits{{%/link%}}(targets) via Signals based on a scheduled Batch policy. The circuit generates replacement orders, updates {{%link href="https://www.zoho.com/in/inventory/support/"%}}Zoho Inventory{{%/link%}}, and manages inventory accordingly. ### 7. Real-Time Integration with SaaS platform #### Scenario To share Shopify purchase details with {{%link href="https://www.zoho.com/analytics/help/"%}}Zoho Analytics{{%/link%}} and {{%link href="https://www.zoho.com/in/inventory/support/"%}}Zoho Inventory{{%/link%}} for sales analysis. #### Solution Shopify (publisher) generates and emits the Purchase Completion event to {{%link href="/en/serverless/help/functions/introduction/"%}}Catalyst Functions{{%/link%}} (target) through Signals. The function relays the event data to Zoho Inventory and Zoho Analytics for real-time sales analysis. -------------------------------------------------------------------------------- title: "Quick Start Guide" description: "Learn about getting started with Catalyst Signals that helps you establish seamless communication between decoupled applications." last_updated: "2026-03-18T07:41:08.652Z" source: "https://docs.catalyst.zoho.com/en/signals/getting-started/quick-start-guide/" service: "Signals" -------------------------------------------------------------------------------- # A Quick Start Guide Catalyst Signals is a user-friendly event bus service that helps you establish near instantaneous communication between applications. In this guide, we will walk you through the process of setting up a publisher, creating a webhook, and configuring rules to seamlessly manage your events. ## Create a Catalyst Project Log in to your {{%link href="https://console.catalyst.zoho.com/"%}}Catalyst Console{{%/link%}} and create a {{%link href="/en/getting-started/quick-start-guide/#step-1-create-a-catalyst-project"%}}new project{{%/link%}} to leverage the components of Catalyst Signal and other services from the console. ## Accessing Catalyst Signals Elements Navigate to the Catalyst Signals in the left service menu, then click **Start Exploring**. ### Step 1 - Add your Publisher In the {{%link href="/en/signals/help/publishers/key-aspects/"%}}Publishers{{%/link%}} section, you can either add publishers from the default services offered in Catalyst Signals or create a {{%link href="/en/signals/help/publishers/create-publisher/custom-publishers/"%}}Custom Publisher{{%/link%}} of your choice. A few Zoho services and Catalyst Cloud Scale services are supported, along with a set of defined events for easy configuration. For {{%link href="/en/signals/help/publishers/create-publisher/zoho-publishers/"%}}Zoho{{%/link%}} and {{%link href="/en/signals/help/publishers/create-publisher/catalyst-publishers/"%}}Catalyst{{%/link%}} Publishers, internal authorization facilitates event reception. However, for Custom publishers, you need to provide the REST API URL of the events in your publisher application to receive events in Signals. {{%link href="/en/signals/help/publishers/create-publisher/custom-publishers/"%}}Learn how to create a custom publisher{{%/link%}} ### Step 2 - Create a Webhook Navigate to the Webhooks section within the Signals service, then create a webhook by providing the necessary details. In the Additional Settings of webhooks, configure the dispatch rate limits, headers, and parameters for the HTTPS webhook call. Refer to {{%link href="/en/signals/help/targets/create-webhook/"%}}this{{%/link%}} document for detailed guidelines. Instead of using a webhook, you also have the option to create {{%link href="/en/serverless/help/functions/event-functions/"%}}functions{{%/link%}} and {{%link href="/en/serverless/help/circuits/implementation/"%}}circuits{{%/link%}} from the Catalyst Serverless to configure downstream workflows in your target systems. ### Step 3 - Configure Rule Shift to the Rules section and {{%link href="/en/signals/help/rules/create-rule/"%}}create a rule{{%/link%}} for a specific event from your publishers' list. To receive only relevant events, you can filter the events based on the properties available in the event payload. Further, you can determine how events should be delivered to {{%link href="/en/signals/help/targets/key-aspects/"%}}Target{{%/link%}}, which includes {{%link href="/en/signals/help/targets/dispatch-policy/"%}}dispatch policy{{%/link%}}, consumer types, Time To Live, and retries. Transform the event payload effortlessly with a three-pane view, showcasing the existing payload, your {{%link href="/en/signals/help/targets/event-body-setup/event-transformation/"%}}mapping{{%/link%}}, and the transformed payload. ### Step 4 - Monitoring Once the configured rule executes, you can monitor its performance using {{%link href="/en/signals/help/logs/"%}}Logs{{%/link%}} or the {{%link href="/en/signals/help/dasbhoard/"%}}Dashboard{{%/link%}} to get a quick glimpse of each configured rule in a {{%link href="/en/getting-started/catalyst-projects/"%}}Catalyst Project{{%/link%}}. Perform a {{%link href="/en/deployment-and-billing/environments/initial-deployment/"%}}migration{{%/link%}} to deploy these rules to the {{%link href="/en/deployment-and-billing/environments/production-environment/"%}}production environment{{%/link%}} of Catalyst. With Catalyst Signals, you can efficiently decouple different applications or components of a system, enabling them to operate automatically without any human interventions. ## Help Components -------------------------------------------------------------------------------- title: "Events" description: "An Event in Catalyst Signals is the core element of capturing and describing any significant change or occurrence within an application." last_updated: "2026-03-18T07:41:08.652Z" source: "https://docs.catalyst.zoho.com/en/signals/help/events/" service: "Signals" -------------------------------------------------------------------------------- # Events Events are a fundamental part of Catalyst Signals, describing any significant change or occurrence within an environment or application. They encircle a broad spectrum of actions and triggers ranging from user interactions to external stimuli. These events, in turn, serve as another trigger for innumerable actions or workflows across different environments or applications. In Catalyst Signals, these events are pivotal in driving real-time processing, automation, and seamless integration of disparate systems and applications. With this tool, you can capture, process, and route these events to various endpoints called {{%link href="/en/signals/help/targets/key-aspects/"%}}Targets{{%/link%}}. Here are a couple of examples for an event: - In an **ecommerce marketing website**, when a customer places an order, the inventory management application is automatically updated. In this scenario, the event is the Order Placement. - In a **CRM application**, when a lead is created, the organization's website displays product recommendations based on the lead's details. In this scenario, lead creation serves as the event. ### Event Statuses To track the events within the Signals environment, they are categorized by their processing status. This represents the overall performance of an event, regardless of how many rules it is associated with or how many targets it is delivered to. The execution status of each rule and target can be found in the {{%link href="/en/signals/help/logs/"%}}logs help page{{%/link%}}. The overall event performance statuses in Signals are mentioned as follows: - **Received** - Events received in Signals from all types of publishers. - **In Queue** - Events received but not yet processed. - **In Progress** - Events that are currently being processed. - **Success** - For an event to be marked as a success, it must be delivered to every target, across all associated rules. - **Failed** - Events that failed to be delivered to at least one target, in any of the associated rules, will carry an overall status as Failed. - **Unmatched** - Events that did not meet the conditions configured in the rule filters or have no active rules or targets, and therefore were not processed. - **Unprocessed** - Events that are associated with an inactive publisher, rule, or target. - **Dropped** - Events associated with a deleted or disabled target or rule. {{%note%}}{{%bold class="bold-primary"%}}Note{{%/bold%}} The overall Event Status is determined by the {{%link href="/en/signals/help/logs/#comprehensive-event-capture"%}}Event Execution Statuses{{%/link%}}, which track how an event performs across each rule and target it's associated with. - The overall Event Status follow this priority order: **Failed > Dropped > Success**. - If any execution is marked as **Failed** or **Dropped**, the event status will also be marked as **Failed** or **Dropped**. - If both **Failed** and **Dropped** execution statuses exist for an event, the overall event status will be marked as **Failed**, since it takes higher priority. {{%/note%}} ### Zoho Events The preconfigured services for {{%link href="/en/signals/help/publishers/create-publisher/zoho-publishers/"%}}Zoho publishers{{%/link%}} come equipped with default events, each accompanied by its own schema. This automated setup streamlines event management by eliminating the need for manual schema creation. Events from Zoho services are received into Signals through the internal authorization process of Catalyst with other services.Therefore, you need not perform any authorization configurations for Zoho publishers. Events will be defined by default for **custom modules** created within {{%link href="https://www.zoho.com/en-in/crm/"%}}Zoho CRM{{%/link%}}. **Custom fields** are also synchronized periodically to ensure trouble-free integration with event schemas during event transformation and webhook creation in Signals. The supported services for custom fields synchronization include: - {{%link href="https://www.bigin.com/"%}}Zoho Bigin{{%/link%}} - {{%link href="https://www.zoho.com/in/billing/"%}}Zoho Billing{{%/link%}} - {{%link href="https://www.zoho.com/in/books/"%}}Zoho Books{{%/link%}} - {{%link href="https://www.zoho.com/en-in/crm/"%}}Zoho CRM{{%/link%}} - {{%link href="https://www.zoho.com/in/expense/"%}}Zoho Expense{{%/link%}} - {{%link href="https://www.zoho.com/in/inventory/"%}}Zoho Inventory{{%/link%}} - {{%link href="https://www.zoho.com/us/invoice/"%}}Zoho Invoice{{%/link%}} {{%link href="/en/signals/help/publishers/create-publisher/zoho-publishers/"%}}Click here for the full list of supported Zoho Publishers{{%/link%}} ### Catalyst Events A few Catalyst services are also supported as default {{%link href="/en/signals/help/publishers/create-publisher/catalyst-publishers/"%}}Catalyst Publishers{{%/link%}} in Signals. Each Catalyst service comes with its own set of predefined events and corresponding schemas. These events are automatically listed when the service is added as a publisher, eliminating the need for manual configuration. This allows you to seamlessly capture infrastructure-level changes such as data updates, cache modifications, file actions, or authentication activities and route them through Signals for monitoring, analytics, or integration with downstream processes. {{%note%}}{{%bold class="bold-primary"%}}Notes:{{%/bold%}} * {{%link href="/en/cli/v1/event-generate/sample-payload-catalyst-pub/" %}}Generate Sample Payload for Custom Events{{%/link%}}. * The default events of Zoho publisher are categorized into five main scopes: {{%bold%}}Create{{%/bold%}}, {{%bold%}}Delete{{%/bold%}}, {{%bold%}}Update{{%/bold%}}, {{%bold%}}Approve{{%/bold%}}, and {{%bold%}}Reject{{%/bold%}}. Each scope represents a distinct type of action that results in generating and emitting events to the {{%link href="/en/signals/help/targets/key-aspects/"%}}targets{{%/link%}}. {{%/note%}} ### Custom Events To receive custom events in Signals, the REST API key for these events has to be configured within the custom publisher application. Additionally, a sample payload of the specific event is required to generate its schema. Catalyst Signals offers two methods for adding event payloads to generate schemas: - **Live Event Payload**: You can use the URL provided in this method to capture the payload of an API call and populate it with the necessary keys to use it as an event schema. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} The URL provided for capturing an event payload is only valid for {{%bold%}}15 minutes{{%/bold%}}. {{%/note%}} - **Manual Event Payload**: In this method, you need to manually provide the payload to generate the event schema. {{%link href="/en/signals/help/publishers/create-publisher/custom-publishers/"%}}Instructions for creating custom events and schemas for custom publishers{{%/link%}} {{%note%}}{{%bold%}}Note:{{%/bold%}} * You can create and configure up to {{%bold%}}200 events{{%/bold%}} across all publishers. This threshold is configured for baseline and standard scenarios only. We strongly urge you to email us at {{%link href="mailto:support@zohocatalyst.com" %}}support@zohocatalyst.com{{%/link%}} with your requirement to increase this soft threshold. * Learn more about {{%link href="/en/cli/v1/event-generate/sample-payload-catalyst-pub/#sample-payload-for-custom-events" %}}generating sample payloads for Custom Events{{%/link%}}.{{%/note%}} ### Event Schema Event Schema contains the metadata of the events to provide additional context and information about the event. You can also edit the event schema and tailor it to your requirements to further trigger the workflows in the target environment. {{%link href="/en/signals/help/targets/event-body-setup/event-transformation/"%}}Learn how to extract or transform an event schema{{%/link%}} Although this has been auto-generated by Catalyst Signals, let us analyze the default keys of an event schema to understand the processing of the events. {{%panel_with_adjustment class="language-json line-numbers" header="Event Schema" footer="button" scroll="set-scroll" %}}{ "$schema": "https://json-schema.org/draft/2020-12/schema#", "type": "object", "properties": { "rule_id": { "type": "string" }, "target_id": { "type": "string" }, "version": { "type": "integer" }, "attempt": { "type": "integer" }, "account": { "type": "object", "properties": { "org_id": { "type": "string" }, "project": { "type": "object", "properties": { "environment": { "type": "string" }, "name": { "type": "string" }, "id": { "type": "string" } } } } }, "events": { "type": "array", "items": { "type": "object", "properties": { "data": { "type": "object" <!-- properties of an event --> }, "id": { "type": "string" }, "time_in_ms": { "type": "string" }, "source": { "type": "string" }, "event_config": { "type": "object", "properties": { "api_name": { "type": "string" }, "id": { "type": "string" } } } } } } } } {{%/panel_with_adjustment%}} Here is a sample event payload generated based on the schema for your reference. {{%panel_with_adjustment class="language-json line-numbers" header="Sample Event Payload" footer="button" scroll="set-scroll" %}}{ "rule_id": "123456789", "target_id": "98765432", "version": 1, "attempt": 1, "account": { "org_id": "87359421", "project": { "environment": "DEVELOPMENT", "name": "Project-Rainfall", "id": "12950000000020015" } }, "events": [ { "data": { <!-- properties of an event --> }, "id": "b05f449e-7eb0-4e7f-a40f-662820729d20", "time_in_ms": 1721312979144, "source": "publisher_id:12950000000021006/service:zohocrm/account:87394113", "event_config": { "api_name": "Lead Created", "id": "12950000000021007" } } ] } {{%/panel_with_adjustment%}} #### Default API Keys in Schema <table class="content-table"> <thead> <tr> <th class="w10p">S.No.</th> <th class="w15p">API Name</th> <th class="w15p">Data Type</th> <th class="w60p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>{{%badge%}}rule_id{{%/badge%}}</td> <td>long string</td> <td>This is the unique ID of the {{%link href="/en/signals/help/rules/key-aspects/"%}}rule{{%/link%}} upon which the event has been generated.</td> </tr> <tr> <td>2</td> <td>{{%badge%}}target_id{{%/badge%}}</td> <td>long string</td> <td>It refers to the unique ID of the {{%link href="/en/signals/help/targets/key-aspects/"%}}target{{%/link%}} to which the events and their details are delivered.</td> </tr> <tr> <td>3</td> <td>{{%badge%}}version{{%/badge%}}</td> <td>integer</td> <td>The key represents the version of the event schema in Catalyst Signals.</td> </tr> <tr> <td>4</td> <td>{{%badge%}}attempt{{%/badge%}}</td> <td>integer</td> <td>It denotes the current number of attempt for the event to reach the target. <br />Attempts greater than one corresponds to the {{%link href="/en/signals/help/targets/key-aspects/#retry-policy"%}}retry count{{%/link%}} configured in the rule.</td> </tr> <tr> <td>5</td> <td>{{%badge%}}account{{%/badge%}}</td> <td>object</td> <td>This comprises the following catalyst account details: <ul> <li>{{%bold%}}org_id (string){{%/bold%}} - The key refers to the {{%link href="/en/getting-started/catalyst-organizations/"%}}Catalyst organization{{%/link%}} ID using which the events are configured.</li> <li>{{%bold%}}project (object){{%/bold%}} - It contains the name {{%bold%}}(string){{%/bold%}}, {{%bold%}}environment (string){{%/bold%}} and {{%bold%}}id (string){{%/bold%}} of the {{%link href="/en/getting-started/catalyst-projects/"%}}Catalyst project{{%/link%}} used to access the Signals service.</li> </ul></td> </tr> <tr> <td>6</td> <td>{{%badge%}}events{{%/badge%}}</td> <td>array</td> <td>This is an array of objects. Each object in the array refers to one of the configured events of the {{%link href="/en/signals/help/publishers/key-aspects/"%}}publisher{{%/link%}}. <br /> The following are the default keys present in the objects of this array: <ul> <li>{{%bold%}}data (object){{%/bold%}} - The object contains the event details. <!-- {{%link href=" "%}}Learn more about this key{{%/link%}} --> </li> <li>{{%bold%}}id (long string){{%/bold%}} - It represents the unique ID of an event for this particular occurrence.</li> <li>{{%bold%}}time_in_ms (integer){{%/bold%}} - This key denotes the time of event generation in milliseconds.</li> <li>{{%bold%}}source (string){{%/bold%}} - This contains the publisher ID, service name, and its account ID separated by a slash (/).</li> <li>{{%bold%}}event_config (object){{%/bold%}} - This comprises of the {{%bold%}}id (long string){{%/bold%}} and {{%bold%}}api_name (string){{%/bold%}} of the event.</li> </ul></td> </tr> </tbody> </table> {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} {{%list%}}* The keys within the {{%bold%}}data{{%/bold%}} object differs for each and every event as it represents and describes the event. You can {{%bold%}}add/remove keys{{%/bold%}} within the data object depending on your requirements.{{%/list%}} {{%list%}}* You can also remove the default keys from the schema. {{%link href="/en/signals/help/targets/event-body-setup/event-transformation/"%}}Learn how to customize the event schema{{%/link%}}{{%/list%}} {{%/note%}} -------------------------------------------------------------------------------- title: "Dashboard" description: " Dashboard in Catalyst Signals provides an analytical view of events within a project for efficient event management." last_updated: "2026-03-18T07:41:08.653Z" source: "https://docs.catalyst.zoho.com/en/signals/help/dashboard/" service: "Signals" -------------------------------------------------------------------------------- # Dashboard The Analytics dashboard of Catalyst Signals provides a consolidated view of the event performances within a Catalyst project. It presents the data in an easy-to-understand format, allowing you to draw valuable insights. This includes analyzing trends, identifying patterns, and making informed decisions to optimize system performance and ensure seamless event processing. You can use the refresh icon in the title bar to get real-time updates of the event performances. The time drop-down in the top-left corner of the dashboard lets you adjust the time period of the data you find in the dashboard. The default view is set to the **Last 3 hours** and offers an incremental time period. You even have a range calendar to get a complete analysis of your required business periods. ### Event Chart The line graph illustrates the number of events processed in the Signals service over time, measured in minutes. It offers great flexibility by allowing you to adjust the time period, ranging from **one minute interval to a maximum of 15 minutes**. The icons below the chart help you adjust this interval with the help of a time scale. The graph represents three distinct lines, each representing the status of the events. - **Received** - All the events received in Signals from the publishers are denoted in blue color. - **Success** - Events that have successfully met the rule conditions and delivered to the targets are represented in the green color. - **Failed** - Events that have met the rule conditions but failed to reach the target due to any errors are denoted in the red color. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} Events that failed to reach the target after the configured Retry Counts will only be marked as {{%bold%}}Failed{{%/bold%}}. {{%/note%}} Visualizing the number of events processed over time and differentiating between event statuses help you to understand the performance, reliability, and overall health of your event rules. ### Event Statistics This statistics provide understanding into the number and percentage of events across different event processing status. It helps in understanding the anomalies and identifying areas of improvement to ensure an effective event processing. The following even statuses will be displayed: - **Received** - This denotes the total number of events that have been received by Signals from all the publishers. - **In Queue** - This represents the total number of events that have been received and not started to process. - **In Progress** - This denotes the total number of events that are currently under event processing. - **Success** - This indicates the total number of events that have been successfully delivered to the targets without encountering any errors. - **Failed** - This represents the total number of events that failed to be delivered to the target due to any errors. - **Unmatched** - This indicates the total number of events that did not meet the conditions configured in the rule filters or had no active rules or targets, and therefore were not processed. - **Dropped** - This denotes the total number of events that are dropped when either the target or rule is disabled or deleted. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} The {{%bold%}}Success{{%/bold%}} and {{%bold%}}Failed{{%/bold%}} statuses display the Key Performance Indicator metrics in terms of percentage relative to the selected time interval that is visible in the top-right corner of the title bar. For example, if the period is set to {{%bold%}}Last 3 hours{{%/bold%}}, the percentage will reflect the comparison with the previous 3 hours. {{%/note%}} ### Top Publishers This element lists the top five publishers and their total number of events irrespective of their status. This helps you gain deeper understanding of which publishers are most active and effective in generating valuable events. Recognizing these sources of significant event traffic helps you to assess the impact of individual publishers on the overall event processing workflow.This assists you in taking data driven decisions to enhance the performance and effectiveness of their event processing workflows. ### Most Failures The element highlights the top five failure targets, along with the number of failed events and their associated consumer type and name. It helps you to pinpoint areas of concern within your event processing workflow. This information facilitates focused debugging and troubleshooting that allows you to collaborate more efficiently with relevant teams responsible for managing the affected targets. -------------------------------------------------------------------------------- title: "Logs" description: "Logs in Catalyst Signals help you track the overall event performance along with its status across multiple rules and targets. " last_updated: "2026-03-18T07:41:08.653Z" source: "https://docs.catalyst.zoho.com/en/signals/help/logs/" service: "Signals" -------------------------------------------------------------------------------- # Logs Event logs provide a comprehensive record of all the events processed within the Signals. Each time a subscribed event occurs in the publisher system, a unique ID is generated and logged here with the time stamp, status, and other relevant details. It acts as a valuable source of insight which the managements can use to monitor, analyze, and effectively troubleshoot their event rules. <!-- to do: change the colors in the image --> ## Key Aspects ### Log Details Event logs capture details about each event processed within the system, including event source, timestamp, status, dispatch type, and the number of attempts taken to reach the target in the details view page. Refer to the {{%link href="/en/signals/help/events/#event-statuses"%}}Event Statuses{{%/link%}} help page to learn more about each status. This data enables organizations to gain visibility into event flows and track the lifecycle of individual events. <!-- to do: New image --> ### Comprehensive Event Capture Signals offers a **Log Details View** of an event that has been deployed in multiple {{%link href="/en/signals/help/rules/key-aspects/"%}}rules{{%/link%}} and {{%link href="/en/signals/help/targets/key-aspects/"%}}targets{{%/link%}} to achieve certain business requirements. Within the log page, you can track a particular event's performance across different rules and targets to help you analyze its flow and performance metrics. Following are the list of event execution statuses used for it, - **In Queue** - The event has been processed according to the rule configurations and is now queued for delivery to the target. - **In Progress** - Events that are currently being delivered to the target. - **Success** - The event has been successfully delivered to the target specified in the rule. - **Failed** - The event was either not delivered to the specified target in the rule or the target failed to respond to the received event. - **Dropped** - The event is linked to a target or rule that has been deleted or disabled. - **Batching** - The event is part of a batch that will be delivered to the target according to the selected dispatch policy. - **Scheduled** - The event has been received by Signals and is set to be delivered to the target at a scheduled time. - **Retry Scheduled** - When an event failed to reach the target, this denotes that a retry has been scheduled based on the configured {{%link href="/en/signals/help/targets/key-aspects/#retry-policy"%}}retry policy{{%/link%}}. {{%note%}}{{%bold class="bold-primary"%}}Note{{%/bold%}} Each event is assigned an overall {{%link href="/en/signals/help/events/#event-statuses"%}}Event Status{{%/link%}}, which summarizes its delivery outcome across all associated targets. This status is influenced by the Event Execution Statuses. - The overall Event Status follow this priority order: **Failed > Dropped > Success**. - If any execution is marked as **Failed** or **Dropped**, the event status will also be marked as **Failed** or **Dropped**. - If both **Failed** and **Dropped** execution statuses exist for an event, the overall event status will be marked as **Failed**, since it takes higher priority. {{%/note%}} <!-- to do: gif showing this status --> ### Log filters The filter icon on the top-left corner of the logs' list view page offers a range of filters that can help you locate specific events. The filters are categorized based on targets, status, rules, events and their Unique ID. In '**Filter By Events**', you can search for events by selecting its service, publisher, and the subscribed events. <!-- to do: changes in the UI colors and status so replace gif --> ### Debugging and Troubleshooting Each event log includes the status of the event processing flow. If an event fails, you can hover over its **Failed** status in the details view to see the failure message. This helps you quickly analyze errors, identify root causes, and resolve issues efficiently, ensuring system reliability. If an event is delivered to a {{%link href="/en/serverless/help/functions/event-functions/"%}}Function{{%/link%}} or a {{%link href="/en/serverless/help/circuits/implementation/"%}}Circuit{{%/link%}} as a target, a **Logs** icon appears next to it. - For **Functions**, clicking the icon takes you to the {{%link href="/en/devops/help/logs/introduction/"%}}Logs{{%/link%}} page in {{%link href="/en/devops/"%}}DevOps{{%/link%}}, where function logs are recorded. - For **Circuits**, it redirects you to the {{%link href="/en/serverless/help/circuits/implementation/#execution-history-of-a-circuit"%}}Circuit Execution History{{%/link%}} page in the {{%link href="/en/serverless/"%}}Serverless{{%/link%}}. If the target function takes too long to respond to an event, you can terminate it using the **Kill Function** icon next to the Logs icon. Terminating a function moves the event to a **Dropped** status, and the event data cannot be recovered. -------------------------------------------------------------------------------- title: "Deployment Notes" description: " Dashboard in Catalyst Signals provides an analytical view of events within a project for efficient event management." last_updated: "2026-03-18T07:41:08.653Z" source: "https://docs.catalyst.zoho.com/en/signals/help/deployment/" service: "Signals" -------------------------------------------------------------------------------- # Deployment Notes Catalyst by Zoho supports two distinct environments - **Development** and **Production**. This allows you to build, test, and validate your application in a sandboxed space before moving stable components to a live production environment. To understand the differences and usage of these environments, refer to the {{%link href="/en/deployment-and-billing/environments/introduction/"%}}Catalyst Environments help guide.{{%/link%}} Below are key considerations when deploying Catalyst Signals to the production environment: ### Deployment User Permissions The user initiating the deployment in Catalyst must be an admin in the {{%link href="/en/signals/help/publishers/create-publisher/zoho-publishers"%}}Zoho Publisher{{%/link%}} applications used. This is essential to ensure proper authorization between Catalyst Signals and Zoho publishers. ### Deploy All Dependent Catalyst Components If your Signals setup uses other Catalyst components, such as: - {{%link href="/en/cloud-scale/"%}}Cloud Scale{{%/link%}} Services as publishers - Serverless {{%link href="/en/serverless/help/functions/event-functions/"%}}Functions{{%/link%}} or {{%link href="/en/serverless/help/circuits/implementation/"%}}Circuits{{%/link%}} as {{%link href="/en/signals/help/targets/key-aspects/"%}}targets{{%/link%}} - Connections for {{%link href="/en/signals/help/webhooks/key-aspects/"%}}webhook{{%/link%}} authorization Ensure that all these **dependent components are deployed together** with Catalyst Signals. ### Publisher Deployment Limit You can deploy a **maximum of 25 publishers** to the production environment in a **single deployment**. This limit applies regardless of the publisher type supported in Signals. ### Rules Are Locked in Production In the production environment, you are permitted to **enable or disable** existing rules. However, you **cannot create, edit, or delete** rules directly in production. All structural changes to rules must be made in the development environment and then deployed. For **Zoho CRM Publisher**, you can **modify the organization associated with it during deployment**. This allows you to switch from a Sandbox organization used in development environment to the corresponding Production organization during deployment. ### Align Custom Components Before deploying Catalyst Signals, ensure that all custom modules and custom fields used in your rules within the development environment are available in the production organization during deployment. ### Publishers -------------------------------------------------------------------------------- title: "Key Aspects" description: "Publishers in Catalyst Signals are the primary source of generating and emitting events in which the targets are interested. " last_updated: "2026-03-18T07:41:08.654Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/key-aspects/" service: "Signals" -------------------------------------------------------------------------------- # Publishers A publisher is the primary source of events within a system. They generate events when an action or change occurs in an application in which the {{%link href="/en/signals/help/targets/key-aspects/"%}}targets{{%/link%}} are interested. Publishers are usually scalable to handle high volumes of event generation, and it can either be any Zoho or other external SAAS products. Here are a couple of examples for Publishers: - A ride-sharing **mobile application** serves as a Publisher, generating and emitting events whenever a driver is assigned to notify the user. - **Zoho Inventory** acts as a Publisher, emitting events whenever there is an update to the inventory list to change the stock count in an e-commerce platform. Publishers play a crucial role in enabling real-time event processing and event-driven workflows within targeted systems. ## Key Aspects ### Default Publishers Catalyst Signals offers a set of default publishers for ease of use. Additionally, you can also create your own authorized publisher and events in the Catalyst Signals. The default publishers are categorized into two types as follows: - {{%link href="/en/signals/help/publishers/create-publisher/zoho-publishers/"%}}{{%bold%}}Zoho Publishers{{%/bold%}}{{%/link%}}: This comprises all the products of Zoho with a set of default events based on the service provided by the product. Only the Zoho products created using the same ID as the Catalyst can be configured. - {{%link href="/en/signals/help/publishers/create-publisher/catalyst-publishers/"%}}{{%bold%}}Catalyst Publishers{{%/bold%}}{{%/link%}}: This lists down the Catalyst publishers and their supported events by default. Only the Catalyst Services created for the same project and organization can be configured. - {{%link href="/en/signals/help/publishers/create-publisher/custom-publishers/"%}}{{%bold%}}Custom Publishers{{%/bold%}}{{%/link%}}: You can create new publishers with the product of your choice. You will have to add, configure your own events, and provide the required REST API URLs. ### No-Code Schema Zoho and Catalyst publishers in Signals include event schema for each event by default. Even for {{%link href="/en/signals/help/publishers/create-publisher/custom-publishers/"%}}custom publishers{{%/link%}}, adding just the event payload will auto-generate the schema for the custom events. You can manually add the event payload or use the {{%link href="/en/signals/help/publishers/create-publisher/custom-publishers/#live"%}}Live Event Payload{{%/link%}} option to capture it from an API call. Customizing an existing schema is also easy with just JSON path in Signals. {{%link href="/en/signals/help/targets/event-body-setup/event-transformation/"%}}Event Transformation guide{{%/link%}} ### Event Ordering Event Ordering ensures that events are delivered to the target in the same order they were received from the publisher. This is particularly useful for workflows that rely on **sequential event processing**. This feature works across all publisher types - Zoho, Catalyst, and Custom. When event ordering is enabled, Signals maintains the sequence of events as long as each one is successfully delivered on the first attempt. If an event fails and enters the **Dropped** status, it will be retried according to the configured retry policy. Subsequent events will still be delivered in the order they were received. To learn more about retry handling and event statuses, see the {{%link href="/en/signals/help/targets/key-aspects/#retry-policy"%}}Retry Policy{{%/link%}} and {{%link href="/en/signals/help/events/#event-statuses"%}}Event Statuses{{%/link%}} help page. #### Creating a Publisher -------------------------------------------------------------------------------- title: "Zoho Publishers" description: "Catalyst Signals provide a set of default Zoho Publishers to ease the flow of establishing an event-driven architecture." last_updated: "2026-03-18T07:41:08.654Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/create-publisher/zoho-publishers/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Publishers Catalyst Signals provide default support to a few Zoho products, and you can establish a rule with them at ease. Following are the current Zoho products that are provided as default publishers. - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-bigin/"%}}Zoho Bigin{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-billing/"%}}Zoho Billing{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-books/"%}}Zoho Books{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-commerce/"%}}Zoho Commerce{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-crm/"%}}Zoho CRM{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-expense/"%}}Zoho Expense{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-inventory/"%}}Zoho Inventory{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-invoice/"%}}Zoho Invoice{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-meeting/"%}}Zoho Meeting{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-survey/"%}}Zoho Survey{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-assist/"%}}Zoho Assist{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-campaigns/"%}}Zoho Campaigns{{%/link%}} - {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-marketing-automation/"%}}Zoho Marketing Automation{{%/link%}} {{%note%}}{{%bold%}}Note:{{%/bold%}} You can configure up to {{%bold%}}100{{%/bold%}} Zoho Publishers. This threshold is configured for baseline and standard scenarios only. We strongly urge you to email us at {{%link href="mailto:support@zohocatalyst.com" %}}support@zohocatalyst.com{{%/link%}} with your requirement to increase this soft threshold.{{%/note%}} Catalyst Signals establishes connection with these default products through internal authorization. This eliminates the need for manual authorization and configuration of scopes, which results in a streamlined process. ### Creating a Zoho Publisher 1. Navigate to Publishers on the left menu and click the Add Publisher button. 2. Choose the Publisher type you want to add. 3. Select the Zoho service that you want to add as a publisher. 4. Fill in the details as shown in the below image. The values for the **API Name** field should not contain any white spaces or hyphens and must not exceed **50** characters. It accepts underscores and alphanumeric values but cannot start with a numeric value. The **Organization** field lists the organizations you have either created or joined using the same email address. 5. Enable **Event Ordering** to ensure events are delivered in the same order they were received. Refer to the {{%link href="/en/signals/help/publishers/key-aspects/#event-ordering"%}}Event Ordering{{%/link%}} help section to learn more. 6. Click the **Save** button in the top-right corner after providing the mandatory details. 7. An authorization message pops-up, and requests to access the data of the Zoho service you have created. Click **Authorize** to continue. ### Add Events from Zoho Publisher **Subscribed Events** of a Zoho Publisher are those with which you have created a {{%link href="/en/signals/help/rules/key-aspects/"%}}rule{{%/link%}}. Whereas, **Non-Subscribed Events** are the default events that have not yet been associated with any rule. 1. Once you create the publisher, an Events tab appears below the General Details section, listing all supported events for the service. 2. Click the **Add Rule** button to go to the Create Rule page, where you can subscribe to an event from the publisher. For more guidance, refer to the {{%link href="/en/signals/help/rules/create-rule/"%}}Create Rule{{%/link%}} help page. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} * The maximum allowed size for a single occurrence of an event from a Zoho publisher, generated and emitted to Signals, is {{%bold%}}100 KB{{%/bold%}}. * An event can also carry data for multiple occurrences of the same event, with a combined size of up to {{%bold%}}5 MB{{%/bold%}}. There is no upper limit on the number of times a particular event can occur. * You need to ensure that the required PII configurations pertaining to the data stored in the Publisher ({{%bold%}}Zoho Services{{%/bold%}}) needs to be restricted at the publisher service level. This would ensure continued compliance with industry standard data practices. {{%/note%}} -------------------------------------------------------------------------------- title: "Catalyst Publishers" description: "Catalyst Signals provide a set of default Catalyst services as Publishers to ease the flow of establishing an event-driven architecture within the Catalyst ecosystem." last_updated: "2026-03-18T07:41:08.654Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/create-publisher/catalyst-publishers/" service: "Signals" -------------------------------------------------------------------------------- # Catalyst Publishers Catalyst Signals offers default publisher support for several services within the Catalyst ecosystem, allowing you to easily set up event rules based on activities in these services. This helps you build responsive workflows or trigger functions automatically when specific events occur. Following are the current Catalyst publishers provided as default: - {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-authentication"%}}Cloud Scale Authentication{{%/link%}} - {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-cache"%}}Cloud Scale Cache{{%/link%}} - {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-data-store"%}}Cloud Scale Data Store{{%/link%}} - {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-file-store"%}}Cloud Sclae File Store{{%/link%}} - {{%link href="/en/signals/event-help/catalyst-publishers#cloud-scale-stratus"%}}Cloud Scale Stratus{{%/link%}} {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} You can configure these publishers only for services that belong to the same project and organization. Make sure the respective service is active and set up in your project before configuring it in Signals.{{%/note%}} ### Creating a Catalyst Publisher 1. Navigate to Publishers on the left menu and click the Add Publisher button. 2. Choose the Publisher type as **Catalyst Publishers**. 3. Select the Catalyst service that you want to add as a publisher. 4. Fill in the details as shown in the below image. The values for the API Name field should not contain any white spaces or hyphens and must not exceed 50 characters. It can contain underscores and alphanumeric values but cannot start with a numeric value. The Organization and Project fields lists only the current organization and project as same as the Catalyst Signals project. 5. Enable **Event Ordering** to ensure events are delivered in the same order they were received. Refer to the {{%link href="/en/signals/help/publishers/key-aspects/#event-ordering"%}}Event Ordering{{%/link%}} help section to learn more. 6. Click the **Save** button in the top-right corner after providing the required details. ### Add Events from Catalyst Publishers 1. Once you create the publisher, an Events tab appears below the General Details section, listing all supported events for the service. 2. Click the **Add Rule** button to go to the Create Rule page, where you can subscribe to an event from the publisher. For more guidance, refer to the {{%link href="/en/signals/help/rules/create-rule/"%}}Create Rule{{%/link%}} help page. -------------------------------------------------------------------------------- title: "Custom Publishers" description: "Build custom publishers in Catalyst Signals to connect your targets with third-party applications and automate workflows without human intervention." last_updated: "2026-03-18T07:41:08.654Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/create-publisher/custom-publishers/" service: "Signals" -------------------------------------------------------------------------------- # Custom Publishers In addition to the existing default publishers, you can create new publishers with the product of your choice. For custom publishers, you must add your own events. To ensure these events are received in Signals, provide the REST API URL of the custom events in the publisher application where the events will be posted. The API URL supports up to **500 requests per minute**. If this threshold is exceeded, the REST API will be locked for the next 60 seconds. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} * The REST API URL generated for custom events in the {{%link href="en/deployment-and-billing/environments/development-environment/"%}}development environment{{%/link%}} differs from the URL created for the same custom events in the {{%link href="/en/deployment-and-billing/environments/production-environment/"%}}production environment{{%/link%}}. Ensure you replace the URL when moving the project to production. * You can create and configure up to {{%bold%}}25{{%/bold%}} Custom Publishers. This threshold is configured for baseline and standard scenarios only. We strongly urge you to email us at {{%link href="mailto:support@zohocatalyst.com" %}}support@zohocatalyst.com{{%/link%}} with your requirement to increase this soft threshold.{{%/note%}} ### Creating a Custom Publisher To add a custom publisher: 1. Navigate to **Publishers** on the left menu and click the **Add Publisher** button. 2. Go to the **Create Your Own Publisher** section in the menubar and fill in the necessary details as shown here. Enable **Event Ordering** to ensure events are delivered in the same order they were received and click **Save**. Refer to the {{%link href="/en/signals/help/publishers/key-aspects/#event-ordering"%}}Event Ordering{{%/link%}} help section to learn more. 3. To add a custom event after providing the publisher details, click the **Add Event** button near the Events section. 4. Fill in the details of Events and click **Save**. The values for the **API Name** field should not contain any white spaces or hyphens and must not exceed **50** characters. It accepts underscores and alphanumeric values but cannot start with a numerical value. ### Add Schema to Custom Events 1. Click **Add Schema** of the custom event that you have created. 2. A pop-up will appear with two methods to generate schema using the event payload. #### Manual You can manually add the schema to the custom events. Select the **Manual** option and provide the request payload of the event. The default keys of an event schema will be automatically populated on the right for the provided payload. #### Live To capture an API call's request payload and populate it here, select the **Live Events** option and copy the URL displayed here. Provide this URL in the Publisher from which the API call is made. In the GIF shown above, the live events URL is copied and provided to the publisher system. This URL listens to the publisher's API calls for the next 15 minutes and displays them on this platform. You can select the required payload from the listened API calls and add its schema to the custom events. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} The URL to capture the live events will last for only {{%bold%}}15 minutes{{%/bold%}}.{{%/note%}} 3. Once you have generated the event schema, you can subscribe the event by associating it with a rule. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} * For custom publishers, the maximum allowed size for events generated and emitted to Signals is {{%bold%}}64 KB{{%/bold%}}, with an array of events up to {{%bold%}}256 KB{{%/bold%}}, limited to a maximum of 25 events. * You need to ensure that the required PII configurations pertaining to the data stored in the Custom Publisher service needs to be restricted at the publisher service level. This would ensure continued compliance with industry standard data practices.{{%/note%}} #### Supported Events -------------------------------------------------------------------------------- title: "Catalyst Publishers" description: "Publishers in Catalyst Signals are the primary source of generating and emitting events in which the targets are interested. " last_updated: "2026-03-18T07:41:08.655Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/catalyst-publishers/" service: "Signals" -------------------------------------------------------------------------------- # Catalyst Publishers Following are the default events supported for various Catalyst Publishers: ### Cloud Scale Authentication <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>User Signup</td> <td>{{%badge%}}user_signedup{{%/badge%}}</td> <td>An event is generated when a user signs up to the app using Catalyst Authentication.</td> </tr> <tr> <td>2</td> <td>User Confirmation</td> <td>{{%badge%}}user_confirmed{{%/badge%}}</td> <td>An event is generated when a user successfully verifies their account using Catalyst Authentication.</td> </tr> <tr> <td>3</td> <td>User Delete</td> <td>{{%badge%}}user_deleted{{%/badge%}}</td> <td>An event is generated when a user is removed using Catalyst Authentication.</td> </tr> </tbody> </table> ### Cloud Scale Cache <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Item Create</td> <td>{{%badge%}}cache_item_created{{%/badge%}}</td> <td>An event is generated when an item is created in Cache Segment.</td> </tr> <tr> <td>2</td> <td>Item Update</td> <td>{{%badge%}}cache_item_updated{{%/badge%}}</td> <td>An event is generated when a cached item is updated in Cache Segment.</td> </tr> </tbody> </table> ### Cloud Scale Data Store <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Row Insert</td> <td>{{%badge%}}row_inserted{{%/badge%}}</td> <td>An event is generated when a new row is inserted to the table in Catalyst Data Store.</td> </tr> <tr> <td>2</td> <td>Row Delete</td> <td>{{%badge%}}row_deleted{{%/badge%}}</td> <td>An event is generated when a row is deleted in the table in Catalyst Data Store.</td> </tr> <tr> <td>3</td> <td>Row Update</td> <td>{{%badge%}}row_updated{{%/badge%}}</td> <td>An event is generated when a row is updated in the table in Catalyst Data Store.</td> </tr> </tbody> </table> ### Cloud Scale File Store <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>File Upload</td> <td>{{%badge%}}filestore_file_uploaded{{%/badge%}}</td> <td>An event is generated when a file is uploaded to a folder in File Store.</td> </tr> </tbody> </table> ### Cloud Scale Stratus <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Object Download</td> <td>{{%badge%}}ustratus_object_downloaded{{%/badge%}}</td> <td>An event is generated when an object is downloaded from a bucket in Stratus.</td> </tr> <tr> <td>2</td> <td>Object Upload</td> <td>{{%badge%}}stratus_object_uploaded{{%/badge%}}</td> <td>An event is generated when an object is uploaded to a bucket in Stratus.</td> </tr> <tr> <td>3</td> <td>Object Delete</td> <td>{{%badge%}}stratus_object_deleted{{%/badge%}}</td> <td>An event is generated when an object is deleted from a bucket in Stratus.</td> </tr> <tr> <td>4</td> <td>Object Update</td> <td>{{%badge%}}stratus_object_updated{{%/badge%}}</td> <td>An event is generated when an object is updated in a bucket in Stratus.</td> </tr> </tbody> </table> <!-- ### Cloud Scale Web Client Hosting <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Webapp Deploy</td> <td>{{%badge%}}webapp_deployed{{%/badge%}}</td> <td>An event is generated when you deploy your application in Cloud Scale's Web Client Hosting.</td> </tr> </tbody> </table> --> ##### Zoho Publishers -------------------------------------------------------------------------------- title: "Zoho Bigin" description: "List of default events supported for Zoho Bigin." last_updated: "2026-03-18T07:41:08.655Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-bigin/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Bigin Following are the default events supported for the Zoho Bigin Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w20p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Contact Created</td> <td>{{%badge%}}contact_created{{%/badge%}}</td> <td>An event is generated when a new contact is created in Zoho Bigin.</td> </tr> <tr> <td>2</td> <td>Call Created</td> <td>{{%badge%}}call_created{{%/badge%}}</td> <td>An event is generated when a new call is created in Zoho Bigin.</td> </tr> <tr> <td>3</td> <td>Call Deleted</td> <td>{{%badge%}}call_deleted{{%/badge%}}</td> <td>An event is generated when a call is deleted in Zoho Bigin.</td> </tr> <tr> <td>4</td> <td>Call Updated</td> <td>{{%badge%}}call_updated{{%/badge%}}</td> <td>An event is generated when a call is updated in Zoho Bigin.</td> </tr> <tr> <td>5</td> <td>Company Created</td> <td>{{%badge%}}account_created{{%/badge%}}</td> <td>An event is generated when a Company is created in Zoho Bigin.</td> </tr> <tr> <td>6</td> <td>Company Deleted</td> <td>{{%badge%}}account_deleted{{%/badge%}}</td> <td>An event is generated when a Company is deleted in Zoho Bigin.</td> </tr> <tr> <td>7</td> <td>Company Updated</td> <td>{{%badge%}}account_updated{{%/badge%}}</td> <td>An event is generated when a Company is updated in Zoho Bigin.</td> </tr> <tr> <td>8</td> <td>Contact Deleted</td> <td>{{%badge%}}contact_deleted{{%/badge%}}</td> <td>An event is generated when a contact is deleted in Zoho Bigin.</td> </tr> <tr> <td>9</td> <td>Contact Updated</td> <td>{{%badge%}}contact_updated{{%/badge%}}</td> <td>An event is generated when a contact is updated in Zoho Bigin.</td> </tr> <tr> <td>10</td> <td>Event Created</td> <td>{{%badge%}}event_created{{%/badge%}}</td> <td>An event is generated when a new event is created in Zoho Bigin</td> <tr> <td>11</td> <td>Event Updated</td> <td>{{%badge%}}event_updated{{%/badge%}}</td> <td>An event is generated when an event is updated in Zoho Bigin.</td> </tr> <tr> <td>12</td> <td>Pipeline Created</td> <td>{{%badge%}}deal_created{{%/badge%}}</td> <td>An event is generated when a Pipeline is created in Zoho Bigin.</td> </tr> <tr> <td>13</td> <td>Pipeline Deleted</td> <td>{{%badge%}}deal_deleted{{%/badge%}}</td> <td>An event is generated when a Pipeline is deleted in Zoho Bigin.</td> </tr> <tr> <td>14</td> <td>Pipeline Updated</td> <td>{{%badge%}}deal_updated{{%/badge%}}</td> <td>An event is generated when a Pipeline is updated in Zoho Bigin.</td> </tr> <tr> <td>15</td> <td>Product Created</td> <td>{{%badge%}}product_created{{%/badge%}}</td> <td>An event is generated when a new product is created in Zoho Bigin.</td> </tr> <tr> <td>16</td> <td>Product Deleted</td> <td>{{%badge%}}product_deleted{{%/badge%}}</td> <td>An event is generated when a product is updated in Zoho Bigin.</td> </tr> <tr> <td>17</td> <td>Product Updated</td> <td>{{%badge%}}product_updated{{%/badge%}}</td> <td>An event is generated when a product is updated in Zoho Bigin.</td> </tr> <tr> <td>18</td> <td>Task Created</td> <td>{{%badge%}}task_created{{%/badge%}}</td> <td>An event is generated when a new task is created in Zoho Bigin.</td> </tr> <tr> <td>19</td> <td>Task Deleted</td> <td>{{%badge%}}task_deleted{{%/badge%}}</td> <td>An event is generated when a task is deleted in Zoho Bigin.</td> </tr> <tr> <td>20</td> <td>Task Updated</td> <td>{{%badge%}}task_updated{{%/badge%}}</td> <td>An event is generated when a task is updated in Zoho Bigin.</td> </tr> <tr> <td>21</td> <td>Event Deleted</td> <td>{{%badge%}}event_deleted{{%/badge%}}</td> <td>An event is generated when an event is deleted in Zoho Bigin.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Billing" description: "List of default events supported for Zoho Billing." last_updated: "2026-03-18T07:41:08.655Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-billing/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Billing Following are the default events supported for the Zoho Billing Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w25p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Subscription Created</td> <td>{{%badge%}}subscription_created{{%/badge%}}</td> <td>An event is generated when a subscription is created in Zoho Billing.</td> </tr> <tr> <td>2</td> <td>Subscription Updated</td> <td>{{%badge%}}subscription_updated{{%/badge%}}</td> <td>An event is generated when a subscription is updated in Zoho Billing.</td> </tr> <tr> <td>3</td> <td>Subscription Renewed</td> <td>{{%badge%}}subscription_renewed{{%/badge%}}</td> <td>An event is generated when a subscription is renewed in Zoho Billing.</td> </tr> <tr> <td>4</td> <td>Subscription Cancelled</td> <td>{{%badge%}}subscription_cancelled{{%/badge%}}</td> <td>An event is generated when a subscription is cancelled in Zoho Billing.</td> </tr> <tr> <td>5</td> <td>Subscription Deleted</td> <td>{{%badge%}}subscription_deleted{{%/badge%}}</td> <td>An event is generated when a subscription is deleted in Zoho Billing.</td> </tr> <tr> <td>6</td> <td>Subscription Paused</td> <td>{{%badge%}}subscription_paused{{%/badge%}}</td> <td>An event is generated when a subscription is paused in Zoho Billing.</td> </tr> <tr> <td>7</td> <td>Subscription Downgraded</td> <td>{{%badge%}}subscription_downgraded{{%/badge%}}</td> <td>An event is generated when a subscription is downgraded in Zoho Billing.</td> </tr> <tr> <td>8</td> <td>Subscription Upgraded</td> <td>{{%badge%}}subscription_upgraded{{%/badge%}}</td> <td>An event is generated when a subscription is upgraded in Zoho Billing.</td> </tr> <tr> <td>9</td> <td>Subscription Resumed</td> <td>{{%badge%}}subscription_resumed{{%/badge%}}</td> <td>An event is generated when a subscription is resumed in Zoho Billing.</td> </tr> <tr> <td>10</td> <td>Subscription Expired</td> <td>{{%badge%}}subscription_expired{{%/badge%}}</td> <td>An event is generated when a subscription is expired in Zoho Billing.</td> </tr> <tr> <td>11</td> <td>Subscription Unpaid</td> <td>{{%badge%}}subscription_unpaid{{%/badge%}}</td> <td>An event is generated when a subscription is unpaid in Zoho Billing.</td> </tr> <tr> <td>12</td> <td>Invoice Created</td> <td>{{%badge%}}invoice_created{{%/badge%}}</td> <td>An event is generated when an invoice is created in Zoho Billing.</td> </tr> <tr> <td>13</td> <td>Subscription Reactivated</td> <td>{{%badge%}}subscription_reactivated{{%/badge%}}</td> <td>An event is generated when a subscription is reactivated in Zoho Billing.</td> </tr> <tr> <td>14</td> <td>Invoice Updated</td> <td>{{%badge%}}invoice_updated{{%/badge%}}</td> <td>An event is generated when an invoice is updated in Zoho Billing.</td> </tr> <tr> <td>15</td> <td>Payment Refunded</td> <td>{{%badge%}}payment_refunded{{%/badge%}}</td> <td>An event is generated when a payment is refunded in Zoho Billing.</td> </tr> <tr> <td>16</td> <td>Payment Succeede</td> <td>{{%badge%}}payment_succeeded{{%/badge%}}</td>d <td>An event is generated when a payment succeeds in Zoho Billing.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Books" description: "List of default events supported for Zoho Books." last_updated: "2026-03-18T07:41:08.655Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-books/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Books Following are the default events supported for the Zoho Books Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w30p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Bill Created</td> <td>{{%badge%}}bill_created{{%/badge%}}</td> <td>An event is generated when a bill is created in Zoho Books.</td> </tr> <tr> <td>2</td> <td>Bill Updated</td> <td>{{%badge%}}bill_updated{{%/badge%}}</td> <td>An event is generated when a bill is updated in Zoho Books.</td> </tr> <tr> <td>3</td> <td>Estimate Created</td> <td>{{%badge%}}estimate_created{{%/badge%}}</td> <td>An event is generated when an estimate is created in Zoho Books.</td> </tr> <tr> <td>4</td> <td>Estimate Updated</td> <td>{{%badge%}}estimate_updated{{%/badge%}}</td> <td>An event is generated when an estimate is updated in Zoho Books.</td> </tr> <tr> <td>5</td> <td>Expense Created</td> <td>{{%badge%}}expense_created{{%/badge%}}</td> <td>An event is generated when an expense is created in Zoho Books.</td> </tr> <tr> <td>6</td> <td>Credit Note Created</td> <td>{{%badge%}}credit_note_created{{%/badge%}}</td> <td>An event is generated when a credit note is created in Zoho Books.</td> </tr> <tr> <td>7</td> <td>Credit Note Updated</td> <td>{{%badge%}}credit_note_updated{{%/badge%}}</td> <td>An event is generated when a credit note is updated in Zoho Books.</td> </tr> <tr> <td>8</td> <td>Customer Created</td> <td>{{%badge%}}customer_created{{%/badge%}}</td> <td>An event is generated when a customer is created in Zoho Books.</td> </tr> <tr> <td>9</td> <td>Customer Updated</td> <td>{{%badge%}}customer_updated{{%/badge%}}</td> <td>An event is generated when a customer is updated in Zoho Books.</td> </tr> <tr> <td>10</td> <td>Expense Updated</td> <td>{{%badge%}}expense_updated{{%/badge%}}</td> <td>An event is generated when an expense is updated in Zoho Books.</td> </tr> <tr> <td>11</td> <td>Invoice Created</td> <td>{{%badge%}}invoice_created{{%/badge%}}</td> <td>An event is generated when an invoice is created in Zoho Books.</td> </tr> <tr> <td>12</td> <td>Invoice Updated</td> <td>{{%badge%}}invoice_updated{{%/badge%}}</td> <td>An event is generated when an invoice is updated in Zoho Books.</td> </tr> <tr> <td>13</td> <td>Purchase Order Created</td> <td>{{%badge%}}purchase_order_created{{%/badge%}}</td> <td>An event is generated when a purchase order is created in Zoho Books.</td> </tr> <tr> <td>14</td> <td>Purchase Order Updated</td> <td>{{%badge%}}purchase_order_updated{{%/badge%}}</td> <td>An event is generated when a purchase order is updated in Zoho Books.</td> </tr> <tr> <td>15</td> <td>Sales Order Created</td> <td>{{%badge%}}sales_order_created{{%/badge%}}</td> <td>An event is generated when a sales order is created in Zoho Books.</td> </tr> <tr> <td>16</td> <td>Sales Order Updated</td> <td>{{%badge%}}sales_order_updated{{%/badge%}}</td> <td>An event is generated when a sales order is updated in Zoho Books.</td> </tr> <tr> <td>17</td> <td>Customer Payment Created</td> <td>{{%badge%}}customer_payment_created{{%/badge%}}</td> <td>An event is generated when a customer payment is created in Zoho Books.</td> </tr> <tr> <td>18</td> <td>Customer Payment Updated</td> <td>{{%badge%}}customer_payment_updated{{%/badge%}}</td> <td>An event is generated when a customer payment is updated in Zoho Books.</td> </tr> <tr> <td>19</td> <td>Vendor Payment Created</td> <td>{{%badge%}}vendor_payment_created{{%/badge%}}</td> <td>An event is generated when a vendor payment is created in Zoho Books.</td> </tr> <tr> <td>20</td> <td>Vendor Payment Updated</td> <td>{{%badge%}}vendor_payment_updated{{%/badge%}}</td> <td>An event is generated when a vendor payment is updated in Zoho Books.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Commerce" description: "List of default events supported for Zoho Commerce." last_updated: "2026-03-18T07:41:08.655Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-commerce/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Commerce Following are the default events supported for the Zoho Commerce Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Sales Order Created</td> <td>{{%badge%}}sales_order_created{{%/badge%}}</td> <td>An event is generated when a sales order is created in Zoho Commerce.</td> </tr> <tr> <td>2</td> <td>Sales Order Confirmed</td> <td>{{%badge%}}sales_order_confirmed{{%/badge%}}</td> <td>An event is generated when a sales order is confirmed in Zoho Commerce.</td> </tr> <tr> <td>3</td> <td>Sales Order Cancelled</td> <td>{{%badge%}}sales_order_cancelled{{%/badge%}}</td> <td>An event is generated when a sales order is cancelled in Zoho Commerce.</td> </tr> <tr> <td>4</td> <td>Sales Order Declined</td> <td>{{%badge%}}sales_order_declined{{%/badge%}}</td> <td>An event is generated when a sales order is declined in Zoho Commerce.</td> </tr> <tr> <td>5</td> <td>Sales Order Shipped</td> <td>{{%badge%}}sales_order_shipped{{%/badge%}}</td> <td>An event is generated when a sales order is shipped in Zoho Commerce.</td> </tr> <tr> <td>6</td> <td>Sales Order Delivered</td> <td>{{%badge%}}sales_order_delivered{{%/badge%}}</td> <td>An event is generated when a sales order is delivered in Zoho Commerce.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho CRM" description: "List of default events supported for Zoho CRM." last_updated: "2026-03-18T07:41:08.655Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-crm/" service: "Signals" -------------------------------------------------------------------------------- # Zoho CRM Following are the default events supported for the Zoho CRM Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Lead Created</td> <td>{{%badge%}}lead_created{{%/badge%}}</td> <td>An event is generated when a lead is created in Zoho CRM.</td> </tr> <tr> <td>2</td> <td>Lead Approved</td> <td>{{%badge%}}lead_approved{{%/badge%}}</td> <td>An event is generated when a lead is approved in Zoho CRM.</td> </tr> <tr> <td>3</td> <td>Lead Converted</td> <td>{{%badge%}}lead_converted{{%/badge%}}</td> <td>An event is generated when a lead is converted in Zoho CRM.</td> </tr> <tr> <td>4</td> <td>Lead Deleted</td> <td>{{%badge%}}lead_deleted{{%/badge%}}</td> <td>An event is generated when a lead is deleted in Zoho CRM.</td> </tr> <tr> <td>5</td> <td>Lead Rejected</td> <td>{{%badge%}}lead_rejected{{%/badge%}}</td> <td>An event is generated when a lead is rejected in Zoho CRM.</td> </tr> <tr> <td>6</td> <td>Lead Updated</td> <td>{{%badge%}}lead_updated{{%/badge%}}</td> <td>An event is generated when a lead is updated in Zoho CRM.</td> </tr> <tr> <td>7</td> <td>Account Approved</td> <td>{{%badge%}}account_approved{{%/badge%}}</td> <td>An event is generated when an account is approved in Zoho CRM.</td> </tr> <tr> <td>8</td> <td>Account Created</td> <td>{{%badge%}}account_created{{%/badge%}}</td> <td>An event is generated when an account is created in Zoho CRM.</td> </tr> <tr> <td>9</td> <td>Account Deleted</td> <td>{{%badge%}}account_deleted{{%/badge%}}</td> <td>An event is generated when an account is deleted in Zoho CRM.</td> </tr> <tr> <td>10</td> <td>Account Rejected</td> <td>{{%badge%}}account_rejected{{%/badge%}}</td> <td>An event is generated when an account is rejected in Zoho CRM.</td> </tr> <tr> <td>11</td> <td>Account Updated</td> <td>{{%badge%}}account_updated{{%/badge%}}</td> <td>An event is generated when an account is updated in Zoho CRM.</td> </tr> <tr> <td>12</td> <td>Contact Created</td> <td>{{%badge%}}contact_created{{%/badge%}}</td> <td>An event is generated when a contact is created in Zoho CRM.</td> </tr> <tr> <td>13</td> <td>Contact Deleted</td> <td>{{%badge%}}contact_deleted{{%/badge%}}</td> <td>An event is generated when a contact is deleted in Zoho CRM.</td> </tr> <tr> <td>14</td> <td>Contact Updated</td> <td>{{%badge%}}contact_updated{{%/badge%}}</td> <td>An event is generated when a contact is updated in Zoho CRM.</td> </tr> <tr> <td>15</td> <td>Contacts Approved</td> <td>{{%badge%}}contact_approved{{%/badge%}}</td> <td>An event is generated when a contact is approved in Zoho CRM.</td> </tr> <tr> <td>16</td> <td>Contacts Rejected</td> <td>{{%badge%}}contact_rejected{{%/badge%}}</td> <td>An event is generated when a contact is rejected in Zoho CRM.</td> </tr> <tr> <td>17</td> <td>Deal Approved</td> <td>{{%badge%}}deal_approved{{%/badge%}}</td> <td>An event is generated when a deal is approved in Zoho CRM.</td> </tr> <tr> <td>18</td> <td>Deal Created</td> <td>{{%badge%}}deal_created{{%/badge%}}</td> <td>An event is generated when a deal is created in Zoho CRM.</td> </tr> <tr> <td>19</td> <td>Deal Deleted</td> <td>{{%badge%}}deal_deleted{{%/badge%}}</td> <td>An event is generated when a deal is deleted in Zoho CRM.</td> </tr> <tr> <td>20</td> <td>Deal Rejected</td> <td>{{%badge%}}deal_rejected{{%/badge%}}</td> <td>An event is generated when a deal is rejected in Zoho CRM.</td> </tr> <tr> <td>21</td> <td>Deal Updated</td> <td>{{%badge%}}deal_updated{{%/badge%}}</td> <td>An event is generated when a deal is updated in Zoho CRM.</td> </tr> <tr> <td>22</td> <td>Product Created</td> <td>{{%badge%}}product_created{{%/badge%}}</td> <td>An event is generated when a product is created in Zoho CRM.</td> </tr> <tr> <td>23</td> <td>Campaign Approved</td> <td>{{%badge%}}campaign_approved{{%/badge%}}</td> <td>An event is generated when a campaign is approved in Zoho CRM.</td> </tr> <tr> <td>24</td> <td>Campaign Created</td> <td>{{%badge%}}campaign_created{{%/badge%}}</td> <td>An event is generated when a campaign is created in Zoho CRM.</td> </tr> <tr> <td>25</td> <td>Campaign Deleted</td> <td>{{%badge%}}campaign_deleted{{%/badge%}}</td> <td>An event is generated when a campaign is deleted in Zoho CRM.</td> </tr> <tr> <td>26</td> <td>Campaign Member Status Updated</td> <td>{{%badge%}}campaign_member_status{{%/badge%}}</td> <td>An event is generated when a campaign member status is updated in Zoho CRM.</td> </tr> <tr> <td>27</td> <td>Campaign Rejected</td> <td>{{%badge%}}campaign_rejected{{%/badge%}}</td> <td>An event is generated when a campaign is rejected in Zoho CRM.</td> </tr> <tr> <td>28</td> <td>Campaign Updated</td> <td>{{%badge%}}campaign_updated{{%/badge%}}</td> <td>An event is generated when a campaign is updated in Zoho CRM.</td> </tr> <tr> <td>29</td> <td>Case Approved</td> <td>{{%badge%}}case_approved{{%/badge%}}</td> <td>An event is generated when a case is approved in Zoho CRM.</td> </tr> <tr> <td>30</td> <td>Case Created</td> <td>{{%badge%}}case_created{{%/badge%}}</td> <td>An event is generated when a case is created in Zoho CRM.</td> </tr> <tr> <td>31</td> <td>Case Deleted</td> <td>{{%badge%}}case_deleted{{%/badge%}}</td> <td>An event is generated when a case is deleted in Zoho CRM.</td> </tr> <tr> <td>32</td> <td>Case Rejected</td> <td>{{%badge%}}case_rejected{{%/badge%}}</td> <td>An event is generated when a case is rejected in Zoho CRM.</td> </tr> <tr> <td>33</td> <td>Case Updated</td> <td>{{%badge%}}case_updated{{%/badge%}}</td> <td>An event is generated when a case is updated in Zoho CRM.</td> </tr> <tr> <td>34</td> <td>Product Approved</td> <td>{{%badge%}}product_approved{{%/badge%}}</td> <td>An event is generated when a product is approved in Zoho CRM.</td> </tr> <tr> <td>35</td> <td>Product Deleted</td> <td>{{%badge%}}product_deleted{{%/badge%}}</td> <td>An event is generated when a product is deleted in Zoho CRM.</td> </tr> <tr> <td>36</td> <td>Product Rejected</td> <td>{{%badge%}}product_rejected{{%/badge%}}</td> <td>An event is generated when a product is rejected in Zoho CRM.</td> </tr> <tr> <td>37</td> <td>Product Updated</td> <td>{{%badge%}}product_updated{{%/badge%}}</td> <td>An event is generated when a product is updated in Zoho CRM.</td> </tr> <tr> <td>38</td> <td>Solution Approved</td> <td>{{%badge%}}solution_approved{{%/badge%}}</td> <td>An event is generated when a solution is approved in Zoho CRM.</td> </tr> <tr> <td>39</td> <td>Solution Created</td> <td>{{%badge%}}solution_created{{%/badge%}}</td> <td>An event is generated when a solution is created in Zoho CRM.</td> </tr> <tr> <td>40</td> <td>Solution Deleted</td> <td>{{%badge%}}solution_deleted{{%/badge%}}</td> <td>An event is generated when a solution is deleted in Zoho CRM.</td> </tr> <tr> <td>41</td> <td>Solution Rejected</td> <td>{{%badge%}}solution_rejected{{%/badge%}}</td> <td>An event is generated when a solution is rejected in Zoho CRM.</td> </tr> <tr> <td>42</td> <td>Solution Updated</td> <td>{{%badge%}}solution_updated{{%/badge%}}</td> <td>An event is generated when a solution is updated in Zoho CRM.</td> </tr> <tr> <td>43</td> <td>PriceBook Approved</td> <td>{{%badge%}}price_book_approved{{%/badge%}}</td> <td>An event is generated when a price book is approved in Zoho CRM.</td> </tr> <tr> <td>44</td> <td>PriceBook Created</td> <td>{{%badge%}}price_book_created{{%/badge%}}</td> <td>An event is generated when a price book is created in Zoho CRM.</td> </tr> <tr> <td>45</td> <td>PriceBook Deleted</td> <td>{{%badge%}}price_book_deleted{{%/badge%}}</td> <td>An event is generated when a price book is deleted in Zoho CRM.</td> </tr> <tr> <td>46</td> <td>PriceBook Rejected</td> <td>{{%badge%}}price_book_rejected{{%/badge%}}</td> <td>An event is generated when a price book is rejected in Zoho CRM.</td> </tr> <tr> <td>47</td> <td>PriceBook Updated</td> <td>{{%badge%}}price_book_updated{{%/badge%}}</td> <td>An event is generated when a price book is updated in Zoho CRM.</td> </tr> <tr> <td>48</td> <td>Quote Approved</td> <td>{{%badge%}}quote_approved{{%/badge%}}</td> <td>An event is generated when a quote is approved in Zoho CRM.</td> </tr> <tr> <td>49</td> <td>Quote Converted</td> <td>{{%badge%}}quote_converted{{%/badge%}}</td> <td>An event is generated when a quote is converted in Zoho CRM.</td> </tr> <tr> <td>50</td> <td>Quote Created</td> <td>{{%badge%}}quote_created{{%/badge%}}</td> <td>An event is generated when a quote is created in Zoho CRM.</td> </tr> <tr> <td>51</td> <td>Quote Deleted</td> <td>{{%badge%}}quote_deleted{{%/badge%}}</td> <td>An event is generated when a quote is deleted in Zoho CRM.</td> </tr> <tr> <td>52</td> <td>Quote Rejected</td> <td>{{%badge%}}quote_rejected{{%/badge%}}</td> <td>An event is generated when a quote is rejected in Zoho CRM.</td> </tr> <tr> <td>53</td> <td>Quote Updated</td> <td>{{%badge%}}quote_updated{{%/badge%}}</td> <td>An event is generated when a quote is updated in Zoho CRM.</td> </tr> <tr> <td>54</td> <td>Vendor Approved</td> <td>{{%badge%}}vendor_approved{{%/badge%}}</td> <td>An event is generated when a vendor is approved in Zoho CRM.</td> </tr> <tr> <td>55</td> <td>Vendor Created</td> <td>{{%badge%}}vendor_created{{%/badge%}}</td> <td>An event is generated when a vendor is created in Zoho CRM.</td> </tr> <tr> <td>56</td> <td>Vendor Deleted</td> <td>{{%badge%}}vendor_deleted{{%/badge%}}</td> <td>An event is generated when a vendor is deleted in Zoho CRM.</td> </tr> <tr> <td>57</td> <td>Vendor Rejected</td> <td>{{%badge%}}vendor_rejected{{%/badge%}}</td> <td>An event is generated when a vendor is rejected in Zoho CRM.</td> </tr> <tr> <td>58</td> <td>Vendor Updated</td> <td>{{%badge%}}vendor_updated{{%/badge%}}</td> <td>An event is generated when a vendor is updated in Zoho CRM.</td> </tr> <tr> <td>59</td> <td>Invoice Approved</td> <td>{{%badge%}}invoice_approved{{%/badge%}}</td> <td>An event is generated when a invoice is approved in Zoho CRM.</td> </tr> <tr> <td>60</td> <td>Invoice Created</td> <td>{{%badge%}}invoice_created{{%/badge%}}</td> <td>An event is generated when a invoice is created in Zoho CRM.</td> </tr> <tr> <td>61</td> <td>Invoice Deleted</td> <td>{{%badge%}}invoice_deleted{{%/badge%}}</td> <td>An event is generated when a invoice is deleted in Zoho CRM.</td> </tr> <tr> <td>62</td> <td>Invoice Rejected</td> <td>{{%badge%}}invoice_rejected{{%/badge%}}</td> <td>An event is generated when a invoice is rejected in Zoho CRM.</td> </tr> <tr> <td>63</td> <td>Invoice Updated</td> <td>{{%badge%}}invoice_updated{{%/badge%}}</td> <td>An event is generated when a invoice is updated in Zoho CRM.</td> </tr> <tr> <td>64</td> <td>Note Approved</td> <td>{{%badge%}}note_approved{{%/badge%}}</td> <td>An event is generated when a note is approved in Zoho CRM.</td> </tr> <tr> <td>65</td> <td>Note Created</td> <td>{{%badge%}}note_created{{%/badge%}}</td> <td>An event is generated when a note is created in Zoho CRM.</td> </tr> <tr> <td>66</td> <td>Note Deleted</td> <td>{{%badge%}}note_deleted{{%/badge%}}</td> <td>An event is generated when a note is deleted in Zoho CRM.</td> </tr> <tr> <td>67</td> <td>Note Rejected</td> <td>{{%badge%}}note_rejected{{%/badge%}}</td> <td>An event is generated when a note is rejected in Zoho CRM.</td> </tr> <tr> <td>68</td> <td>Note Updated</td> <td>{{%badge%}}note_updated{{%/badge%}}</td> <td>An event is generated when a note is updated in Zoho CRM.</td> </tr> <tr> <td>69</td> <td>PurchaseOrder Approved</td> <td>{{%badge%}}purchase_order_approved{{%/badge%}}</td> <td>An event is generated when a purchase order is deleted in Zoho CRM.</td> </tr> <tr> <td>70</td> <td>PurchaseOrder Created</td> <td>{{%badge%}}purchase_order_created{{%/badge%}}</td> <td>An event is generated when a purchase order is created in Zoho CRM.</td> </tr> <tr> <td>71</td> <td>PurchaseOrder Deleted</td> <td>{{%badge%}}purchase_order_deleted{{%/badge%}}</td> <td>An event is generated when a purchase order is deleted in Zoho CRM.</td> </tr> <tr> <td>72</td> <td>PurchaseOrder Updated</td> <td>{{%badge%}}purchase_order_updated{{%/badge%}}</td> <td>An event is generated when a purchase order is updated in Zoho CRM.</td> </tr> <tr> <td>73</td> <td>SalesOrder Approved</td> <td>{{%badge%}}sales_order_approved{{%/badge%}}</td> <td>An event is generated when a sales order is approved in Zoho CRM.</td> </tr> <tr> <td>74</td> <td>SalesOrder Converted</td> <td>{{%badge%}}sales_order_converted{{%/badge%}}</td> <td>An event is generated when a sales order is converted in Zoho CRM.</td> </tr> <tr> <td>75</td> <td>SalesOrder Created</td> <td>{{%badge%}}sales_order_created{{%/badge%}}</td> <td>An event is generated when a sales order is created in Zoho CRM.</td> </tr> <tr> <td>76</td> <td>SalesOrder Deleted</td> <td>{{%badge%}}sales_order_deleted{{%/badge%}}</td> <td>An event is generated when a sales order is deleted in Zoho CRM.</td> </tr> <tr> <td>77</td> <td>SalesOrder Rejected</td> <td>{{%badge%}}sales_order_rejected{{%/badge%}}</td> <td>An event is generated when a sales order is rejected in Zoho CRM.</td> </tr> <tr> <td>78</td> <td>SalesOrder Updated</td> <td>{{%badge%}}sales_order_updated{{%/badge%}}</td> <td>An event is generated when a sales order is updated in Zoho CRM.</td> </tr> <tr> <td>79</td> <td>Call Created</td> <td>{{%badge%}}call_created{{%/badge%}}</td> <td>An event is generated when a call is created in Zoho CRM.</td> </tr> <tr> <td>80</td> <td>Call Deleted</td> <td>{{%badge%}}call_deleted{{%/badge%}}</td> <td>An event is generated when a call is deleted in Zoho CRM.</td> </tr> <tr> <td>81</td> <td>Call Missed</td> <td>{{%badge%}}call_missed{{%/badge%}}</td> <td>An event is generated when a call is missed in Zoho CRM.</td> </tr> <tr> <td>82</td> <td>Call Received</td> <td>{{%badge%}}call_received{{%/badge%}}</td> <td>An event is generated whenever a call is received in Zoho CRM.</td> </tr> <tr> <td>83</td> <td>Call Updated</td> <td>{{%badge%}}call_updated{{%/badge%}}</td> <td>An event is generated when a call is updated in Zoho CRM.</td> </tr> <tr> <td>84</td> <td>Email Bounced</td> <td>{{%badge%}}email_bounced{{%/badge%}}</td> <td>An event is generated when an email is bounced in Zoho CRM.</td> </tr> <tr> <td>85</td> <td>Email Clicked</td> <td>{{%badge%}}email_clicked{{%/badge%}}</td> <td>An event is generated when an email is clicked in Zoho CRM.</td> </tr> <tr> <td>86</td> <td>Email Opened</td> <td>{{%badge%}}email_opened{{%/badge%}}</td> <td>An event is generated when an email is opened in Zoho CRM.</td> </tr> <tr> <td>87</td> <td>Email Received</td> <td>{{%badge%}}email_received{{%/badge%}}</td> <td>An event is generated when an email is received in Zoho CRM.</td> </tr> <tr> <td>88</td> <td>Email Resubscribed</td> <td>{{%badge%}}email_resubscribed{{%/badge%}}</td> <td>An event is generated when an email is resubscribed in Zoho CRM.</td> </tr> <tr> <td>89</td> <td>Email Sent</td> <td>{{%badge%}}email_sent{{%/badge%}}</td> <td>An event is generated when an email is sent in Zoho CRM.</td> </tr> <tr> <td>90</td> <td>Email Unsubscribed</td> <td>{{%badge%}}email_unsubscribed{{%/badge%}}</td> <td>An event is generated when an email is unsubscribed in Zoho CRM.</td> </tr> <tr> <td>91</td> <td>OutBound Call Unattended</td> <td>{{%badge%}}outbound_call_unattended{{%/badge%}}</td> <td>An event is generated when an out bound call is unattended in Zoho CRM.</td> </tr> <tr> <td>92</td> <td>PurchaseOrder Rejected</td> <td>{{%badge%}}purchase_order_rejected{{%/badge%}}</td> <td>An event is generated when a purchase order is rejected in Zoho CRM.</td> </tr> <tr> <td>93</td> <td>Meetings Approved</td> <td>{{%badge%}}event_approved{{%/badge%}}</td> <td>An event is generated when a meeting is approved in Zoho CRM.</td> </tr> <tr> <td>94</td> <td>Meetings Created</td> <td>{{%badge%}}event_created{{%/badge%}}</td> <td>An event is generated when a meeting is created in Zoho CRM.</td> </tr> <tr> <td>95</td> <td>Meetings Deleted</td> <td>{{%badge%}}event_deleted{{%/badge%}}</td> <td>An event is generated when a meeting is deleted in Zoho CRM.</td> </tr> <tr> <td>96</td> <td>Meetings Rejected</td> <td>{{%badge%}}event_rejected{{%/badge%}}</td> <td>An event is generated when a meeting is rejected in Zoho CRM.</td> </tr> <tr> <td>97</td> <td>Meetings Updated</td> <td>{{%badge%}}event_updated{{%/badge%}}</td> <td>An event is generated when a meeting is updated in Zoho CRM.</td> </tr> <tr> <td>98</td> <td>Task Approved</td> <td>{{%badge%}}task_approved{{%/badge%}}</td> <td>An event is generated when a task is approved in Zoho CRM.</td> </tr> <tr> <td>99</td> <td>Task Created</td> <td>{{%badge%}}task_created{{%/badge%}}</td> <td>An event is generated when a task is created in Zoho CRM.</td> </tr> <tr> <td>100</td> <td>Task Deleted</td> <td>{{%badge%}}task_deleted{{%/badge%}}</td> <td>An event is generated when a task is deleted in Zoho CRM.</td> </tr> <tr> <td>101</td> <td>Task Rejected</td> <td>{{%badge%}}task_rejected{{%/badge%}}</td> <td>An event is generated when a task is rejected in Zoho CRM.</td> </tr> <tr> <td>102</td> <td>Task Updated</td> <td>{{%badge%}}task_updated{{%/badge%}}</td> <td>An event is generated when a task is updated in Zoho CRM.</td> </tr> <tr> <td>103</td> <td>Webform Submitted</td> <td>{{%badge%}}webform_submitted{{%/badge%}}</td> <td>An event is generated when a webform is updated in Zoho CRM.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Expense" description: "List of default events supported for Zoho Expense." last_updated: "2026-03-18T07:41:08.658Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-expense/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Expense Following are the default events supported for the Zoho Expense Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w35p">API Name</th> <th class="w50p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Trips Created</td> <td>{{%badge%}}trips_created{{%/badge%}}</td> <td>An event is generated when a trip is created in Zoho Expense.</td> </tr> <tr> <td>2</td> <td>Trips Deleted</td> <td>{{%badge%}}trips_deleted{{%/badge%}}</td> <td>An event is generated when a trip is deleted in Zoho Expense.</td> </tr> <tr> <td>3</td> <td>Trips Edited</td> <td>{{%badge%}}trips_edited{{%/badge%}}</td> <td>An event is generated when a trip is edited in Zoho Expense.</td> </tr> <tr> <td>4</td> <td>Trips Submitted</td> <td>{{%badge%}}trips_submitted{{%/badge%}}</td> <td>An event is generated when a trip is submitted in Zoho Expense.</td> </tr> <tr> <td>5</td> <td>Trips Approved</td> <td>{{%badge%}}trips_approved{{%/badge%}}</td> <td>An event is generated when a trip is approved in Zoho Expense.</td> </tr> <tr> <td>6</td> <td>Trips Closed</td> <td>{{%badge%}}trips_closed{{%/badge%}}</td> <td>An event is generated when a trip is closed in Zoho Expense.</td> </tr> <tr> <td>7</td> <td>Trips Recalled</td> <td>{{%badge%}}trips_recalled{{%/badge%}}</td> <td>An event is generated when a trip is recalled in Zoho Expense.</td> </tr> <tr> <td>8</td> <td>Trips Rejected</td> <td>{{%badge%}}trips_rejected{{%/badge%}}</td> <td>An event is generated when a trip is rejected in Zoho Expense.</td> </tr> <tr> <td>9</td> <td>Trips Cancelled</td> <td>{{%badge%}}trips_cancelled{{%/badge%}}</td> <td>An event is generated when a trip is cancelled in Zoho Expense.</td> </tr> <tr> <td>10</td> <td>Trips Trip Option Approved</td> <td>{{%badge%}}trips_trip_option_approved{{%/badge%}}</td> <td>An event is generated when a trip option is approved for a trip in Zoho Expense.</td> </tr> <tr> <td>11</td> <td>Trips Trip Option Selected</td> <td>{{%badge%}}trips_trip_option_selected{{%/badge%}}</td> <td>An event is generated when a trip option is selected within a trip in Zoho Expense.</td> </tr> <tr> <td>12</td> <td>Trips Trip Option_Added</td> <td>{{%badge%}}trips_trip_option_added{{%/badge%}}</td> <td>An event is generated when a trip option is added to a trip in Zoho Expense.</td> </tr> <tr> <td>13</td> <td>Trips Itinerary Rescheduled</td> <td>{{%badge%}}trips_itinerary_rescheduled{{%/badge%}}</td> <td>An event is generated when the itinerary of a trip is rescheduled in Zoho Expense.</td> </tr> <tr> <td>14</td> <td>Trips More Option Requested</td> <td>{{%badge%}}trips_more_option_requested{{%/badge%}}</td> <td>An event is generated when the more option for trips is requested in Zoho Expense.</td> </tr> <tr> <td>15</td> <td>Trips Trip Option Cancelled</td> <td>{{%badge%}}trips_trip_option_cancelled{{%/badge%}}</td> <td>An event is generated when a trip option is cancelled for a trip in Zoho Expense.</td> </tr> <tr> <td>16</td> <td>Trips Trip Option Rejected</td> <td>{{%badge%}}trips_trip_option_rejected{{%/badge%}}</td> <td>An event is generated when a trip option is rejected for a trip in Zoho Expense.</td> </tr> <tr> <td>17</td> <td>Reports Created</td> <td>{{%badge%}}reports_created{{%/badge%}}</td> <td>An event is generated when a report is created in Zoho Expense.</td> </tr> <tr> <td>18</td> <td>Reports Edited</td> <td>{{%badge%}}reports_edited{{%/badge%}}</td> <td>An event is generated when a report is edited in Zoho Expense.</td> </tr> <tr> <td>19</td> <td>Trips Itinerary Cancelled</td> <td>{{%badge%}}trips_itinerary_cancelled{{%/badge%}}</td> <td>An event is generated when the itinerary of a trip is cancelled in Zoho Expense.</td> </tr> <tr> <td>20</td> <td>Trips Rescheduled</td> <td>{{%badge%}}trips_rescheduled{{%/badge%}}</td> <td>An event is generated when a trip is rescheduled in Zoho Expense.</td> </tr> <tr> <td>21</td> <td>Reports Approved</td> <td>{{%badge%}}reports_approved{{%/badge%}}</td> <td>An event is generated when a report is approved in Zoho Expense.</td> </tr> <tr> <td>22</td> <td>Reports Deleted</td> <td>{{%badge%}}reports_deleted{{%/badge%}}</td> <td>An event is generated when a report is deleted in Zoho Expense.</td> </tr> <tr> <td>23</td> <td>Reports Submitted</td> <td>{{%badge%}}reports_submitted{{%/badge%}}</td> <td>An event is generated when a report is submitted in Zoho Expense.</td> </tr> <tr> <td>24</td> <td>Reports Recalled</td> <td>{{%badge%}}reports_recalled{{%/badge%}}</td> <td>An event is generated when a report is recalled in Zoho Expense.</td> </tr> <tr> <td>25</td> <td>Reports Reimbursed</td> <td>{{%badge%}}reports_reimbursed{{%/badge%}}</td> <td>An event is generated when a report is reimbursed in Zoho Expense.</td> </tr> <tr> <td>26</td> <td>Reports Rejected</td> <td>{{%badge%}}reports_rejected{{%/badge%}}</td> <td>An event is generated when a report is rejected in Zoho Expense.</td> </tr> <tr> <td>27</td> <td>Advances Created</td> <td>{{%badge%}}advances_created{{%/badge%}}</td> <td>An event is generated when an advance is created in Zoho Expense.</td> </tr> <tr> <td>28</td> <td>Advances Deleted</td> <td>{{%badge%}}advances_deleted{{%/badge%}}</td> <td>An event is generated when an advance is deleted in Zoho Expense.</td> </tr> <tr> <td>29</td> <td>Advances Edited</td> <td>{{%badge%}}advances_edited{{%/badge%}}</td> <td>An event is generated when an advance is edited in Zoho Expense.</td> </tr> <tr> <td>30</td> <td>Reports Reimbursement Cancelled</td> <td>{{%badge%}}reports_reimbursement_cancelled{{%/badge%}}</td> <td>An event is generated when the reimbursement for a report is cancelled in Zoho Expense.</td> </tr> <tr> <td>31</td> <td>Advance Refunds Created</td> <td>{{%badge%}}advance_refunds_created{{%/badge%}}</td> <td>An event is generated when an advance refund is created in Zoho Expense.</td> </tr> <tr> <td>32</td> <td>Advance Refunds Deleted</td> <td>{{%badge%}}advance_refunds_deleted{{%/badge%}}</td> <td>An event is generated when an advance refund is deleted in Zoho Expense.</td> </tr> <tr> <td>33</td> <td>Advance Refunds Edited</td> <td>{{%badge%}}advance_refunds_edited{{%/badge%}}</td> <td>An event is generated when an advance refund is edited in Zoho Expense.</td> </tr> <tr> <td>34</td> <td>Advances Paid</td> <td>{{%badge%}}advances_paid{{%/badge%}}</td> <td>An event is generated when an advance is paid in Zoho Expense.</td> </tr> <tr> <td>35</td> <td>Advances Rejected</td> <td>{{%badge%}}advances_rejected{{%/badge%}}</td> <td>An event is generated when an advance is approved in Zoho Expense.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Inventory" description: "List of default events supported for Zoho Inventory." last_updated: "2026-03-18T07:41:08.659Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-inventory/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Inventory Following are the default events supported for the Zoho Inventory Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w25p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Item Created</td> <td>{{%badge%}}item_created{{%/badge%}}</td> <td>An event is generated when an item is created in Zoho Inventory.</td> </tr> <tr> <td>2</td> <td>Item Updated</td> <td>{{%badge%}}item_updated{{%/badge%}}</td> <td>An event is generated when an item is updated in Zoho Inventory.</td> </tr> <tr> <td>3</td> <td>Adjustment Created</td> <td>{{%badge%}}adjustments_created{{%/badge%}}</td> <td>An event is generated when an inventory adjustment is created in Zoho Inventory.</td> </tr> <tr> <td>4</td> <td>Adjustment Deleted</td> <td>{{%badge%}}adjustments_deleted{{%/badge%}}</td> <td>An event is generated when an inventory adjustment is deleted in Zoho Inventory.</td> </tr> <tr> <td>5</td> <td>Adjustment Updated</td> <td>{{%badge%}}adjustments_updated{{%/badge%}}</td> <td>An event is generated when an inventory adjustment is updated in Zoho Inventory.</td> </tr> <tr> <td>6</td> <td>Customer Created</td> <td>{{%badge%}}customer_created{{%/badge%}}</td> <td>A event is generated when a customer is created in Zoho Inventory.</td> </tr> <tr> <td>7</td> <td>Customer Deleted</td> <td>{{%badge%}}customer_deleted{{%/badge%}}</td> <td>An event is generated when a customer is deleted in Zoho Inventory.</td> </tr> <tr> <td>8</td> <td>Customer Updated</td> <td>{{%badge%}}customer_updated{{%/badge%}}</td> <td>An event is generated when a customer is updated in Zoho Inventory.</td> </tr> <tr> <td>9</td> <td>Item Deleted</td> <td>{{%badge%}}item_deleted{{%/badge%}}</td> <td>An event is generated when an item is deleted in Zoho Inventory.</td> </tr> <tr> <td>10</td> <td>Invoice Created</td> <td>{{%badge%}}invoice_created{{%/badge%}}</td> <td>An event is generated when an invoice is created in Zoho Inventory.</td> </tr> <tr> <td>11</td> <td>Sales Order Created</td> <td>{{%badge%}}sales_order_created{{%/badge%}}</td> <td>An event is generated when a sales order is created in Zoho Inventory.</td> </tr> <tr> <td>12</td> <td>Sales Order Deleted</td> <td>{{%badge%}}sales_order_deleted{{%/badge%}}</td> <td>An event is generated when a sales order is deleted in Zoho Inventory.</td> </tr> <tr> <td>13</td> <td>Sales Order Updated</td> <td>{{%badge%}}sales_order_updated{{%/badge%}}</td> <td>An event is generated when a sales order is updated in Zoho Inventory.</td> </tr> <tr> <td>14</td> <td>Credit Note Created</td> <td>{{%badge%}}credit_note_created{{%/badge%}}</td> <td>An event is generated when a credit note is created in Zoho Inventory.</td> </tr> <tr> <td>15</td> <td>Invoice Deleted</td> <td>{{%badge%}}invoice_deleted{{%/badge%}}</td> <td>An event is generated when an invoice is deleted in Zoho Inventory.</td> </tr> <tr> <td>16</td> <td>Invoice Updated</td> <td>{{%badge%}}invoice_updated{{%/badge%}}</td> <td>An event is generated when an invoice is updated in Zoho Inventory.</td> </tr> <tr> <td>17</td> <td>Credit Note Deleted</td> <td>{{%badge%}}credit_note_deleted{{%/badge%}}</td> <td>An event is generated when a credit note is deleted in Zoho Inventory.</td> </tr> <tr> <td>18</td> <td>Credit Note Updated</td> <td>{{%badge%}}credit_note_updated{{%/badge%}}</td> <td>An event is generated when a credit note is updated in Zoho Inventory.</td> </tr> <tr> <td>19</td> <td>Delivery Challan Created</td> <td>{{%badge%}}delivery_challan_created{{%/badge%}}</td> <td>An event is generated when a delivery challan is created in Zoho Inventory.</td> </tr> <tr> <td>20</td> <td>Delivery Challan Deleted</td> <td>{{%badge%}}delivery_challan_deleted{{%/badge%}}</td> <td>An event is generated when a delivery challan is deleted in Zoho Inventory.</td> </tr> <tr> <td>21</td> <td>Delivery Challan Updated</td> <td>{{%badge%}}delivery_challan_updated{{%/badge%}}</td> <td>An event is generated when a delivery challan is updated in Zoho Inventory.</td> </tr> <tr> <td>22</td> <td>Bill Created</td> <td>{{%badge%}}bill_created{{%/badge%}}</td> <td>An event is generated when a bill is created in Zoho Inventory.</td> </tr> <tr> <td>23</td> <td>Purchase Order Created</td> <td>{{%badge%}}purchase_order_created{{%/badge%}}</td> <td>An event is generated when a purchase order is created in Zoho Inventory.</td> </tr> <tr> <td>24</td> <td>Purchase Order Deleted</td> <td>{{%badge%}}purchase_order_deleted{{%/badge%}}</td> <td>An event is generated when a purchase order is deleted in Zoho Inventory.</td> </tr> <tr> <td>25</td> <td>Purchase Order Updated</td> <td>{{%badge%}}purchase_order_updated{{%/badge%}}</td> <td>An event is generated when a purchase order is updated in Zoho Inventory.</td> </tr> <tr> <td>26</td> <td>Sales Returns Created</td> <td>{{%badge%}}sales_returns_created{{%/badge%}}</td> <td>An event is generated when a sales return is created in Zoho Inventory.</td> </tr> <tr> <td>27</td> <td>Sales Returns Deleted</td> <td>{{%badge%}}sales_returns_deleted{{%/badge%}}</td> <td>An event is generated when a sales return is deleted in Zoho Inventory.</td> </tr> <tr> <td>28</td> <td>Sales Returns Updated</td> <td>{{%badge%}}sales_returns_updated{{%/badge%}}</td> <td>An event is generated when a sales return is updated in Zoho Inventory.</td> </tr> <tr> <td>29</td> <td>Bill Deleted</td> <td>{{%badge%}}bill_deleted{{%/badge%}}</td> <td>An event is generated when a bill is deleted in Zoho Inventory.</td> </tr> <tr> <td>30</td> <td>Bill Updated</td> <td>{{%badge%}}bill_updated{{%/badge%}}</td> <td>An event is generated when a bill is updated in Zoho Inventory.</td> </tr> <tr> <td>31</td> <td>Transfer Order Created</td> <td>{{%badge%}}transfer_order_created{{%/badge%}}</td> <td>An event is generated when a transfer order is created in Zoho Inventory.</td> </tr> <tr> <td>32</td> <td>Transfer Order Updated</td> <td>{{%badge%}}transfer_order_updated{{%/badge%}}</td> <td>An event is generated when a transfer order is updated in Zoho Inventory.</td> </tr> <tr> <td>33</td> <td>Vendor Credits Created</td> <td>{{%badge%}}vendor_credits_created{{%/badge%}}</td> <td>An event is generated when a vendor credit is created in Zoho Inventory.</td> </tr> <tr> <td>34</td> <td>Vendor Credits Deleted</td> <td>{{%badge%}}vendor_credits_deleted{{%/badge%}}</td> <td>An event is generated when a vendor credit is deleted in Zoho Inventory.</td> </tr> <tr> <td>35</td> <td>Vendor Credits Updated</td> <td>{{%badge%}}vendor_credits_updated{{%/badge%}}</td> <td>An event is generated when a vendor credit is updated in Zoho Inventory.</td> </tr> <tr> <td>36</td> <td>Transfer Order Deleted</td> <td>{{%badge%}}transfer_order_deleted{{%/badge%}}</td> <td>An event is generated when a transfer order is deleted in Zoho Inventory.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Invoice" description: "List of default events supported for Zoho Invoice." last_updated: "2026-03-18T07:41:08.659Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-invoice/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Invoice Following are the default events supported for the Zoho Invoice Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w20p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Estimate Created</td> <td>{{%badge%}}estimate_created{{%/badge%}}</td> <td>An event is generated when an estimate is created in Zoho Invoice.</td> </tr> <tr> <td>2</td> <td>Estimate Updated</td> <td>{{%badge%}}estimate_updated{{%/badge%}}</td> <td>An event is generated when an estimate is updated in Zoho Invoice.</td> </tr> <tr> <td>3</td> <td>Invoice Created</td> <td>{{%badge%}}invoice_created{{%/badge%}}</td> <td>An event is generated when an invoice is created in Zoho Invoice.</td> </tr> <tr> <td>4</td> <td>Invoice Updated</td> <td>{{%badge%}}invoice_updated{{%/badge%}}</td> <td>An event is generated when an invoice is updated in Zoho Invoice.</td> </tr> <tr> <td>5</td> <td>Customer Created</td> <td>{{%badge%}}customer_created{{%/badge%}}</td> <td>An event is generated when a customer is created in Zoho Invoice.</td> </tr> <tr> <td>6</td> <td>Customer Updated</td> <td>{{%badge%}}customer_updated{{%/badge%}}</td> <td>An event is generated when a customer is updated in Zoho Invoice.</td> </tr> <tr> <td>7</td> <td>Payment Received</td> <td>{{%badge%}}payment_received{{%/badge%}}</td> <td>An event is generated when a payment is received in Zoho Invoice.</td> </tr> <tr> <td>8</td> <td>Payment Updated</td> <td>{{%badge%}}payment_updated{{%/badge%}}</td> <td>An event is generated when a payment is updated in Zoho Invoice.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Survey" description: "List of default events supported for Zoho Survey." last_updated: "2026-03-18T07:41:08.659Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-survey/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Survey Following are the default events supported for the Zoho Survey Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w20p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Response Completed</yd> <td>{{%badge%}}response_completed{{%/badge%}}</td> <td>An event is generated when a response is completed in Zoho Survey.</td> </tr> <tr> <td>2</td> <td>Response Created</yd> <td>{{%badge%}}response_created{{%/badge%}}</td> <td>An event is generated when a response is created in Zoho Survey.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Meeting" description: "List of default events supported for Zoho Meeting." last_updated: "2026-03-18T07:41:08.659Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-meeting/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Meeting Following are the default events supported for the Zoho Meeting Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w20p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Meeting Created</td> <td>{{%badge%}}meeting_created{{%/badge%}}</td> <td>An event is generated when a meeting is created in Zoho Meetings.</td> </tr> <tr> <td>2</td> <td>Meeting Canceled</td> <td>{{%badge%}}meeting_canceled{{%/badge%}}</td> <td>An event is generated when a meeting is canceled in Zoho Meetings.</td> </tr> <tr> <td>3</td> <td>Meeting Updated</td> <td>{{%badge%}}meeting_updated{{%/badge%}}</td> <td>An event is generated when a meeting is updated in Zoho Meetings.</td> </tr> <tr> <td>4</td> <td>Meeting Ended</td> <td>{{%badge%}}meeting_ended{{%/badge%}}</td> <td>An event is generated when a meeting is ended in Zoho Meetings.</td> </tr> <tr> <td>5</td> <td>Meeting Started</td> <td>{{%badge%}}meeting_started{{%/badge%}}</td> <td>An event is generated when a meeting is started in Zoho Meetings.</td> </tr> <tr> <td>6</td> <td>Webinar Created</td> <td>{{%badge%}}webinar_created{{%/badge%}}</td> <td>An event is generated when a webinar is created in Zoho Meetings.</td> </tr> <tr> <td>7</td> <td>Webinar Canceled</td> <td>{{%badge%}}webinar_canceled{{%/badge%}}</td> <td>An event is generated when a webinar is canceled in Zoho Meetings.</td> </tr> <tr> <td>8</td> <td>Webinar Updated</td> <td>{{%badge%}}webinar_updated{{%/badge%}}</td> <td>An event is generated when a webinar is updated in Zoho Meetings.</td> </tr> <tr> <td>9</td> <td>Webinar Ended</td> <td>{{%badge%}}webinar_ended{{%/badge%}}</td> <td>An event is generated when a webinar is ended in Zoho Meetings.</td> </tr> <tr> <td>10</td> <td>Webinar Started</td> <td>{{%badge%}}webinar_started{{%/badge%}}</td> <td>An event is generated when a webinar is started in Zoho Meetings.</td> </tr> <tr> <td>11</td> <td>Webinar Member Joined</td> <td>{{%badge%}}webinar_member_joined{{%/badge%}}</td> <td>An event is generated when a member joins a webinar in Zoho Meetings.</td> </tr> <tr> <td>12</td> <td>Webinar Registered</td> <td>{{%badge%}}webinar_registered{{%/badge%}}</td> <td>An event is generated when a webinar is registered in Zoho Meetings.</td> </tr> <tr> <td>13</td> <td>Webinar Member Removed</td> <td>{{%badge%}}webinar_member_removed{{%/badge%}}</td> <td>An event is generated when a member is removed from the webinar in Zoho Meetings.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Assist" description: "List of default events supported for Zoho Assist." last_updated: "2026-03-18T07:41:08.659Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-assist/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Assist Following are the default events supported for the Zoho Assist Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w20p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Outbound Session Started</td> <td>{{%badge%}}outbound_session_start{{%/badge%}}</td> <td>An event is generated when an outbound session starts in Zoho Assist.</td> </tr> <tr> <td>2</td> <td>ScreenShare Session Started</td> <td>{{%badge%}}session_start_ss{{%/badge%}}</td> <td>An event is generated when a screen-share session starts in Zoho Assist.</td> </tr> <tr> <td>3</td> <td>RemoteSupport Session Ended</td> <td>{{%badge%}}session_end_rs{{%/badge%}}</td> <td>An event is generated when a remote-support session ends in Zoho Assist.</td> </tr> <tr> <td>4</td> <td>ScreenShare Session Ended</td> <td>{{%badge%}}ssession_end_ss{{%/badge%}}</td> <td>An event is generated when a screen-share session ends in Zoho Assist.</td> </tr> <tr> <td>5</td> <td>RemoteSupport Customer Joined</td> <td>{{%badge%}}customer_join_rs{{%/badge%}}</td> <td>An event is generated when a customer joins a remote-support session in Zoho Assist.</td> </tr> <tr> <td>6</td> <td>Inbound Request Created</td> <td>{{%badge%}}inbound_request_create{{%/badge%}}</td> <td>An event is generated when an inbound request is created in Zoho Assist.</td> </tr> <tr> <td>7</td> <td>Inbound Request Transferred</td> <td>{{%badge%}}inbound_request_transfer{{%/badge%}}</td> <td>An event is generated when an inbound request is transferred in Zoho Assist.</td> </tr> <tr> <td>8</td> <td>Inbound Request Delegated</td> <td>{{%badge%}}inbound_request_delegate{{%/badge%}}</td> <td>An event is generated when an inbound request is delegated in Zoho Assist.</td> </tr> <tr> <td>9</td> <td>Inbound Request Picked</td> <td>{{%badge%}}inbound_request_picked{{%/badge%}}</td> <td>An event is generated when an inbound request is picked in Zoho Assist.</td> </tr> <tr> <td>10</td> <td>Inbound Request Declined</td> <td>{{%badge%}}inbound_request_declined{{%/badge%}}</td> <td>An event is generated when an inbound request is declined in Zoho Assist.</td> </tr> <tr> <td>11</td> <td>Inbound Request Dropped</td> <td>{{%badge%}}inbound_request_dropped{{%/badge%}}</td> <td>An event is generated when an inbound request is dropped in Zoho Assist.</td> </tr> <tr> <td>12</td> <td>Inbound Request Expired</td> <td>{{%badge%}}inbound_request_expired{{%/badge%}}</td> <td>An event is generated when an inbound request is expired in Zoho Assist.</td> </tr> <tr> <td>13</td> <td>Device Added</td> <td>{{%badge%}}device_add{{%/badge%}}</td> <td>An event is generated when a device is added in Zoho Assist.</td> </tr> <tr> <td>14</td> <td>Device Online</td> <td>{{%badge%}}device_online{{%/badge%}}</td> <td>An event is generated when a device goes online in Zoho Assist.</td> </tr> <tr> <td>15</td> <td>Device Offline</td> <td>{{%badge%}}device_offline{{%/badge%}}</td> <td>An event is generated when a device goes offline in Zoho Assist.</td> </tr> <tr> <td>16</td> <td>Device Deleted</td> <td>{{%badge%}}device_delete{{%/badge%}}</td> <td>An event is generated when a device is deleted in Zoho Assist.</td> </tr> <tr> <td>17</td> <td>Unattended Access Session Started</td> <td>{{%badge%}}session_start_urs{{%/badge%}}</td> <td>An event is generated when an unattended-access session starts in Zoho Assist.</td> </tr> <tr> <td>18</td> <td>Unattended Access Session Ended</td> <td>{{%badge%}}session_end_urs{{%/badge%}}</td> <td>An event is generated when an unattended-access session ends in Zoho Assist.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Campaigns" description: "List of default events supported for Zoho Campaigns." last_updated: "2026-03-18T07:41:08.659Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-campaigns/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Campaigns Following are the default events supported for the Zoho Campaigns Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w20p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Contact Subscribed</td> <td>{{%badge%}}contact_subscribed{{%/badge%}}</td> <td>An event is generated when a contact subscribes to Zoho Campaigns.</td> </tr> <tr> <td>2</td> <td>Contact Unsubscribed</td> <td>{{%badge%}}contact_unsubscribed{{%/badge%}}</td> <td>An event is generated when a contact unsubscribes from Zoho Campaigns.</td> </tr> <tr> <td>3</td> <td>Email Sent</td> <td>{{%badge%}}email_sent{{%/badge%}}</td> <td>An event is generated when an email is sent using Zoho Campaigns.</td> </tr> <tr> <td>4</td> <td>Email Opened</td> <td>{{%badge%}}email_opened{{%/badge%}}</td> <td>An event is generated when an email is opened in Zoho Campaigns.</td> </tr> <tr> <td>5</td> <td>Email Clicked</td> <td>{{%badge%}}email_clicked{{%/badge%}}</td> <td>An event is generated when an email is accessed in Zoho Campaigns.</td> </tr> <tr> <td>6</td> <td>Email Replied</td> <td>{{%badge%}}email_replied{{%/badge%}}</td> <td>An event is generated when an email is replied to from Zoho Campaigns.</td> </tr> <tr> <td>7</td> <td>Email Bounced</td> <td>{{%badge%}}email_bounced{{%/badge%}}</td> <td>An event is generated when an email gets bounced in Zoho Campaigns.</td> </tr> <tr> <td>8</td> <td>Subscription Preference Updated</td> <td>{{%badge%}}subscription_preference_updated{{%/badge%}}</td> <td>An event is generated when a contact updates their subscription preference in Zoho Campaigns.</td> </tr> <tr> <td>9</td> <td>Field Updated</td> <td>{{%badge%}}field_updated{{%/badge%}}</td> <td>An event is generated when a contact's field is updated in Zoho Campaigns.</td> </tr> <tr> <td>10</td> <td>List Updated</td> <td>{{%badge%}}list_updated{{%/badge%}}</td> <td>An event is generated when a list is updated in Zoho Campaigns.</td> </tr> <tr> <td>11</td> <td>Tag Updated</td> <td>{{%badge%}}tag_updated{{%/badge%}}</td> <td>An event is generated when a contact's tag is updated in Zoho Campaigns.</td> </tr> <tr> <td>12</td> <td>Score Updated</td> <td>{{%badge%}}score_updated{{%/badge%}}</td> <td>An event is generated when a contact's score is updated in Zoho Campaigns.</td> </tr> </tbody> </table> -------------------------------------------------------------------------------- title: "Zoho Marketing Automation" description: "List of default events supported for Zoho Marketing Automation." last_updated: "2026-03-18T07:41:08.659Z" source: "https://docs.catalyst.zoho.com/en/signals/help/publishers/supported-events/zoho-publishers/zoho-marketing-automation/" service: "Signals" -------------------------------------------------------------------------------- # Zoho Marketing Automation Following are the default events supported for the Zoho Marketing Automation Publisher: <table class="content-table"> <thead> <tr> <th class="w5p">No.</th> <th class="w20p">Display Name</th> <th class="w20p">API Name</th> <th class="w55p">Description</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Contact Subscribed</td> <td>{{%badge%}}contact_subscribed{{%/badge%}}</td> <td>An event is generated when a contact subscribes to Zoho Marketing Automation.</td> </tr> <tr> <td>2</td> <td>Contact Unsubscribed</td> <td>{{%badge%}}contact_unsubscribed{{%/badge%}}</td> <td>An event is generated when a contact unsubscribes from Zoho Marketing Automation.</td> </tr> <tr> <td>3</td> <td>Email Sent</td> <td>{{%badge%}}email_sent{{%/badge%}}</td> <td>An event is generated when an email is sent using Zoho Marketing Automation.</td> </tr> <tr> <td>4</td> <td>Email Opened</td> <td>{{%badge%}}email_opened{{%/badge%}}</td> <td>An event is generated when an email is opened in Zoho Marketing Automation.</td> </tr> <tr> <td>5</td> <td>Email Clicked</td> <td>{{%badge%}}email_clicked{{%/badge%}}</td> <td>An event is generated when an email is accessed in Zoho Marketing Automation.</td> </tr> <tr> <td>6</td> <td>Email Replied</td> <td>{{%badge%}}email_replied{{%/badge%}}</td> <td>An event is generated when an email is replied to from Zoho Marketing Automation.</td> </tr> <tr> <td>7</td> <td>Email Bounced</td> <td>{{%badge%}}email_bounced{{%/badge%}}</td> <td>An event is generated when an email gets bounced in Zoho Marketing Automation.</td> </tr> <tr> <td>8</td> <td>Subscription Preference Updated</td> <td>{{%badge%}}subscription_preference_updated{{%/badge%}}</td> <td>An event is generated when a contact updates their subscription preference in Zoho Marketing Automation.</td> </tr> <tr> <td>9</td> <td>Field Updated</td> <td>{{%badge%}}field_updated{{%/badge%}}</td> <td>An event is generated when a contact's field is updated in Zoho Marketing Automation.</td> </tr> <tr> <td>10</td> <td>List Updated</td> <td>{{%badge%}}list_updated{{%/badge%}}</td> <td>An event is generated when a list is updated in Zoho Marketing Automation.</td> </tr> <tr> <td>11</td> <td>Tag Updated</td> <td>{{%badge%}}tag_updated{{%/badge%}}</td> <td>An event is generated when a contact's tag is updated in Zoho Marketing Automation.</td> </tr> <tr> <td>12</td> <td>Score Updated</td> <td>{{%badge%}}score_updated{{%/badge%}}</td> <td>An event is generated when a contact's score is updated in Zoho Marketing Automation.</td> </tr> <tr> <td>13</td> <td>Stage Updated</td> <td>{{%badge%}}stage_updated{{%/badge%}}</td> <td>An event is generated when a contact's stage is updated in Zoho Marketing Automation.</td> </tr> </tbody> </table> ### Rules -------------------------------------------------------------------------------- title: "Key Aspects" description: "Rules help you ingest the events from publisher to various targets. Learn more about cutomizing and filtering the events depending upon the target." last_updated: "2026-03-18T07:41:08.660Z" source: "https://docs.catalyst.zoho.com/en/signals/help/rules/key-aspects/" service: "Signals" -------------------------------------------------------------------------------- # Rules Rule is a statement that guides the ingestion of incoming {{%link href="/en/signals/help/events/"%}}events{{%/link%}} from {{%link href="/en/signals/help/publishers/key-aspects/"%}}Publisher{{%/link%}} to {{%link href="/en/signals/help/targets/key-aspects/"%}}Target{{%/link%}}. It prescribes the actions which should be taken when certain conditions are met for delivering the events. You can tailor the rule configurations, update matching criteria, and modify target actions as required to accommodate changing business needs. Following are a couple of examples of rules: - In a **Travel Bureau**, whenever a trip is booked through their online platform, the event should be delivered to multiple target services, such as reservation management, customer service and support, and personalized recommendations. To achieve this, you can create a rule with no condition and multiple targets. - In a **marketing software** managing several campaigns and trade shows for a product with various features, each feature department needs to be notified of customer interactions regularly. To achieve this, you can create a rule with a condition to match a feature. The rule can then direct the events to the specific feature department through webhook. {{%note%}}{{%bold%}}Note:{{%/bold%}} You can create and configure up to {{%bold%}}100 Rules{{%/bold%}}. This threshold is configured for baseline and standard scenarios only. We strongly urge you to email us at {{%link href="mailto:support@zohocatalyst.com" %}}support@zohocatalyst.com{{%/link%}} with your requirement to increase this soft threshold.{{%/note%}} ## Key Aspects ### Event Sources Event source refers to the publisher from where the configured event will be dispatched to Signals. Each Rule connects an event from a Publisher to one or more Targets. A single Rule can serve **up to five Targets**, allowing diverse services to react to the same event. {{%link href="/en/signals/help/publishers/create-publisher/zoho-publishers/"%}}Learn how to create a publisher{{%/link%}} ### Filter Rules deploy filters to find out the necessary events that need to be delivered to the target. These filters are based on {{%link href="/en/signals/help/events/#event-schema"%}}event schema{{%/link%}} such as publisher, event details, or specific values within the event payload. This filtering capabilities of Signals assist you in precisely discovering the required events for triggering downstream processes in the target. {{%note%}}{{%bold%}}Note:{{%/bold%}} You can configure up to {{%bold%}}25 Filter{{%/bold%}} conditions per Rule. This threshold is configured for baseline and standard scenarios only. We strongly urge you to email us at {{%link href="mailto:support@zohocatalyst.com" %}}support@zohocatalyst.com{{%/link%}} with your requirement to increase this soft threshold.{{%/note%}} ### Target Input Targets process the incoming events according to a few actions that involve data extraction and transformation of the event schema. They also implement a dispatch policy that determines whether events have to be delivered instantly or should meet any condition to be delivered as a batch. These events further trigger a downstream process through different consumer types. Refer to {{%link href="/en/signals/help/targets/key-aspects/"%}}Target types and Target Input{{%/link%}}. ### Multiple Target Association Rules in Signals support multiple targets, allowing users to define multiple actions to be taken when any event matches the rule. This enables you to manage complex event routing and orchestration scenarios, where events may need to trigger multiple downstream processes in one or many targets. ### App Alerts Integration {{%link href="/en/devops/help/application-alerts/introduction/"%}}Application Alerts{{%/link%}} in the Catalyst ecosystem is supported within Catalyst Signals to help you stay informed about event delivery failures. When enabled, Application Alerts automatically sends email notifications whenever an event fails to reach its target. It is an optional support ensures you are alerted in real time, enabling faster resolution without the need for constant monitoring. You can configure Application Alerts under Catalyst DevOps service to define and manage alert settings. Learn more about {{%link href="/en/devops/help/application-alerts/implementation/"%}}setting up Application Alerts{{%/link%}}. -------------------------------------------------------------------------------- title: "Creating a Rule" description: "Rules help you ingest the events from publisher to various targets. Learn more about cutomizing and filtering the events depending upon the target." last_updated: "2026-03-18T07:41:08.660Z" source: "https://docs.catalyst.zoho.com/en/signals/help/rules/create-rule/" service: "Signals" -------------------------------------------------------------------------------- # Creating a Rule You need to configure the publisher, its events, and target types beforehand to use them within the rule. {{%link href="/en/signals/help/webhooks/key-aspects/"%}}Webhooks{{%/link%}} can be configured within the Signals service; {{%link href="/en/serverless/help/functions/event-functions/"%}}functions{{%/link%}} and {{%link href="/en/serverless/help/circuits/implementation/"%}}circuits{{%/link%}} can be created in the Catalyst Serverless platform. ### I. Configuring the Event Source 1. Navigate to the **Rules** section and click the **Add Rule** button. 2. Provide a Name and Description for the rule in the title bar, as shown in this image. 3. Click on **Choose Events**. This will open a pop-up displaying the configured publishers from {{%link href="/en/signals/help/publishers/create-publisher/zoho-publishers/"%}}Zoho{{%/link%}}, {{%link href="/en/signals/help/publishers/create-publisher/catalyst-publishers/"%}}Catalyst{{%/link%}}, {{%link href="/en/signals/help/publishers/create-publisher/saas-publishers/"%}}SAAS{{%/link%}}, and {{%link href="/en/signals/help/publishers/create-publisher/custom-publishers/"%}}Custom{{%/link%}} publishers. Select a publisher and choose an event from it. ### II. Setting up the Filter 1. Select the edit icon of the filter to determine which events you want to be sent to the target. You can choose to deliver all events or create conditions to filter and only share the required events with the target. 2. Select the **Events matching certain conditions** option and provide the condition. The **Path** key in the filter lists all the properties of that particular event in payload. The following **comparators** are supported for creating a filter in the rule: <table class="content-table"> <thead> <tr> <th class="w30p">Data Type</th> <th class="w70p">Supported Comparators</th> </tr> </thead> <tbody> <tr> <td>{{%badge%}}String{{%/badge%}}</td> <td>is, isn't, contains, doesn\'t contain, starts with, ends with, is empty, is not empty</td> </tr> <tr> <td>{{%badge%}}Integer, Number{{%/badge%}}</td> <td>= (equals), != (not equals), < (less than), <= (lesser than or equals), > (greater than), >= (greater than or equals), between, not between, is empty, is not empty</td> </tr> <tr> <td>{{%badge%}}Boolean{{%/badge%}}</td> <td>is, isn't</td> </tr> <tr> <td>{{%badge%}}DateTime, Date{{%/badge%}}</td> <td>is, isn't, is before, is after, between, not between, is empty, is not empty, Today, Tomorrow, Tomorrow Onwards, Yesterday, Till Yesterday, Last Month, Current Month, Next Month, Last Week, Current Week, Next Week</td> </tr> </tbody> </table> ### III. Configuring Target Input 1. Click the **Choose Target** button. 2. In the pop-up window, provide the Target Name and choose your Consumer Type. 3. Upon selecting the preferred consumer type, you need to choose the respective {{%link href="/en/signals/help/webhooks/key-aspects/"%}}webhook{{%/link%}} / {{%link href="/en/serverless/help/functions/event-functions/"%}}function{{%/link%}} / {{%link href="/en/serverless/help/circuits/implementation/"%}}circuit{{%/link%}} for the rule. {{%note%}}{{%bold%}}Note:{{%/bold%}} You can configure up to {{%bold%}}25 Filter{{%/bold%}} conditions per Rule. This threshold is configured for baseline and standard scenarios only. We strongly urge you to email us at {{%link href="mailto:support@zohocatalyst.com" %}}support@zohocatalyst.com{{%/link%}} with your requirement to increase this soft threshold.{{%/note%}} #### Placeholders If you have chosen a webhook with dynamic values in headers or parameters, a new field called **Placeholders** will appear, as shown in the image. - Specify the values for the keys configured in the webhooks page for headers/parameters. - You can either provide static values or dynamic values using JSON path of the {{%link href="/en/signals/help/events/#event-schema"%}}event schema{{%/link%}}. Use JSON path to denote the key whose values you want to use. 4. Choose the preferred mode of event delivery to your target. {{%link href="/en/signals/help/targets/dispatch-policy/"%}}Learn more about dispatch policies{{%/link%}} 5. Provide the number of retry attempts that should take place when any event fails to reach the target. You can also set the frequency of retries based on your needs. Check {{%link href="/en/signals/help/targets/key-aspects/#retry-policy"%}}this{{%/link%}} help page to know more about the frequency of retry attempts. 6. In the **Target Input**, you can either deliver the complete event schema to the target or perform extraction and transformation based on your business requirements before delivering it to the target. #### Extraction - Select the **Extraction** option under **Target Input**. - The **Path** field will list you all the keys in terms of JSON path from the particular event schema. You can only select and extract a single key from the event schema. #### Transformation {{%link href="/en/signals/help/targets/event-body-setup/event-transformation/"%}}Learn how to transform your schema{{%/link%}} - Select the **Transformation** option under **Target Input**. A three-pane transformer will appear with a sample event payload on your left. - In the center pane, build a JSON body with the custom keys that you would require for your target. - In place of providing values to the keys, you can match the values from the default event payload. Refer to the sample event payload on the left and provide the JSON path of the key whose value you would want for the keys in the compiler. - Click the **Generate Output** button in the right pane. This will provide the transformed payload with the custom keys mapped to the data from the default payload. Signlas will use the generated output as the new payload for the particular target in this rule. Once you have completed your transformation, click the **Confirm** button. {{%link href="/en/signals/help/targets/event-body-setup/event-transformation/"%}}Learn more about event transformation and its guidelines{{%/link%}} 7. Similarly, you can add a maximum of **five targets** to a rule. After adding the targets, click the **Save** button in the top-right corner. {{%note%}}{{%bold%}}Note:{{%/bold%}} You can create and configure up to {{%bold%}}100 Rules{{%/bold%}}. This threshold is configured for baseline and standard scenarios only. We strongly urge you to email us at {{%link href="mailto:support@zohocatalyst.com" %}}support@zohocatalyst.com{{%/link%}} with your requirement to increase this soft threshold.{{%/note%}} ### IV. Configuring App Alert 1. After creating the rule, navigate to its detail page and click the **Configure Alert** button located at the top-right corner. 2. You will be redirected to the Application Alerts section under the Catalyst DevOps service to complete the configuration. For detailed instructions, refer to the {{%link href="/en/devops/help/application-alerts/implementation/"%}}Application Alerts{{%/link%}} help page. ### Targets -------------------------------------------------------------------------------- title: "Key Aspects" description: "Targets are any endpoint that serves as a destination for events generated and emitted from publishers." last_updated: "2026-03-18T07:41:08.661Z" source: "https://docs.catalyst.zoho.com/en/signals/help/targets/key-aspects/" service: "Signals" -------------------------------------------------------------------------------- # Targets A target is usually an endpoint that serves as a destination for the events generated by a {{%link href="/en/signals/help/publishers/key-aspects/"%}}publisher{{%/link%}}. 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. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} You can associate a maximum of {{%bold%}}five{{%/bold%}} targets to a {{%link href="/en/signals/help/rules/key-aspects/"%}}rule{{%/link%}}.{{%/note%}} ## Key Aspects Targets are responsible for processing the incoming events according to predefined {{%link href="/en/signals/help/rules/key-aspects/"%}}rules{{%/link%}} 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: - {{%link href="/en/signals/help/webhooks/key-aspects/"%}}Webhooks{{%/link%}} are HTTP callbacks that help you to share real-time data between applications. They are commonly used for event-driven integration between systems. - {{%link href="/en/serverless/help/functions/event-functions/"%}}Functions{{%/link%}} 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. - {{%link href="/en/serverless/help/circuits/implementation/"%}}Circuits{{%/link%}} 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 {{%link href="/en/getting-started/catalyst-projects/"%}}Catalyst Project{{%/link%}} 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: <table class="content-table"> <thead> <tr> <th class="w30p">Target Type</th> <th class="w30p">Queue Dispatch</th> <th class="w30p">Batch Dispatch</th> </tr> </thead> <tbody> <tr> <td>{{%badge%}}Webhooks{{%/badge%}}</td> <td>5 seconds</td> <td>15 seconds</td> </tr> <tr> <td>{{%badge%}}Circuits{{%/badge%}}</td> <td>5 seconds</td> <td>15 seconds </td> </tr> <tr> <td>{{%badge%}}Functions{{%/badge%}}</td> <td>15 minutes</td> <td>15 minutes</td> </tr> </tbody> </table> ### 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 {{%link href="/en/signals/help/targets/dispatch-policy/"%}}Types in the Dispatch policy{{%/link%}}. ### 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**. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} The retry policy will be carried out within the configured {{%bold%}}Time To Live{{%/bold%}} period of the specific event. If the retry count exceeds that period, it will be {{%link href="/en/signals/help/events/#event-statuses"%}}dropped{{%/link%}}. {{%/note%}} ### 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 {{%link href="/en/signals/help/events/#event-schema"%}}event schema{{%/link%}}. ### Event Transformation {{%link href="/en/signals/help/events/#event-schema"%}}Event Schemas{{%/link%}} 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. {{%link href="/en/signals/help/targets/event-body-setup/event-transformation/"%}}Step-by-step guide to extract and transform an event schema{{%/link%}} -------------------------------------------------------------------------------- title: "Dispatch Policy" description: "Dispatch policy helps you to decide whether to deliver the events individually or as a batch to the targets." last_updated: "2026-03-18T07:41:08.661Z" source: "https://docs.catalyst.zoho.com/en/signals/help/targets/dispatch-policy/" service: "Signals" -------------------------------------------------------------------------------- # Dispatch Policy The dispatch policy in Signals determines how the events are delivered to the target systems after the publisher has emitted them. It provides options to handle them either individually or collectively that cater to a multitude of use cases and preferences. You can configure this policy based on your requirements, ensuring efficient and timely processing of events within the system. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} The maximum size of the events delivered to the target system at once is {{%bold%}}1024 KB{{%/bold%}} (1 MB). {{%/note%}} ### Instant In this policy, events are delivered to the target immediately after they occur in the publisher application. This enables continuous monitoring of publisher activities and performance metrics. It results in triggering instant actions such as processing payments, updating inventories, and can also help in preventing potential security breaches. By default, Signals retains events for up to 24 hours between the publisher and target. This **Time to Live** (TTL) period can be customized in hours or minutes to suit your workflow needs. In some scenarios, events may be received in bulk. By default, these are instantly delivered as a batch. If you prefer to deliver each event individually, you can enable the **Send as Single Event** option under the Instant ploicy. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} You can configure the Time To Live (TTL) period for {{%bold%}}up to 24 hours or 1440 minutes{{%/bold%}}. {{%/note%}} ### Batch This type helps in the collective delivery of events to the target systems. It enables you to gain insights from overall events, particularly in scenarios such as campaign responses and log management to trigger downstream workflows accordingly. The **Time To Live (TTL)** period for each event within Signals is **24 hours by default** and cannot be changed. Signals offer four dispatch types to define the event collection that must be delivered to the target. Following are the available dispatch types: - **By Count** - The Signals wait until the configured events count is reached before delivering them to the targets as a batch. Following are a couple of exceptional cases in this type: - If the events reach the maximum size of 1MB before reaching the configured count, Signals collect the remaining events in a new batch and deliver them to the targets as multiple batches. - If the configured count is not reached within the TTL period, the events will be delivered to the target systems based on the [One-Time Dispatch policy](/en/signals/help/targets/dispatch-policy/#one-time-dispatch). {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} The minimum event count is {{%bold%}}two{{%/bold%}}, and the maximum event count that you can configure is {{%bold%}}100{{%/bold%}}.{{%/note%}} - **By Size** - In this type, events are delivered when their combined size matches the configured size. If the configured size is not reached within the TTL period, then the events are delivered to the targets based on the One-Time Dispatch policy. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} The maximum event size that you can configure is {{%bold%}}100 KB{{%/bold%}}.{{%/note%}} - **By Interval** - Events are delivered in regular intervals to the target. If events reach the maximum size of 1mb before the interval time, they are dispatched in multiple batches at the configured interval. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} The interval can be configured from a {{%bold%}}minimum of two hours{{%/bold%}} to a {{%bold%}}maximum of 12 hours{{%/bold%}}.{{%/note%}} - **By Schedule** - Events are delivered daily at the configured time, and it can be even customized to your timezone. If events reach the maximum size of 1MB before the scheduled time, they are dispatched in multiple batches at the configured scheduled time. ### One-Time Dispatch The One-Time Dispatch policy of Signals helps in preventing data loss in specific scenarios. The retry counts configured for the {{%link href="/en/signals/help/targets/key-aspects/"%}}Target{{%/link%}} will not be applicable, and failed events cannot be retrieved again. It occurs at the following two different instances: - **Before Clean-Up** - It takes place at the end of everyday to clear the data of failed events. Before cleaning-up, Signals checks for any batch events that have not met the dispatch conditions within 24 hours. If any are found, they are delivered to the target. - **Instant** - If any changes have been made to the dispatch types of an existing {{%link href="/en/signals/help/rules/key-aspects/"%}}rule{{%/link%}}, events accumulated within Signals according to the previous dispatch type are instantly delivered to the target systems. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} If a {{%link href="/en/signals/help/targets/key-aspects/"%}}target{{%/link%}} or {{%link href="/en/signals/help/rules/key-aspects/"%}}rule{{%/link%}} for an event is {{%bold%}}deleted/disabled{{%/bold%}}, the event status is logged as '{{%bold%}}Failed{{%/bold%}}'.{{%/note%}} #### Event Body Setup -------------------------------------------------------------------------------- title: "Event Transformation" description: "Customize the event body before delivering it to the targets for operational efficiency." last_updated: "2026-03-18T07:41:08.661Z" source: "https://docs.catalyst.zoho.com/en/signals/help/targets/event-body-setup/event-transformation/" service: "Signals" -------------------------------------------------------------------------------- # Event Transformation You can tailor the event schema for each target system. This allows you to build complex orchestration flows with different schemas for the same event across diverse targets. Signals simplifies the process without coding by using JSON path and mapping logic for schema transformation. ### Extraction This approach allows extracting a single key from the schema and forwarding only that specific key to the designated target. #### How to extract data? 1. Create a rule following the instructions in {{%link href="/en/signals/help/rules/create-rule/"%}}this{{%/link%}} document. 2. While configuring *Target Input*, select **Extraction** under *Target Input*. 3. Click the box for **Path** to view all keys in the event schema. Choose the required key and save the rule. ### Transformation Data transformation relies on a mapping concept utilizing JSON path. #### How to transform data? 1. Create a rule following the instructions in {{%link href="/en/signals/help/rules/create-rule/"%}}this{{%/link%}} document. 2. While configuring *Target Input*, select **Transformation** under *Target Input*. 3. In the new template, provide the key name and in place of its value specify the JSON path of the desired key from the sample event schema. 4. Employ the **for-each method** to create an array in your template. This will help you to access specific objects/keys from any array in the sample schema. Deploy this syntax **forEach((var{n})->{JSON_path_of_desired_key} )** next to the key that you want to be an array. In the syntax, **var{n}** designates the variable name of the array and the specific index in the array. In the place of **JSON_path** in the syntax, you can also employ a new key or a JSON object, which may or may not carry a for-each method within it. To map a key value within the syntax, specify the **var{n}** (variable) that you have set in the argument and navigate to your desired key. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} Catalyst Signals provides {{%bold%}}suggestions of JSON paths{{%/bold%}} in the template compiler pane based on the provided sample event schema. This eases the task of searching for keys and their order from the sample schema.{{%/note%}} -------------------------------------------------------------------------------- title: "Samples" description: "A few samples of customizing the event body before delivering it to the targets for operational efficiency." last_updated: "2026-03-18T07:41:08.662Z" source: "https://docs.catalyst.zoho.com/en/signals/help/targets/event-body-setup/samples/" service: "Signals" -------------------------------------------------------------------------------- # Examples Following is the sample event payload of the **Leads Created** event from the **Zoho CRM** service in Catalyst Signals. ### Sample Event Payload {{%panel_with_adjustment class="language-json line-numbers" header="Sample Event Payload" footer="button" scroll="set-scroll" %}}{ "rule_id": "123456789", "target_id": "98765432", "version": 1, "attempt": 1, "account": { "org_id": "85512289", "project": { "environment": "DEVELOPMENT", "name": "crm", "id": "10666000000021013" } }, "events": [ { "data": { "Owner": { "name": "Owner name", "id": "9876543210", "zuid": "654321" }, "Company": "Company", "Email": "test@zoho.com", "Lead_Status_Prediction": "value of picklist", "Last_Activity_Time": "2024-01-01T12:00:00+00:00", "Industry": "value of picklist", "Unsubscribed_Mode": "value of picklist", "Street": "Street", "Zip_Code": "Zip Code", "id": 9876543210, "Data_Source": "value of picklist", "Enrich_Status__s": "value of picklist", "Created_Time": "2024-01-01T12:00:00+00:00", "Change_Log_Time__s": "2024-01-01T12:00:00+00:00", "City": "City", "No_of_Employees": 1, "Data_Processing_Basis": "value of picklist", "Converted__s": true, "Converted_Date_Time": "2024-01-01T12:00:00+00:00", "Converted_Account": { "name": "lookup name", "id": "9876543210" }, "State": "State", "Country": "Country", "Created_By": { "name": "Owner name", "id": "9876543210", "zuid": "654321" }, "Annual_Revenue": 100, "Secondary_Email": "test@zoho.com", "Description": "Description", "Rating": "value of picklist", "Website": "https://catalyst.zoho.com", "Twitter": "Twitter", "Salutation": "value of picklist", "First_Name": "First Name", "Full_Name": "Full Name", "Lead_Status": "value of picklist", "Modified_By": { "name": "Owner name", "id": "9876543210" }, "Lead_Conversion_Time": 1, "Skype_ID": "Skype ID", "Phone": 9876543210, "Email_Opt_Out": true, "Designation": "Designation", "Modified_Time": "2024-01-01T12:00:00+00:00", "Lead_Status_Prediction_Score": 1, "Unsubscribed_Time": "2024-01-01T12:00:00+00:00", "Converted_Contact": { "name": "lookup name", "id": "9876543210" }, "Mobile": 9876543210, "Last_Name": "Last Name", "Locked__s": true, "Lead_Source": "value of picklist", "Tag": "Tag", "Fax": "Fax", "Last_Enriched_Time__s": "2024-01-01T12:00:00+00:00" }, "id": "c6b53699-94b1-48a1-86fd-80b8d4778e28", "time_in_ms": 1718780819204, "source": "publisher_id:10666000000021074/service:zohocrm/account:73756307", "event_config": { "api_name": "Leads Created", "id": "10666000000021075" } } ] } {{%/panel_with_adjustment%}} With the help of this sample event payload, let us walk you through two mostly used transformation patterns for your targets. ### Scenario 1: Simple Transformation Let's perform a basic transformation of adding a new key-value pair and modifying the existing ones for only a particular indexed object in an array. #### New Payload Requirements - To retain the existing keys like Event ID, Lead ID, and Email. - To add this **"is_transformed": true** new key-value pair. - To retain the Lead's full name in a different key called **Name**. #### Expected Event Payload {{%panel_with_adjustment class="language-json line-numbers" header="Expected Event Payload" footer="button" scroll="set-scroll" %}}{ "id" : 9876543210, "name" : "Full Name", "email" : "test@zoho.com", "event_id" : "c6b53699-94b1-48a1-86fd-80b8d4778e28", "is_transformed" : true } {{%/panel_with_adjustment%}} 1. Open a JSON object and add the "**id**" key, providing the JSON path of the corresponding key in the sample event payload instead of value. Repeat this step for the "**email**" and "**event_id**" key. 2. For the "**name**" key, provide the JSON path of the Full_Name key in the sample event payload. Finally, add this **"is_transformed": true** static key-value pair to denote that this payload is transformed to suit the orchestration configured for the particular event. You can also copy and paste the below template compiler for the Lead Created event in Zoho CRM service to witness the instant transformation of your payloads. {{%panel_with_adjustment class="language-json line-numbers" header="Template Compiler" footer="button" scroll="set-scroll" %}}{ "id" : $.events[0].data.id, "name" : $.events[0].data.Full_Name, "email" : $.events[0].data.Email, "event_id" : $.events[0].id, "is_transformed" : true } {{%/panel_with_adjustment%}} {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} This applies only to the first indexed JSON object in the events array.{{%/note%}} <br /> <hr /> ### Scenario 2: Complex Transformation For the same requirements that we have seen in the above scenario, we need to apply the transformation to each and every JSON object within the **events** array instead of a particular indexed object. #### New Payload Requirements - To have an array of JSON objects called **data**. - Each JSON object in the array should carry the id, name, email, event_id keys as transformed in the previous scenario. - To add this **"is_transformed": true** new key-value pair. #### Expected Event Payload {{%panel_with_adjustment class="language-json line-numbers" header="Expected Event Payload" footer="button" scroll="set-scroll" %}}{ "data" : [ { "id" : 9876543210, "name" : "Full Name", "email" : "test@zoho.com", "event_id" : "c6b53699-94b1-48a1-86fd-80b8d4778e28" } ], "is_transformed" : true } {{%/panel_with_adjustment%}} 1. To create an array, begin by opening a JSON object with the **data** key. Provide the JSON path of the **events** array from the sample payload and deploy this **forEach((var{n})->{JSON_path_of_desired_key} )** syntax instead of values. Replace var with the a variable name. 2. Enter the name of the keys (id, name, email, event_id) that you want to include within an object of this array. Instead of values, provide the JSON path of the corresponding keys from the particular array without the **$** symbol. This will iterate through each object starting from index 0 and generate an array of objects containing lead names, IDs, and Emails. 3. Add this **"is_transformed": true** static key-value pair to denote that this payload is transformed to suit the orchestration configured for the particular event. You can either practice this transformation step-by-step, or copy and paste the below template compiler for the Lead Created event in Zoho CRM service to witness the instant transformation of your payloads. {{%panel_with_adjustment class="language-json line-numbers" header="Template Compiler" footer="button" scroll="set-scroll" %}}{ "data" : $.events.forEach((array) -> { "id" : array.data.id, "name" : array.data.Full_Name, "email" : array.data.Email, "event_id" : array.id } ), "is_transformed" : true } {{%/panel_with_adjustment%}} ### Webhooks -------------------------------------------------------------------------------- title: "Key Aspects" description: "An HTTP-based callback function that allows event-driven communication between decoupled apps." last_updated: "2026-03-18T07:41:08.663Z" source: "https://docs.catalyst.zoho.com/en/signals/help/webhooks/key-aspects/" service: "Signals" -------------------------------------------------------------------------------- # Webhooks Webhooks serves seamless sharing of real-time communication and data exchange between applications. These Hypertext Transfer Protocol Secure (HTTPS) callbacks allow near-instantaneous interaction between the different applications. With webhooks, Signals help you to automatically trigger actions in the {{%link href="/en/signals/help/targets/key-aspects/"%}}target{{%/link%}} systems based on predefined events that occur in the {{%link href="/en/signals/help/publishers/key-aspects/"%}}publisher{{%/link%}} environment. This eliminates the need for manual intervention and allows systems to react dynamically to the changes. {{%note%}}{{%bold class="bold-primary"%}}Note:{{%/bold%}} You can create up to {{%bold%}}100{{%/bold%}} webhooks in a {{%link href="/en/getting-started/catalyst-projects/"%}}Catalyst Project{{%/link%}}.{{%/note%}} ## Key Aspects ### Authorization Connections provided under Catalyst Cloud Scale simplifies the authorization setup for webhooks. This helps developers to securely authenticate webhook requests without managing external credentials manually. ### Track Webhook Performance Each webhook has a dedicated **Activity** page that provides insights into its execution trends and performance. It displays the number of successful and failed executions over time. This feature helps developers monitor webhook reliability and troubleshoot issues efficiently through **Execution History**. It captures details like response JSON and status codes, making it easier to analyze failures, identify patterns, and optimize webhook performance. ### Supported HTTPS Methods Catalyst Signals supports multiple HTTPS methods for webhooks. It includes **POST**, **GET**, **PUT**, **PATCH**, **DELETE**, and **OPTIONS**. This flexibility enhances the management of event data, leading to robust and efficient event deliveries to the target applications. ### Invocation Rate Limit The invocation rate limit controls how frequently a webhook can be triggered per second. This limit helps in preventing excessive use of endpoints that may overload the target systems. You can configure this limit between 1 and 300 HTTPS calls per second, with **300 per second** as the default. ### Customizable Headers and Parameters Webhooks support customizable headers and parameters, which can be either static values or dynamic placeholders wrapped in double curly braces (***{{variable}}***). Once specified, you must configure them on the {{%link href="/en/signals/help/targets/key-aspects/"%}}target{{%/link%}} page under Placeholders. Each webhook supports up to **25 unique headers and parameters**, allowing precise control over transmitted data. {{%link href="/en/signals/help/webhooks/create-webhook/#https-call-settings"%}}Learn how to configure Headers and Parameters for Webhook{{%/link%}} -------------------------------------------------------------------------------- title: "Creating a Webhook" description: "An HTTP-based callback function that allows event-driven communication between decoupled apps." last_updated: "2026-03-18T07:41:08.663Z" source: "https://docs.catalyst.zoho.com/en/signals/help/webhooks/create-webhook/" service: "Signals" -------------------------------------------------------------------------------- # Creating a Webhook 1. Navigate to the webhooks section and click **Create Webhook**. 2. Provide the necessary details as shown in the following image and click **Save**. Select the required HTTPS method and provide the Endpoint URL based on your requirement. {{%link href="/en/signals/help/webhooks/key-aspects/#various-https-methods"%}}Learn more about HTTPS methods{{%/link%}} ### Headers & Parameters Settings 3. To include custom headers or parameters in the HTTPS call, enter the required key and its corresponding value. If you're using placeholder values, you'll be able to assign actual values when associating the webhook with a target. You can provide: - **Static values**: They remain fixed and can be directly assigned without any special format. - **Dynamic values**: Use the format ***{{event_data_key_name}}*** to reference values from the event payload. This allows you to pass data dynamically from each event. - **Placeholder-based static values**: Use the format ***{{static_value}}*** to represent static values that are assigned during rule configuration. This enables you to use the same webhook across multiple {{%link href="/en/signals/help/targets/key-aspects/"%}}targets{{%/link%}}, while assigning a different static value to each target’s header or parameter. {{%note%}} {{%bold class="bold-primary"%}}Note:{{%/bold%}} The Placeholder-based static values is especially useful when the underlying webhook configuration remains the same, but the contextual values vary by {{%link href="/en/signals/help/targets/key-aspects/"%}}targets{{%/link%}}. {{%/note%}} 4. After setting up the headers/parameters, navigate to the {{%link href="/en/signals/help/rules/key-aspects/"%}}Rule{{%/link%}} where you want to use this webhook. In the Targets section of the rule, select the webhook you just created. 5. Once the webhook is selected, a new section called **Placeholders** will appear. This is where you can assign actual values for any placeholders you used in the header or parameter configuration. For variable values, provide the JSON path of the key whose value you want tp use for for the key. ### Authorize via Connection 6. Select the 'Authorize via Connection' option and view all the connections created for the current project under the Catalyst Cloud Scale service. To create a new connection for the webhook, click the **Create New** option at the end of the list. You can refer to the step-by-step guide on Connections to help you through the process. ### Throttling Settings 7. In the webhook **Additional Settings**, you can set the dispatch rate limit per second for the webhook call. This will limit the excessive use of endpoints that may overload the target systems. {{%note%}} {{%bold class="bold-primary"%}}Note:{{%/bold%}}{{%list%}}* You can only make {{%bold%}}HTTPS{{%/bold%}} calls using this webhook.{{%/list%}} {{%list%}}* You can configure a maximum dispatch rate limit of {{%bold%}}up to 300 HTTPS calls per second{{%/bold%}}.{{%/list%}} {{%/note%}} --- ## FAQ — Signals # Signals ### Publishers {{%expand-container%}} {{%expand id="event_schema" header="Do I need to create an event schema for all events in the publisher?"%}} No, this is not necessary. Zoho in Signals come with {{%link href="/en/signals/help/publishers/supported-events/zoho-publishers/zoho-bigin/"%}}predefined events{{%/link%}} and their schemas. Even for custom events, you can easily capture the event payload using the {{%link href="/en/signals/help/publishers/create-publisher/custom-publishers/#live"%}}Live Events{{%/link%}} support and generate the schema within seconds. {{%/expand%}} {{%/expand-container%}} {{%expand-container%}} {{%expand id="zoho_event_size" header="What's the maximum size of a Zoho event that Signals can process?"%}} The maximum size for a {{%link href="/en/signals/help/publishers/create-publisher/zoho-publishers/"%}}Zoho publisher{{%/link%}}'s event processed in Signals is **100 KB**, with an array of limitless Zoho events allowed up to **5 MB**. {{%/expand%}} {{%/expand-container%}} ### Webhooks {{%expand-container%}} {{%expand id="webhook_headers_params" header="Can I customize webhook headers and parameters using event schema properties?"%}} Yes, you can customize headers and parameters with static or variable values from event payloads using JSON path. {{%/expand%}} {{%/expand-container%}} {{%expand-container%}} {{%expand id="protocol_and_methods" header="What protocol and methods does Signals support for webhooks?"%}} Signals support the **HTTPS** protocol and methods like **POST**, **GET**, **PUT**, **PATCH**, **DELETE**, and **OPTION** for {{%link href="/en/signals/help/webhooks/key-aspects/"%}}webhooks{{%/link%}}. {{%/expand%}} {{%/expand-container%}} ### Rules {{%expand-container%}} {{%expand id="event_in_rule" header="How many events can I add to a rule?"%}} You can add only one event to a rule in Signals. However, you can customize the same {{%link href="/en/signals/help/events/"%}}event{{%/link%}} for each {{%link href="/en/signals/help/targets/key-aspects/"%}}target{{%/link%}} within the {{%link href="/en/signals/help/rules/key-aspects/"%}}rule{{%/link%}}. {{%/expand%}} {{%/expand-container%}} {{%expand-container%}} {{%expand id="multiple_targets" header="Can I add multiple targets to a rule, and what's the maximum limit?"%}} Yes, you can add multiple {{%link href="/en/signals/help/targets/key-aspects/"%}}targets{{%/link%}} to a {{%link href="/en/signals/help/rules/key-aspects/"%}}rule{{%/link%}}. The maximum number of targets allowed per rule is **five**. {{%/expand%}} {{%/expand-container%}} ### Dashboard {{%expand-container%}} {{%expand id="success_failure_percentage" header="What does the percentage near the Success and Failed status indicate in the Event Statistics element?"%}} They are called the Key performance Indicator (KPI) metrics reflecting the proportion of events in each status compared to the selected time interval on the top-right corner, providing a snapshot of recent performance. {{%/expand%}} {{%/expand-container%}} ### Logs {{%expand-container%}} {{%expand id="event_across_rules_and_targets" header="Besides individual log entries, can I assess how an event performs across different rules and targets?"%}} Absolutely. Each {{%link href="/en/signals/help/events/"%}}event{{%/link%}} record in Signals offers a comprehensive overview, allowing you to analyze its performance across various {{%link href="/en/signals/help/targets/key-aspects/"%}}targets{{%/link%}} within the same {{%link href="/en/signals/help/rules/key-aspects/"%}}rule{{%/link%}} and across different rules. {{%/expand%}} {{%/expand-container%}}