--- title: "Server-Side Module Execution" slug: "server-side-module-execution" updated: 2025-09-26T07:00:04Z published: 2025-09-26T07:00:04Z canonical: "docs.unqork.io/server-side-module-execution" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.unqork.io/llms.txt > Use this file to discover all available pages before exploring further. # Server-Side Module Execution ## Overview **Server-side** **module** **execution** is a module that executes outside of the end-user's browser. That is, the module performs its function on the server. To configure a server-side execute, use the **Execute** **Module** API call. ## Execute Module Call In the list of Unqork APIs documentation ([developers.unqork.io](https://developers.unqork.io/#tag/Modules%2Fpaths%2F~1modules~1{moduleId}~1execute%2Fput)), you’ll find a call for **Execute** **Module**. This is the call you use to create a server-side module execution. Think of this call as a trigger. But, instead of triggering a component in the module, the call triggers an entire module. Without using **Execute** **Module**, an application's API calls happen in the browser. “In the browser" means that all data and API calls run in Express View. Everything happens on the page that the end-user sees. In a remote execute, everything happens behind the scenes on the server. The API calls happen in a module unseen by the end-user. ## Why Are Server-Side Executions More Secure? If an API call runs in the browser, any end-user can open the DevTools Console and inject malware or access private information. Creating remote execute modules prevents malicious actors from accessing sensitive data. Executing internal API calls, like Get Submissions, Create Submission, or Update Submission, in server-side modules is beneficial in the following ways: - **Speed**: API calls occur using a remote server, unburdening the browser. - **Security**: Bad actors cannot access Personally Identifiable Information using the DevTools Console. - **Easier Debugging**: Creating modular API modules provides a smaller codebase when troubleshooting. > [!TIP] > Server-side execution enables HTTP status code outputs in API modules. To learn more about HTTP Output, visit our [HTTP Status Codes](/v1/docs/http-status-codes) article. ## Creating APIs From Modules For this example, you might have a module that sends email reminders. The module has a Plug-In using the [SendGrid API](/v1/docs/sendgrid-in-unqork). When triggered, the Plug-In sends an email. We'll call this the SendGrid module. In a separate front-end module, you configure a Plug-In to make a Remote Execute call to the SendGrid module. When that happens, the SendGrid module executes. The SendGrid Plug-In triggers and the email sends. When you create this type of configuration, you’re essentially building your own API call. The SendGrid module API. It’s best practice to modularize your application so that each API call is its own module. For example, an application might have a Create Submissions Module, an Update Submissions Module, a Get Submissions Module, and so on. When you remote execute these modules, you’re calling them like you would an API. ## Configuring a Remote Execute Configuring the Execute Module Plug-In is fairly simple. The most important part is knowing the module ID of the remote execute module. Adding this ID to the Data Source URL tells the Plug-In which module to execute. You also need to set up the module being executed so it can properly receive the API call. Think about it like an office building that has a phone at the front desk. When you call the office, a receptionist answers the phone and directs your call. Offices have someone to take phone calls. Likewise, your remotely executed module needs a component to detect the API call. **I****nitializer** components can serve as the module's receptionist. With a New Submission or Edit Submission trigger type, the Initializer detects when the module is remotely called. So, when the module gets called, the **I****nitializer** triggers, setting the module's chain of events in motion. In the Unqork Designer Platform, you can find a snippet to create an API module. Look for the **API Specification** **Snippet**. You can read more about this snippet here: [https://academy.unqork.com/api-course/436010](https://academy.unqork.com/api-course/436010). Because of our security standards, **all Plug-Ins in the front-end** **module** **must use the Execute** **Module** **call**. There must always be a layer between a front-end module and an API call. ## Error Handling Error handling a remote execute takes special attention. When a module successfully remote executes, you’ll see a **200 OK** response. However, that doesn’t mean the call behind the remote execute was successful. Let's use the example of creating a SendGrid API module. SendGrid supports the use of API calls to send emails automatically. Within Unqork, you can trigger an API call to SendGrid based on user interaction. For example, you can set a **Button** component that, when clicked, triggers an API call to SendGrid. This ultimately results in SendGrid sending an email. You remote execute the SendGrid API module. The Execute Module call returns a **200 OK** response. But, the email never sends. The response to the Execute Module call doesn’t tell you anything about the SendGrid call. ![](https://cdn.us.document360.io/15548f06-2fba-434c-b0c1-5df88317dbd7/Images/Documentation/APIs_Server_Side_Execution_01_thumb_0_0.jpg?sv=2026-02-06&spr=https&st=2026-11-07T17%3A57%3A38Z&se=2026-11-07T18%3A57%3A38Z&sr=c&sp=r&sig=7bnr43YUbeKfrWolgRXmU46QW00sdD9Cl0p8S2bkqUU%3D) This is where error handling comes into play. Any API calls you create should include an error trigger. This lets you know if an error occurs in the API call. The error trigger logs an error message into a hidden field. That hidden field then comes back in response to your Execute Module API call. > [!TIP] > To learn more about error handling, view our Introduction to [Error Handling in Unqork](https://docs.unqork.io/Content/K-Solutions/K01-Troubleshooting_Error_Handling/K01003-Error_Handling.htm) article. ## Best Practices - Avoid chaining several server-side executed modules. Chaining can impact performance as each module executes a separate call to the server. For example, it might require 100 milliseconds to call from the back-end to your server-side executed module. Creating unnecessary layers of chained remote executes might add extra API calls between modules and can slow your application's performance. ## Resources - [How to: Use the Server Side Execution Testing Page](/v1/docs/how-to-use-the-server-side-execution-testing-page) - [Server-Side Execute Q&A](/v1/docs/server-side-execute-qa) - [Use Case: Server-Side Module Execution](/v1/docs/how-to-configure-a-sendgrid-api-module-with-server-side-execution-sse) End-users, also known as Express Users, are the individuals accessing an application through Express View. In most cases, end-users are the customers using the product. APIs (application programming interfaces) are a set of protocols and definitions developers use to build and integrate application software. APIs act as the connective tissue between products and services. The DevTools Console helps you securely store, build, test, and deploy your software. Malware is software designed to disrupt, damage, or gain access to a computer system. A bad actor is a cybercriminal or organization that might attempt to exploit vulnerabilites in your environment or application. Common exploits used by bad actors include XSS (cross-site scripting) attacks, malware, randsomware, and more. Personal Identifiable Information (PII) is any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means.