Field Types#

The following is a list of the field types we use internally. Normally, you'd choose one of these fields when creating your action fields or trigger fields via the type dropdown:

field types

However, if you're using Custom Fields you might want to know the available field types. The key column corresponds to the type key found in the code example here: Action Fields (Custom).


Unicode fields are essentially one-line text fields that can support unicode characters. There is no coercion done for this type.

Unicode fields are represented by a type: unicode key.


Think of this as a multi-line unicode field. It's really only used to give the user a textarea in the UI instead of a one-line input field. There is no coercion done for this type.

Textarea fields are represented by a type: text. key


Suitable for whole integer numbers, we'll coerce any text down into an integer by stripped non-numeric values from the string. A negative sign (-) in front is also allowed.

Integer fields are represented by a type: int key.


Like integers, this will coerce any text down to a floating point number with the addition of allowed characters like . and ,.

Float fields are represented by a type: float key.


We apply some natural language parsing to try and coerce any text into True or False. This UI field is also replaced with a dropdown allowing the user to specifically pick "Yes" or "No" explicitly.

Boolean fields are represented by a type: bool key.


Our most complex coercion. We'll attempt to convert any given value into an ISO-8601 formatted string. The parser is quite robust, supporting epoch timestamps, ISO-8601 and even natural language parsing! You can use moment.js via Scripting to parse and replace if your servers expect a different format sent to it.

DateTime fields are represented by a type: datetime key.


This is a fairly complex shortcut to a widget that allows a user to provide a series of key/value pairs, perfect for providing completely unstructured and custom metadata (do not use this if your API provide definitions for that metadata, look into custom fields instead!).

Dictionary/Object fields are represented by a type: dict key.


This field represents a file object itself – not a text field describing a file. If a URL is provided by a user, we will download the data at that URL and provide the resulting file object to your app. If non-URL text is entered here, we will create a .txt file containing the field contents and provide that file to your app. A deeper dive into files from a developer perspective can be found here: Files).

File fields are represented by a type: file key.


Copy can be used to bring extra attention to important help text. No user input will be provided with copy – it is simply static text.

Copy fields are represented by a type: copy key.

There are also a few other special things, related to types, you can do.

Static Dropdown#

You can provide a choices array which will be mapped automatically into a dropdown in the Zap Editor. In the developer UI you should simply provide us with a hard-coded list of comma-separated values for the "choices" option when defining a field. If you're using scripting, you'll want to provide these choices to us manually. Here is a code sample and what it looks like:

    "type": "integer",
    "key": "priority",
    "label": "Priority",
    "helpText": "Low Priority alerts do not send a notification. Medium Priority alerts send one notification. High Priority alerts send one notification every hour.",
    "choices": {
      0: "Low Priority",
      1: "Medium Priority",
      2: "High Priority"

field choices

You can also provide an array of just labels for choices if you like. This will be equivalent to providing an object where every key matches its value.


Say you wanted to allow the user to specify multiple values for a single field. Maybe, a list of tags to apply or a list of email addresses to send to. You can use our list feature to enable "+" and "-" buttons in the Zap Editor which users can use to specify more than one value. list fields can be any type except dict or file.

You can make a field a list by checking the appropriate box in the UI. For custom fields, you can use Scripting to alter the field definition to include list: true like this:

    "type": "unicode",
    "key": "to",
    "label": "To",
    "help_text": "What email addresses should this email be sent to?",
    "list": true

field list

↑ Was this documentation useful? Yes No