Actions

Actions are custom JavaScript functions that run on Qik's servers. Use them to extend the platform with your own logic: receive webhooks from outside services, provide custom endpoints for your website or app, transform data, send tailored notifications, or connect Qik to other systems. This article is for builders who are comfortable writing JavaScript.

How actions are run

An action can be started in several ways:

• By URL: every action has its own endpoint that accepts GET and POST requests, so it can act as a webhook receiver or a custom API endpoint.
• By a time trigger: on a schedule. See Listeners and Time Triggers.
• By a listener: when a system event happens, such as a profile being created.
• By a content type automation: when items of a type are created, updated or deleted. See Definition Automations.
• By a workflow step: using the Run an action function. See Workflow Step Automations.

Creating an action

1. Open Developer from the sidebar. The Developer Tools page lists your Actions, Time Triggers, Listeners, Code Snippets and Global Variables.
2. Under Actions, click New Action.
3. On the Code tab, write your code. New actions start with a commented example to build from.
4. On the Configuration tab, give the action a title, set its permissions and other options, and choose its Security under Meta Data.
5. Add a test and run it (see below), then save.

The action editor

The editor has three tabs:

• Code: the code editor, with a test panel underneath for running the action with sample input.
• Configuration: title, permission sets, response headers, the Require confirmation option and the action's meta data (scopes, security and so on).
• Webhook: the action's endpoint URL and example GET and POST requests, including the headers to send.

Writing action code

Your code is the body of an async function. It receives:

• input: everything about this run. For a webhook call, input.body is the POST body and input.query the query string. When the action is started by a listener, content type automation, time trigger or workflow step, the triggering record is in input.item and there is no body.
• input.source: what started the run. source.type is one of webhook, test, definition, listener, timetrigger or workflowstep. For webhook calls, source.user is the caller's session.
• $sdk: a ready-to-use Qik SDK that runs with this action's permissions. Use it to read and write content, for example await $sdk.content.get(id).
• $user: for webhook calls, a second SDK that acts as the calling user, combining their permissions with the action's.
• plugins: install and load npm packages, for example await plugins.install("stripe") then plugins.require("stripe").

Always return an object:

• { success: true, ... } means the run worked. Any other properties you add are returned to the caller.
• { success: false, ... } marks the run as failed. A result without success: true is treated as a failure.
• { success: true, redirect: "https://example.com" } redirects the caller, which is useful for GET links.

The server clock is UTC. When you work with local times, use your organisation's IANA timezone (for example "Australia/Melbourne") rather than a fixed offset, so daylight saving is handled.

Permissions

An action starts with no permissions. On the Configuration tab, add permission sets that grant the roles it needs, in the scopes it should work in, just as you would for a person. Give each action only what it needs. A missing permission is the most common reason an action fails with a 403 when it runs. For how permissions are expressed, see Permission Strings Explained.

Security and the endpoint

The Security setting under Meta Data controls who can call the action's URL:

• Secure (default): only authenticated users and applications with the relevant permissions. Callers send their own access token, as shown on the Webhook tab.
• Public: anyone on the internet can call it without signing in. Use this for webhooks from outside services such as payment providers, and keep the code narrow, because anyone with the link can run it.

The Webhook tab shows the full URL and example GET and POST requests. Use GET when the action needs no input; use POST with a JSON body to send data.

Links in emails: Require confirmation

If you put an action link in an email that changes something, such as "Approve" or "Yes, I'll attend", email security scanners that open links could run it. Turn on Require confirmation on the Configuration tab. Opening the link then shows a confirmation page (you can set its title, message and button text), and the action runs only when the person presses the button.

Testing

The test panel sits under the code on the Code tab.

1. Click + and choose Blank test, or From trigger to start from a real event's data.
2. Enter the test Input as JSON. Under the options button you can set a Test email and Test phone to receive any messages the test sends.
3. Click Run Test (or press Cmd+Enter). The Output pane shows the result, and a Logs pane shows anything written with console.log.

Tests run your real code against real data, so a test that creates or sends things really does. Double-click a test tab to rename it; tests are saved with the action.

Use cases

• Webhook handlers: receive payments, sign-ups or updates from outside services.
• Custom endpoints: power a form or page on your website with your own logic.
• Data processing: validate or enrich records when they are created or updated.
• Scheduled jobs: weekly reports, clean-ups or syncs via a time trigger.
• Approval links: a link in a workflow email that moves the card to the right step.

FAQs