Run actions through Zapier, Make or n8n

Zapier, Make and n8n connect different apps so they can do work together. An omotto action sends information to a workflow you have built in one of these services—for example, to create a service request in another app. You need to configure both ends: the action in omotto and the workflow that receives it.

How it works

These are three different things:

An omotto action: a named connection to one external workflow, with defined inputs and rules for when it applies. An enabled action can be made available during customer conversations.
An omotto automation: a saved rule that runs when a chosen event happens, subject to its conditions. It can call an eligible Zapier, Make or n8n action.
The external workflow: the steps you build and run in Zapier, Make or n8n. That service connects to your other apps and carries out the work.

Creating an action does not build the external workflow. Enabling an action does not schedule it or turn it into an event rule. Instructions describe when it is relevant; they are not a guaranteed trigger for every matching sentence.

For AI-assisted construction, see connecting an agent. This is different from the Coach inside omotto.

New actions start off. The connected agent can switch them on with your permissions; it clearly warns when an action is not yet operational, recommends that you review it first and gives you a link. You can ask it to enable the action or switch it on yourself. Enabling the omotto action does not build or activate the external workflow.

A connected agent can edit an action’s receiving address or Requires approval before firing directly, with your permissions, even while it is on. Any address change removes an operator-entered secret header in the same save; a secret generated by omotto stays. The agent warns beforehand and returns the removed header’s name and a re-entry link. In the app, Save connection changes opens Remove stored secrets and save?; Cancel keeps the old address. After Save and remove secrets, the result links to re-enter the secret. Entering secrets and sending real tests still use their own in-app controls. Saving does not fire the action.

Where to find it

Open Handbook → What [assistant name] does when… to create, enable, configure or delete Custom action rules, including their usage instructions, approval, waiting and Who may fire it. Add a rule → Run a custom action creates a disabled named vendor action; + New action inside a vendor rule adds another action of the same provider.

Use its Technical setup link for the receiving address, inputs, secrets, live tests and starter blueprint. The receiving setup page is Settings → Integrations → Zapier, Make or n8n → Technical setup → Actions. For a service not yet listed, use Settings → Integrations → Add integration, choose the service and select Define actions.

Editing requires the relevant integration-management and Bot access permissions, plus Handbook editing when you use the Handbook. An integration manager with Bot access but without Handbook editing keeps the full action editor on Technical setup; other Handbook readers see behavior read-only in the Handbook. Ask your workspace owner if controls are missing.

Set it up

Required for an action: a receiving workflow in the service you choose, its public HTTPS receiving address, and an enabled omotto action with the inputs that workflow needs.

Optional or conditional: approval before firing, matching secret authentication, waiting for a response in Make or n8n, starter blueprints and live tests. Choose these for the workflow you need; you do not have to connect all three services or run a real customer action as part of setup.

Before you begin

You need an account in Zapier, Make or n8n and permission to create a workflow there. Zapier’s Webhooks by Zapier needs a paid plan, as explained below.
Decide what the workflow should do and which inputs it needs from omotto.
Use a safe destination while testing, with no real charges, customer messages or irreversible changes.
The receiving address must be public HTTPS. See the note below.

The receiving address must use HTTPS and point to a public internet address allowed by omotto’s safety checks. An address on your own computer or private network will not work, even if you can open it yourself. For a local or private n8n installation, ask its administrator to provide a suitable public HTTPS receiving address.

Create a receiving workflow in the service you chose. The service gives it an address to receive information.
In the Handbook, choose Add a rule → Run a custom action, or + New action inside an existing vendor rule.
Enter an Action name your team will recognise, such as “Create a service request”.
Click Create. The new action starts disabled.
Select the action to open its editor.
Fill in When the bot should use it. Explain the purpose and the circumstances in which this action is appropriate.
Open the rule’s Technical setup link and paste the receiving address into Webhook URL. This label means the address omotto sends the action’s information to.
Use Add parameter for each piece of information the workflow needs. A parameter is one named input, such as a request reference or an email address.
Configure the matching secret check in both services if the receiving workflow requires one.
Return to its Handbook rule and choose whether the action Requires approval before firing.
For Make or n8n, choose whether to Wait for response.
Wait for changes to finish saving and resolve any field errors.
Optional: on Technical setup, prepare the receiving workflow to accept a safe test, then click Send live test.
If you sent a test, check the received fields and the actual result in the external service.
In its Handbook rule, turn on Enabled when the action is ready for real use.

Editor changes save automatically. Creating the action is a separate Create step; there is no final Save button in this editor. A disabled action can still send a live test. Use a safe destination without real charges, customer messages or irreversible changes while testing.

If you chose Zapier

A Zap is Zapier’s name for a workflow. The Set up Zapier panel provides a checklist and an example of the information omotto sends.

Before you start: Webhooks by Zapier requires a Professional, Team or Enterprise plan. It is not available on Zapier’s Free plan.

In Zapier, choose Webhooks by Zapier as the trigger app—the step that starts the workflow.
Choose Catch Hook as its event.
Copy the receiving URL from Zapier’s Test tab into the action’s address field.
If you want a sample from omotto, send a safe live test.
If you sent that sample, use Test trigger in Zapier to find it.
Map the sample fields to the inputs of your later steps. Mapping means choosing which incoming value fills each field in the next app.
Finish the later steps and turn on the Zap.

The ordinary Catch Hook supplies the received message’s fields. If your setup needs to inspect the secret sent in a request header, Zapier documents Catch Raw Hook for access to headers and the unparsed message. Have the person building the Zap configure the secret check before any business-changing steps. Typing a secret into omotto alone does not make Zapier check it.

Zapier does not let this trigger return the result of later steps to omotto. Wait for response is therefore unavailable. See Zapier’s receiving-request guide for current requirements and setup.

Optional for Make or n8n: start from a blueprint

A blueprint is a starter file, not a finished connection. The downloads do not include your stored secret or receiving address.

Choose Download Make blueprint or Download n8n blueprint.
Import the file into your external service. In Make, use the scenario builder’s three-dot menu → Import blueprint. In n8n, use the workflow menu → Import from File.
Create and select your own receiving connection.
Replace or remove the placeholder step with the work you actually want done.
Connect your accounts in that service.
Map the received fields to the appropriate steps. In n8n, the incoming fields are inside the request’s body.
Configure receiver-side authentication to match omotto’s secret settings.
Activate or publish the workflow for ongoing use.
Put its ongoing-use receiving address into omotto.

For Make, create a Webhooks → Custom webhook receiver. If you enable Make’s API Key authentication, the matching omotto Secret header name must be x-make-apikey; enter the same secret value on both sides.

For n8n, configure the Webhook step to receive POST requests. Header auth lets you match its Name and Value to omotto’s two secret fields. n8n has separate Test URL and Production URL addresses. The test address listens when you choose Listen for Test Event; the production address is registered when you publish the workflow. Do not leave a temporary test address as the action’s ongoing destination.

If you download a response-waiting starter, its response is only a fixed “ok” acknowledgement. To return a real result, configure the response step yourself: Webhook response in Make, or Respond to Webhook in n8n. Put the relevant result into that response instead of treating the starter acknowledgement as proof of completion.

Official instructions: Make blueprints, Make receiving requests and responses, n8n importing workflows and n8n receiving requests.

Optional: check the behavior you chose

Click Send live test and check that the external service received every field you defined.
Check the actual result in the external service, not only that the test was sent.
Return to the Handbook rule and turn on Enabled only when the result is what you want.
Try it in a rehearsal, after reading how Real and Dry-run writes differ. If you want Wait for response, check that the result comes back.

Settings

Action name, availability and response

Setting	What it does	New action default
Action name	Your readable name, up to 200 characters. You can change it later.	The name you entered when creating the action.
When the bot should use it	Describes the action’s purpose and when it is relevant, up to 1,000 characters. Required before enabling.	Empty.
Webhook URL	The receiving address in the chosen external service. Required before enabling.	Empty.
Tool name	The action’s fixed identifying name. Generated once at creation; renaming the action does not change it. This is not editable.	Generated from the original name, with the service prefix.
Enabled	Makes the action available to its permitted callers. Off prevents normal execution, but not the operator’s live test.	Off for an action created in this screen.
Requires approval before firing	On means a bot-proposed execution goes through team approval before sending. Off means this action does not request that per-call approval. See team involvement.	Off.
Wait for response	For a bot call, returns the receiving workflow’s response instead of only a receipt acknowledgement. The receiver must be configured to return useful output. Available for Make and n8n, not Zapier.	Off.

Run by is a separate configuration that determines who can call the action:

assistant: available for the customer-conversation bot; this is the default.
automations: available for omotto automations, not bot-chosen calls.
both: available to both.

Who may fire it in the Handbook rule changes the Run by choice above. An action must be enabled and allow automations or both before it can be selected by an omotto automation.

Approval before a bot call is not an approval prompt for every event-driven run. An omotto automation uses the definition saved and enabled by an authorised person. Its external-action step checks delivery acknowledgement; it does not use Wait for response to turn the returned text into later-step inputs. See setting up an automation.

Parameters: every input explained

Use Add parameter to add an input and Remove parameter to remove it. There can be up to 20. All declared inputs need a value when the action runs; there is no optional-input switch.

Setting	What it does	New parameter default
Parameter name	The exact field name the receiving workflow uses. Names must be unique, start with a lowercase English letter, and use only lowercase English letters, digits and underscores. Maximum 40 characters.	Empty; fill it in.
Type	Text for words or a reference; Number for a numeric value; Phone for a phone value; Email for an email value. A Number must be sent as a numeric value, not as text.	Text.
Label	A readable explanation of the input’s name, up to 100 characters.	Empty.
Description	Further guidance about what the input should contain, up to 500 characters.	Empty.
Source	Collected in the conversation uses a supplied input. In a bot call, it comes from the conversation; in an automation, you bind the input in that rule. Verified customer identity uses an already verified customer phone or email.	Collected in the conversation.

When a Shopify order automation calls this action, its mapped inputs can include order and item details, separate shipping and billing addresses, buyer name and tracking. For a Text input, choose an amount with currency; use a numeric money projection for a Number input. These store values do not count as verified customer identity.

Verified customer identity is allowed only with Phone or Email, not Text or Number. Choosing a phone or email type on its own does not verify that value. If the required verified value is missing, the action does not send; see verification.

Do not name an input action or conversation_url, or start its name with _omotto. Those names are reserved. If you change an input name, update the field mapping in the receiving workflow too.

Secret header settings

A secret header is a private check sent alongside the action’s information. The receiving service must compare it with the value you configured there. The fields are optional as a pair; if you use them, both must be filled.

Setting	What it does	New action default
Secret header name	The receiving service’s expected name for the secret check.	Empty.
Secret header value	The private value that must match the receiver. Saved values are not displayed again; Configured indicates one is stored. Leaving the replacement field empty keeps an existing stored value.	Empty.
Clear stored secret	Removes the stored name and value. This does not update the receiving workflow for you.	Available once a secret is stored.

Removing the stored header name also clears the pair. When replacing a secret, update both sides and test again. Keep the receiving address and secret private; do not put them into customer messages or share them in screenshots.

What to configure next

Choose only the options that fit what you want this feature to do.

Refine When the bot should use it so the bot uses it only in the right situations.
Decide whether it Requires approval before firing.
Match the secret on both sides before any step that changes business data.
Use automations if it should run on a rule, then go live.

What happens when…

The external service receives an action

It receives the declared input fields and an action identifier. A bot call also includes a link back to its conversation when available. The standard action does not automatically send the complete conversation history. Calls from omotto automations do not automatically include that bot-conversation link.

Decide which customer information you actually need to send before adding fields. Access to the linked conversation still depends on omotto permissions.

A connected agent tests the action

A connected agent with change access can send a live test directly, even when the action is off. This really contacts your receiving workflow. Give it safe sample inputs and check the external system for real effects. Both app and agent tests store the latest outcome, response status, time and who requested it. The agent can read those facts back, but receives no response body or sample payload from the test result.

You click Send live test

This is not a dry run. It sends sample values to the configured receiving address, including sample identity values and an example conversation link—not a real customer conversation. It can run even while Enabled is off, and it does not ask for the bot’s team approval first.

The receiver may perform real work with those samples. Check its run history and the destination app. A successful test checks the connection and field mapping; it does not prove real customer verification, bot choice or team approval will succeed.

The automation preview is different: it checks how a rule matches recorded events without sending the external action.

The test succeeds but the work is not done

Receipt is not completion. Zapier cannot return later-step output through its receiving trigger. Make’s default response is also immediate acceptance, and the supplied response-waiting starters return only a fixed acknowledgement.

Check the external run’s later steps and actual destination. With Make or n8n, Wait for response is useful only when the receiving workflow sends a meaningful result back during the request.

The response is slow or too large

For Wait for response, configure the receiving workflow to return a prompt, concise result. omotto uses a 15-second read timeout while waiting for response data. This is not a guaranteed total deadline for the external workflow.

omotto passes back at most 4,000 bytes of returned text, not 4,000 characters. Longer text is shortened. If the response body exceeds 64 KiB (65,536 bytes), omotto omits the entire body instead. A successful receipt acknowledgement can remain even when the output is omitted.

Missing or shortened output does not prove that the external work failed. Check the external run and its destination before retrying, especially if it sends messages, creates records or takes payments.

The action changes while approval is pending

An old approval is not permission to run a different action. Relevant configuration or verified-identity changes can invalidate a pending approval. Disabling or deleting the action also prevents the old proposal from executing. Review the new proposal rather than repeatedly approving the old one.

You delete an action

In the Handbook rule, Delete action asks for confirmation and cannot be undone. It does not undo work already performed in another app or delete the external workflow. Check any omotto automations that depended on this action before deleting it.

Troubleshooting

Cannot enable the action: fill in the usage instructions and receiving address. Complete every parameter’s name, type and source; correct the inline error before retrying. An unsafe or unreachable destination can be refused.
Send live test is unavailable: wait for automatic saving to finish and fix any save errors. The button stays unavailable while the editor has unsaved or failed changes.
Authentication fails: check the header name and secret on both sides. For Make’s built-in key check, use x-make-apikey. For n8n, select matching Header auth. A stored secret in omotto does not automatically configure the receiver.
n8n does not receive the call: check whether you pasted the test or production address, and whether its workflow is listening or published.
An input is missing or rejected: compare parameter names with the receiving field mapping. Check Number values and whether identity-sourced inputs have a verified customer value. A live test’s sample identity is not proof that a real customer has been verified.
The action is missing from an automation: check Enabled and the separate Run by configuration described above, as well as your integration permissions.
A timeout or uncertain result appears: inspect the external run and destination before sending again. A lost response can happen after the other system has already performed the work. Do not repeat a payment, message or record creation just to get a clearer result.

If the problem persists, contact support with the service name, action name, time of the attempt and the visible error. Remove secrets and receiving addresses from screenshots.