> For the complete documentation index, see [llms.txt](https://docs.rewst.help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rewst.help/documentation/automations/actions-in-rewst/core-actions.md). # Core actions *Core actions* in Rewst Classic are your gateway to the platform's vast array of intrinsic functionalities. These actions, usable right out of the box, offer features ranging from ad-hoc HTTP requests to document parsing. Core actions are used in the same way as regular actions within workflows. They are selected from the list of available actions, configured based on their parameters, and then added to the workflow at the appropriate place. {% hint style="info" %} Expand each of the action types below to see their individual information. {% endhint %} ## Core actions: Communication
Confirmation Email action Send a confirmation email with reply options to a specified recipient.\ This action pauses the workflow and places it in an `Awaiting-User-Input` state. The workflow will not proceed until the confirmation email is interacted with via buttons, or the task times out. You can configure task timeout on the **Advanced** tab of the action. Task time out means that the action fails. Note that this setup means that buttons are required for the workflow to proceed.\ \ ![](https://1835401289-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FAQQ1EHVcEsGKBPVHmiav%2Fuploads%2FoCKZUI0xmHCAnNcR7KJJ%2Fimage.png?alt=media\&token=afc8719f-db57-4137-b18c-da10fbb547af) **Parameters** * This action requires the recipient's email address (`to`), the subject of the email (`subject`), the title of the email (`title`), and the message body (`message`). It also offers user interaction buttons (`buttons`) and has the option to render markdown as HTML (`render_markdown`). * The parameters have several optional settings: * Custom Button CSS - Custom CSS to be applied to the buttons * Custom Footer - Custom footer to be displayed in the email. If not provided, this will default to the Rewst footer unless the footer is set to be removed. * Custom Title CSS - Custom CSS to be applied to the title * Logo Link - URL to go to if the logo is clicked. If not provided, this will default to [https://rewst.io](https://rewst.io/) * Logo URI - String value URI of the logo to be displayed in the email. If not provided, this will default to the Rewst logo image. This is essentially providing a value for the src param of a img tag. You could also provide a base64 encoded value. The file format for your hosted file will need to follow the guidance for your particular email client, which is independent of Rewst. For example, Outlook does not accept PNG formatted files. For broader guidance for all email clients, we recommend using this resource called [caniemail](https://www.caniemail.com/features/). * Remove Footer - Removes the Rewst footer from the email * Render Markdown - Renders markdown as HTML when set to **True** **Output** * If the action is correctly executed, a confirmation email will be sent. * Output variable `inquiry_result` is an output of the task and can be used to route the workflow in a specific path. `Inquiry_result` 's value is that of the button clicked, and is configured as a string value on the action itself in the workflow builder.
* Confirmation email class and confirmation examples * Button classes: * Primary; primary * Default; default * Danger; danger * Title class: * Title; title **Example custom button CSS** ```css a, a:visited, a:hover, a:active { color: inherit !important; } table, td, div, h1, p { font-family: "Times New Roman", Times, serif; } .primary { background: #4d7c0f; } .default { background: #365314; } .danger { background: #dc2626; } ``` **Example custom footer** ```

© The Dougnut {% now 'local', '%Y' %}

Order

Contact Us

Need Delivery?

linkedin

twitter

``` **Example custom title CSS** ``` .title { font-size: 20px; line-height: 16px; font-weight: 700; font-style: normal; color: #0c0a09; text-decoration: none; letter-spacing: 0px; padding: 25px 30px 0 30px; } ``` **Example logo link** ``` https://google.com ``` **Example logo URI** ``` https://www.svgrepo.com/download/533811/donuts-cake.svg ```
Send SMS action This action sends a text message to a phone number via Rewst's built-in SMS capability. Use it for alerting or notification workflows where email isn't sufficient. Keep messages concise and ensure phone numbers are in the correct format for your region **Parameters** * **Phone Number**, required: The recipient's phone number * All phone numbers must be provided using the E.164 international format, which includes the country code: example: `+14155552671` * Improperly formatted numbers may result in validation errors or delivery failures * **Message**, required: The text message content. Can reference a saved Rewst Template **Output** * The output of this action will depend on the implementation details. Usually, it will return a confirmation message or an error message. **Sending number origin** The `core_send_sms` action sends messages from a US-based phone number owned and managed by Rewst. Due to this setup: * SMS delivery is most reliable for United States phone numbers * Some international carriers restrict or block messages originating from US long-code numbers * Certain countries require locally registered sender IDs or approved messaging routes These limitations are imposed by telecommunications carriers and regional messaging regulations. **When to use your own messaging account** If you need to send SMS messages to a region that is not supported by the shared Rewst sending number, you can set up your own messaging account and use it through Rewst’s [Twilio integration](/documentation/integrations/integration-guides/twilio-integration-setup.md). Using your own account allows you to: * Purchase local phone numbers in supported countries * Configure which countries your numbers can send messages to * Register country-specific sender IDs * Meet regional compliance requirements **Delivery behavior** When the `core_send_sms` action is executed, it returns the **current delivery status** for the message. This status reflects the system's understanding of the message state after it has been sent to the carrier networks. Even when a message is reported as sent, final delivery still depends on external telecom carrier networks and the recipient device. Because SMS delivery involves multiple third-party carriers, failures may still occur due to: * Carrier filtering * Regional messaging restrictions * Unreachable devices * Network congestion * Recipient opt-outs **Common SMS error responses** * SMS service is temporarily unavailable, please try again later * Invalid phone number format * SMS cannot be sent to this region - geographic permissions not enabled * This recipient has opted out of receiving messages * SMS cannot be delivered to this number due to carrier or regional restrictions * This number is a landline and cannot receive SMS messages * The phone is currently unreachable (switched off or no signal) * This phone number is unknown or may no longer exist * This number cannot receive SMS messages (likely a landline or unsupported carrier) * Network congestion - please try again in a few minutes **Error scenario: Carrier or regional restrictions** This situation occurs when the destination carrier or region doesn't allow messages from the sending number. Possible causes include: * Sender ID restrictions in the destination country – Some countries limit which numbers, shortcodes, or alphanumeric sender IDs can be used. * Sender ID restrictions on the destination network – Certain networks may block messages from shortcodes or restrict MMS messages from longcodes that originate outside the country. * Alphanumeric sender IDs – If you are using an alphanumeric sender ID, the destination country must support it, and some countries may require pre-registration. * Number formatting – The “To” or “From” number may not be in the proper international format (E.164). Check that numbers are correctly formatted. * Destinations with no connectivity – Some carriers or regions may not have messaging routes available for your sending number. * This error is more common when sending international messages from a US-based number. If you need to reliably reach a destination with restrictions, consider using your own messaging account via the Twilio integration, where you can configure allowed countries, local numbers, and sender IDs. **Error scenario: Messaging geo-permissions disabled** This situation occurs when an SMS or MMS message is sent to a country or region that the Rewst-managed sending number is not authorized to send messages to. Possible causes: * The destination country is not included in the allowed countries for the Rewst sending number * The region is not supported for SMS delivery from the Rewst-managed sending number * Messaging to that region is restricted by telecom regulations * If you need to send messages to a country that is not supported, consider using your own Twilio account via the Twilio integration, where you can configure allowed countries and sender IDs. **Error scenario: Recipient has opted out** The recipient has opted out of receiving messages from the sending number. **Error scenario: Landline number** The destination phone number is a landline and cannot receive SMS messages. **Error scenario: Phone unreachable** The destination device cannot currently be reached. Retrying later may resolve the issue. Possible causes: * Device powered off * No cellular signal * Temporary carrier network issues **Error scenario: Unknown or unreachable numbers** The destination number may not exist, cannot receive SMS, or is otherwise unreachable due to carrier restrictions. **Error scenario: Network congestion** The carrier network is currently congested. Retrying the message later may resolve the issue.
Send Mail action This action sends a plain or markdown-formatted email via Rewst's email infrastructure. Use it for notifications, summaries, and reports. For interactive emails where the recipient needs to make a choice, use the Confirmation Email action instead. You can't upload images to Rewst, so any image will need to be externally referenced via URL. The file format will need to follow the guidance for your particular email client, which is independent of Rewst. For example, Outlook does not accept PNG formatted files. For broader guidance for all email clients, we recommend using this resource called [caniemail](https://www.caniemail.com/features/). Emails will still be sent from the rewst.io domain. **Parameters** * **Recipient**, required: The destination email address. * **Sender**, required: The Rewst sending address to use (options: noreply@, no-reply@, donotreply@, rewsty@, rewstybot@, response@, auto-reply@, forms@ — all @rewst.io) * **Subject**, required: Email subject line * **Title**, required: Heading displayed at the top of the email body * **Message**, required: Body content; can reference a saved Rewst Template * **Custom HTML**: Fully custom HTML for the email body; if provided, Title and Message are ignored * **Render Markdown**: Renders markdown syntax as HTML, with a default to true **Output** * The task doesn't yield an output upon success. It will fail if there are any errors during the process of sending the email.
## Core actions: Data transformation
Compare Strings Set Ratio action This action calculates the ratio of how many words from the smaller string are found in the larger string. It's designed for measuring string similarity based on word overlap rather than character-by-character comparison. This action is particularly useful when you need to determine how similar two text strings are based on shared words, making it ideal for scenarios where exact string matching is too strict but you still need to measure content similarity. Use it for: * Fuzzy matching between text strings * Duplicate detection in datasets * Content similarity analysis * Partial string matching scenarios **Parameters** * **original\_string** (required): The original string to compare * **comparison\_string** (required): The comparison string that is being compared to **Output** * Returns an integer representing the ratio of word overlap between the two strings * Higher values indicate greater similarity
Parse HTML action The Parse HTML action is a versatile tool within Rewst, geared to pinpoint and extract specific elements or data from HTML documents. It parses an HTML string using BeautifulSoup and extracts matching elements or text from HTML files. **Use cases** This action is particularly beneficial in these situations: * **Data Extraction**: capturing specific information from the response of an HTTP request. * **Content Clean-Up**: sieving out only the necessary data from complex HTML content. * **Web Scraping**: automating the extraction of specific information from various web pages using defined tags, classes, or identifiers. **Parameters** * **HTML**: The HTML content to be parsed. This could be HTML content from a webpage, obtained using the `HTTP Request` Core Action. * **Class**: Optionally finds HTML elements based on their `class` attribute. * **ID**: Optionally searches for HTML elements based on their `ID` attribute. * **Query**: Employs [BeautifulSoup filters](https://www.crummy.com/software/BeautifulSoup/bs4/doc/#kinds-of-filters) to specify the operation type: * find\_all returns all instances of the defined HTML tag. * find returns only the first instance of the defined HTML tag. * select enables the use of CSS selectors for nested HTML tags. * **String**: Optionally searches for specific text within the HTML content. * **Value**: Identifies the tag or selector to search for in the HTML content. For example, `a` would find all anchor (``) tags in the HTML content. **Output** * An array of mayching string values is returned. **Practical Use Case: Extracting Links from 'Hacker News'** This example involves making a `GET` request to the `Hacker News` website and parsing the returned HTML to extract all `` links. The first step uses the Core `HTTP Request` action to fetch the HTML content: ```yaml publish_result_as: news request_method: GET URL: https://news.ycombinator.com ``` You can then use the `Parse HTML` action to extract all `` links. The parameters for this action would be set as follows: ```yaml html: {{ CTX.news }} style: find_all value: a ``` **Example Workflow Results** Here's an example of how the `Parse HTML` action's input and output might look like on the workflow results page: **Input from the HTTP Request:** ```json html: { cookies: {}, data: "...", headers: {...}, status_code: 200 }, query: { style: "find_all", value: "a" } ``` **Result:** ```yaml [ "", "Hacker News", "new", "past", "comments", "ask", "show", "jobs", "submit", "login" ] ``` This result contains all `` tags found in the HTML content. To further refine this output, returning only links for externally referenced pages, use the `select` query style, along with advanced CSS filters: ```yaml html: {{ CTX.news }}, style: select value: .titleline a[href^='https://'] ``` The result is a list of strings containing all `` tags that meet the newly specified criteria: ```json [ "Electronic Structure of LK-99", "A room-temperature superconductor? New developments", "Epicycle Clock", "Emacs is my new window manager", "Splitting the Web", "Unconfirmed video showing potential LK-99 sample exhibiting the Meissner effect", "Show HN: Magic Loops – Combine LLMs and code to create simple automations", "eGPU: A 750 MHz Class Soft GPGPU for FPGA" ] ``` To further understand CSS selectors, you can refer to this [w3schools article](https://www.w3schools.com/cssref/css_selectors.php). ***Tip**: Parse HTML's functionalities include finding elements by tags (`

`), class (`class_="abc"`), text (`string="The content"`), or id (`{"id": "abc"}`). When `string` is the sole argument, only the text is returned, not the whole element, which can help you fine-tune data extraction.*

Parse XML action The Core Parse XML action in Rewst is designed to locate and extract specific elements or data from XML documents. This powerful tool, backed by an efficient Python library, facilitates precise data extraction from XML files, simplifying the process of parsing complex data structures. For additional understanding on XPath expressions, refer to this [w3schools article](https://www.w3schools.com/xml/xpath_intro.asp). **Use cases** Consider using the Parse XML action in these scenarios: * **Data Extraction and Content Clean-Up:** Capture specific information or filter out necessary data from XML-formatted content. This is particularly useful in processing responses from HTTP requests or handling complex XML documents. * **Web Scraping:** Automate the extraction of specific information from various XML sources using defined tags, attributes, or identifiers. It enables you to precisely target the data you need from web resources. **Parameters** * **XML**: The XML content that needs to be parsed. This could be XML content from an API response, obtained using the HTTP Request Core Action. * **Attributes**: (Optional) Allows you to find XML elements based on their attribute key. * **ID**: (Optional) Permits searching for XML elements based on their ID attribute. * **Selector**: Determines the operation type. Options include: * find: Returns only the first instance of the defined XML tag. * find\_all: Returns all instances of the defined XML tag. * select: Enables the use of XPath expressions for nested XML tags or conditional searches. * **String**: (Optional) Allows you to search for specific text within the XML content. * **Value**: Specifies the tag or selector to search for in the XML content. **Output** * An array of matching string values is returned. **Practical Use Case: Extracting Books from a Bookstore's XML Data** Before diving into parsing XML data, you'll need to fetch the XML file. In this use case, the XML file is fetched from a public URL which contains bookstore data in XML format. The first task in the workflow, called `get_books`, uses the Core `HTTP Request` action to fetch this XML content: **Input parameters:** ```yaml url: http://books.toscrape.com/catalogue/category/books_1/index.html request_method: GET publish_result_as: get_books ``` The result from this task will look something like this: ```json { "cookies": {}, "data": "...", "headers": {...}, "status_code": 200 } ``` The `data` field contains the XML content, which is the input for the `Parse XML` action. The XML content is passed using the Context (`CTX`) object as `CTX.books.data`. **Finding the first book** In this scenario, we are using the `find` operation to return the first `book` element in the XML: **Input parameters:** ```yaml input: xml: {{CTX.books.data}} selector: find value: book ``` The result from this task will look something like this: ```json { "value": "Everyday ItalianGiada De Laurentiis200530.00" } ``` The output includes the first `book` element in the XML content. **Selecting all 'Children' category books** For a more complex operation, we can use the `select` operation with an XPath expression to extract all `book` tags where the `category` attribute is `children`. **Input parameters:** ```yaml xml: {{CTX.books.data}} selector: select value: book[category='children'] ``` **Result:** ```json { "value": "Harry PotterJ K. Rowling200529.99" } ``` The result includes all `book` tags where the `category` attribute is `children`.
## Core actions: Execution control
Create Pending Task action This action creates a pending task that pauses workflow execution and requires manual intervention through the Rewst UI. It's designed for scenarios where human approval, confirmation, or decision-making is needed within an automated workflow. **Use Cases**: * Manual approval workflows * User confirmation before critical actions * Decision points requiring human judgment * Interactive workflow processes * Quality control checkpoints **Parameters**: * **message** (required): The message to display in the pending task that explains what action is needed from the user * **buttons** (required): An array of button objects that users can click to respond. Each button has: * **label**: The text displayed on the button * **style**: Visual style (`default`, `primary`, `danger`) * **value**: The value returned when the button is clicked **Output**: The workflow pauses at this task until a user interacts with it via the Rewst UI. When a button is clicked, the action returns the corresponding button value, allowing the workflow to continue based on the user's choice. This action is essential for creating interactive workflows that require human oversight or decision-making at specific points in the automation process.
Delay Workflow For Period action This action pauses the workflow for a relative duration: a set number of days, hours, minutes, or seconds from the current moment. All four fields are additive, so you can combine them — e.g. 1 day + 4 hours. Use this when you know the duration but not the exact target time. For a specific target time, use the Delay Workflow Until Date/Time action instead. **Parameters** * **Days to Delay**: Number of days (default: 0) * **Hours to Delay**: Number of hours (default: 0) * **Minutes to Delay**: Number of minutes (default: 0) * **Seconds to Delay**: Number of seconds (default: 0) **Output** * There is no specific output. * The workflow resumes after the specified delay.
Delay Workflow Until Date/Time action This action pauses a workflow execution at that point until a specific date and time is reached, then resumes automatically. Think of it as a "sleep until" instruction — the workflow just waits, consuming no active resources, until the clock hits the target time. If no date/time is provided, the workflow continues immediately without any delay. It's commonly used for scheduling maintenance windows, delayed user creation, cooling-off periods on escalations, or any time-separated multi-step process. There's a 30-day limit on how far into the future you can delay. Requests beyond that will fail, so validate your input if it's user-supplied. Since the workflow is just paused, not re-triggered, the full execution context is preserved when it resumes; all your `CTX` variables are still intact. **Parameters** * **Delay Until**: This is the date and time you want the workflow to resume at. It expects a datetime string in `datetime-local` format. In practice, you'll almost always want to supply this dynamically via Jinja rather than hardcoding a static value. * The key is feeding the `expires_at` field a properly formatted datetime string. Here are the most common patterns: Delay until a specific future time (e.g. tomorrow at 9am UTC): ``` {{ now() | convert_from_epoch | time_delta(days=1) | format_datetime('%Y-%m-%dT09:00:00') }} ``` Delay until a datetime stored in CTX (e.g. from a form input or ticket field): ``` {{ CTX.scheduled_datetime }} ``` Just make sure the value is already in a compatible datetime format. Delay until a calculated time (e.g. 2 hours from now): ``` {{ now() | convert_from_epoch | time_delta(hours=2) | format_datetime('%Y-%m-%dT%H:%M:%S') }} ``` **Output** * The action produces no output. There's nothing to publish or reference after it. Its only job is to pause and resume.
No-Operation (Noop) action A noop action does nothing. It's often used for logic or as a placeholder in the workflow. Use noops for routing logic (fan-out/fan-in), convergence points where multiple branches meet, and creating CTX variables via transition data aliases. Never use `publish_result_as` on a noop since it produces no output — use transition data aliases instead. **Parameters** None **Output** None
Fail action This action immediately terminates the workflow in a failed state. The workflow execution stops and is marked as failed. It's the explicit, intentional counterpart to a workflow completing successfully. There is no result, so nothing can be published or referenced downstream. No further actions will run after this action is reached. If you need cleanup logic before ending, route through a noon-based cleanup path before reaching the fail action. It's commonly used for scheduling maintenance windows, delayed user creation, cooling-off periods on escalations, or any time-separated multi-step process. There's a 30-day limit on how far into the future you can delay. Requests beyond that will fail, so validate your input if it's user-supplied. Since the workflow is just paused, not re-triggered, the full execution context is preserved when it resumes; all your `CTX` variables are still intact. **Parameters** * **Message**: The failure message that will appear in the workflow execution log, explaining why the workflow was intentionally failed * Default message is `Task manually failed` **Output** None
## Core actions: HTTP and networking
DNS Query action This action queries a public nameserver for DNS records associated with a given domain. It's useful for verifying domain configurations, checking MX records before email setup, or validating SPF/TXT records as part of onboarding workflows. **Parameters** * **URL** *(required)* — The domain to query (e.g. `example.com`). * **Field to Query** *(required)* — The DNS record type (A, MX, TXT, CNAME, NS, SPF, etc. — full list available in the action). * **Nameserver** *(required)* — Which DNS resolver to use: Google (8.8.8.8 / 8.8.4.4), Cloudflare (1.1.1.1 / 1.0.0.1), or OpenDNS (default: Google 8.8.8.8). * **Timeout** — Query timeout in seconds (default: 60). **Output** * The specified DNS records associated with the given URL from the queried nameserver.
HTTP Request action This action performs an HTTP request to a specified URL, supporting a variety of methods, body content types, and configurations. This is useful for interacting with APIs or other web services within a workflow, or for performing any other tasks that involve HTTP requests. {% hint style="info" %} *In most cases, we recommend that you use a* [*Custom Integration*](/documentation/integrations/custom-integrations.md) *instead of this HTTP Request action. This allows for enhanced security and customization when interacting with your external APIs. The* HTTP Request action will require building out all endpoints as individual actions/subworkflows. It is only recommended for when Custom Integration is not possible or repeatedly fails. {% endhint %} **Parameters** * **URL**: The URL to which the HTTP request is sent. * **Request Method**: The HTTP method to use for the request. You can select from the dropdown options (`HEAD`, `GET`, `POST`, `PUT`, `DELETE`, `OPTIONS`, `TRACE`, `PATCH`, `PURGE`). * **Auth Username**: The username for basic HTTP Authentication, if needed. * **Auth Password**: The password for basic HTTP Authentication, if needed. *(This parameter is secret to ensure security.)* * **Allow Redirects**: Specifies whether the HTTP request will follow redirects. By default, it's set to `true`. * **Body**: The body to send with the request. This parameter is not required if `JSON` or `Files` is provided. * **JSON**: The JSON body to send with the request. This field is not required if `Body` or `Files` is provided. * **Files**: Here, you can add files to be uploaded with the HTTP request using `multipart/form-data`. Each file requires the following information: * **Field Name**: The name of the form field (not the filename). * **File Name**: The name of the file. * **File Contents**: Contents of the file to upload. * **File URL**: A publicly-accessible URL to the file contents to upload. * **Content Type**: The MIME type of the file to include in the multipart field. * **Cookies**: Input the cookies to send with the request. You can add more than one cookie by clicking on the `+` icon. * **Headers**: Specify the custom HTTP headers to be sent with the request. You can add more than one header by clicking on the `+` icon. * **Params**: Enter the query parameters to be used with the HTTP request. You can add more than one parameter by clicking on the `+` icon. * **Timeout**: Enter the timeout for the HTTP request in seconds. The default value is `5`. * **Require Success Status**: If you check this box, the task will fail if a non-2xx HTTP status code is returned. This is useful for identifying and handling HTTP errors during the task's execution. **Output**: The action returns the content returned by the server in response to the HTTP request. This could be a success message, a failure message, a data object, or any other content that the server sends as a response.
## Core actions: Utilities
Debug action This action outputs a text string or rendered template to the workflow execution log. It's useful for inspecting values mid-workflow without affecting flow. Drop this in between tasks when troubleshooting to log the value of a CTX variable, e.g. `{{ CTX.user_email }}`. Remove or bypass it once you're done debugging. You might want to use the Debug action in the following scenarios: * When developing workflows, to see how data is flowing between tasks and actions. * If you're troubleshooting an issue, to inspect the data that's being passed around. * When you want to log specific information for auditing or reporting purposes. **Parameters** * **Text:** This is a general-purpose text field that will be logged and returned by the `Debug` action. * **Template:** This field takes a reference to a template in your environment that will be rendered and used as part of the action's input. The system will replace any variables in the template with its actual value at the time of template rendering. **Output** * There is no output for this action. * Output appears in the execution log only. **Example usage** You have a template named "Greeting Message" with content `# Hey there {{ CTX.name }}`. Use this template in the `Debug` action with the following parameters: ```yaml text: Testing Debug Action template: Greeting Message ``` Assuming `CTX.name` is set to `Rewsty`, the rendered template would be `# Hey there Rewsty`. The Debug action will log these parameters and also return them as its output. The results of the action on the workflow results page would look like this: **Output:** ```json { "template": "# Hey there Rewsty", "text": "Testing Debug Action" } ``` This tells us that `CTX.name` was set to`Rewsty`, and the text provided with this action was `Testing Debug Action`. Using this, you can better understand the state of your workflow at the point this Debug action was executed.
Generate Password V2 action An upgrade from the deprecated password generation action. It crafts a cryptographically secure password with user-specified values. (*This is recommended for use over the deprecated Password Action due to its upgraded structure.)* * **Parameters:** length, minimum counts of numeric and capital letter characters, and optional punctuation characters. * **Output:** the generated password is presented under the "password" key in the output.
Mock action This action returns a fake, predefined result as if a real action had run. It's used during workflow development to simulate responses from services not yet available. Drag this in place of a real action while building, configure the shape of the expected response, and build your downstream logic against it. Swap it out for the real action when ready: * When designing new workflows where certain steps are not fully implemented. * In testing stages, to simulate conditions without making actual calls to the services. * To create controlled conditions in your workflow for troubleshooting issues. **Parameters** * **Mock Result:** This parameter should contain the key / value pairs that you want to be returned by this action. You can press the `+` to add as many objects as necessary. Jinja expressions inside this object are returned as-is, not evaluated. **Output** * The mock result object wrapped in a `data` property is returned. **Example use** You are developing a workflow that is expected to interact with a service which is not yet implemented. You know the expected format of the response, and you want to build and test your workflow logic based on that response. Let's say you know the response will look something like this: ```json { "name": "Rewsty", "valid": true, "message": "Successfully completed the task." } ``` You can simulate this response using the `Mock` action as follows: ```yaml mock_result: name: {{ CTX.name }} valid: true message: Successfully completed the task. ``` While using the `Mock` action, the values can be literal Jinja expressions like `{{ CTX.name }}`above. The action will return this exact input structure wrapped inside a `data` object, and the Jinja expressions will not be evaluated but returned as is. The result of the action on the workflow results page would look like: **Output:** ```json { "data": { "name": "{{ CTX.name }}", "valid": true, "message": "Successfully completed the task." } } ``` This can be useful for catching issues early in the development phase such as incorrect Jinja expression usage, understanding how the workflow will handle dynamic data, or verifying that your workflow is properly constructed to handle the expected responses from services. It's a way to ensure that your workflow behaves as expected when it starts receiving actual dynamic data.
Test All Parameter Types action This action serves as a comprehensive example and testing tool that showcases all the different input field types that can be used in Rewst actions. It's primarily used for: * UI testing and validation * Demonstrating parameter field capabilities * Training and educational purposes * Testing form rendering and validation **Inputs** The task accepts a wide variety of input parameters representing every field type available in Rewst: **Basic fields:** * `simple_string` (required) - Basic text input * `optional_string` - Optional text field * `string_with_default` - Text with default value "default\_value" * `simple_integer` (required) - Whole number (default: 42) * `simple_number` - Decimal number (default: 3.14) * `simple_boolean` - Toggle switch (default: false) * `required_boolean` (required) - Required toggle **Advanced string fields:** * `string_enum` (required) - Dropdown with options (option\_1, option\_2, option\_3) * `string_enum_objects` - Dropdown with custom labels and descriptions * `radio_selection` (required) - Radio button group * `secret_string` - Password/masked field * `multiline_text` - Large text area * `textarea_content` - Code editor area **Date/Time fields:** * `date_field` - Date picker * `time_field` - Time picker * `datetime_field` - Date and time picker **Array fields:** * `simple_array` - Array of strings * `array_with_enum` - Multi-select dropdown * `array_of_objects` - List of complex objects with name, enabled, and quantity fields **Object fields:** * `simple_object` - JSON object field * `nested_object` - Complex nested object with host, port, SSL settings, and credentials **Special fields:** * `number_with_range` - Integer between 1-100 (default: 50) * `local_reference_template` - Reference to local templates * `remote_reference_example` - Reference to remote API options * `remote_reference_with_dependency` - Dependent reference field **UI state fields:** * `tooltip_field` - Field with helpful tooltip * `hidden_field` - Hidden from UI * `disabled_field` - Cannot be edited * `readonly_field` - Read-only display * `deprecated_field` - Marked as deprecated * `staff_only_field` - Only visible to staff users **Outputs** The action returns a simple object with two properties: * `message` (string) - A test result message describing the outcome * `success` (boolean) - Whether the test execution was successful
UUID action This action generates a new universally unique identifier (UUID). Use `publish_result_as` to store the UUID in CTX and use it as a unique correlation ID, idempotency key, or reference number for records created across multiple systems in the same workflow run. **Parameters** * UUID type: * **UUID1**: time-based * **UUID4**: random, most common, default * **UUID7**: time-ordered, random **Output** * The generated UUID is returned as a string.
## Core actions: Webhooks
Await Webhook Request action This action pauses the workflow and waits for an incoming HTTP request to a previously created one-off webhook. Once a request arrives, the workflow resumes with the request data available. Always pair this with the Create Webhook acgtion. Create the webhook first, publish its `webhook_id` to CTX, then feed `{{ CTX.webhook_id }}` into this action downstream. To access the results of a webhook, publish a [data alias](/documentation/automations/workflows/data-aliases.md) with a value of `{/{ RESULT }/}.` You cannot merely publish the results as or use task. **Parameters** * **Webhook ID**: The ID returned by the Create Webhook action, this tells the workflow which webhook to listen on. **Output** * The output includes the HTTP method, query params, headers, JSON or form/multipart data in the body of the request, and the timestamp when the request was received.
Create Webhook action This action creates a temporary, one-off webhook URL that can receive a single HTTP request. It's always used in tandem with the Await Webhook Request action. **Parameters** * **Expiration Timeout** — How many seconds the webhook stays active before it stops accepting requests (default: 600 seconds / 10 minutes). * **Response Body** *(required)* — What the webhook sends back to the caller. You can use `{{ REQUEST }}` here to echo back request data. * **Allowed Methods** *(required)* — Which HTTP methods the webhook will accept (default: POST). * **Response Status** *(required)* — The HTTP status code returned to the caller (default: 200). * **Response Headers** *(required)* — HTTP headers included in the response (default: `{}`). **Output** * The output of this action is the webhook ID and the full URL of the webhook. * Create the webhook, publish `webhook_id` and `url` to CTX, send the URL to whatever external system needs to call back, then use Await Webhook Request to pause and listen.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.rewst.help/documentation/automations/actions-in-rewst/core-actions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.