# Connect Moxo AI to Atlas Labs

> To receive Atlas Labs events in Moxo AI (app.moxo.com), give a flow template a **Webhook** trigger with the **None (secret URL)** option, publish it, subscribe the copied URL with `POST /webhooks`, then map the fields, add a condition on `type` and re-send the ping with `POST /webhooks/{id}/test`. We tested this on `19 Oct 2026`: each `office.sales_order.received` event from a fictional sandbox started a flow in Moxo. Moxo's Webhook step cannot send the Atlas Labs key, so calls the other way go through a Make, n8n or Zapier webhook that adds it.

Canonical: `https://automationatlas.io/labs/docs/tools/moxo/` · Checked: `2026-10-19`

Atlas Labs is a fictional company's API; every figure in every response is simulation data.

> **Tested with Moxo AI on `19 Oct 2026`.** We built the template below in a Moxo AI workspace (app.moxo.com) and subscribed its webhook URL to a fictional Atlas Labs sandbox. Moxo answered each `office.sales_order.received` delivery with `201`, and each started a flow with a To-Do waiting for the reviewer. Moxo also runs an older product, Moxo Classic; this page is about Moxo AI.

*Reference table — Atlas Labs API fields and the Moxo AI labels used in the test on `19 Oct 2026`, not part of the fictional simulation.*

| At a glance | Value |
| --- | --- |
| Atlas Labs → Moxo | Flow templates → your template → Trigger → **Customize** → **Webhook** → **Add** → **None (secret URL)** |
| Field mapping | Required. Without it Moxo answers `400 VALIDATION_ERROR` (“Unrecognized keys”) to the Atlas Labs body. Flow name = `Atlas Labs sales order ` + **Data / Sales Order Id**, Description = **Links / Self** |
| Filter | **Conditions** → **Match all of the following** → Property `type`, Operator **is**, Value `office.sales_order.received`, so the `webhook.test` ping is answered `200` and skipped |
| Moxo → Atlas Labs | Moxo's **Webhook** step → a webhook trigger in Make, n8n or Zapier → that tool calls Atlas Labs with the key |
| Where the key goes | In the Make, n8n or Zapier step that calls Atlas Labs: `Authorization: Bearer lab_off_YOUR_KEY`. The key never enters Moxo, and never goes in a URL (Atlas Labs rejects and revokes a key it finds in a URL). |
| Atlas Labs delivery | Public HTTPS on port `443`; a `2xx` answer from Moxo counts as delivered. The webhook URL's host is `api.moxo.com`. |

> **Start a sandbox and your keys are filled in for you.** This page uses `lab_off_YOUR_KEY`. After you [start a sandbox](https://automationatlas.io/labs/#start-sandbox-heading), the “Connect it” panel shows the same values with your real keys.

- Atlas Labs → Moxo AI: signed webhook, secret URL, no Moxo auth header
- Moxo AI → Make, n8n or Zapier: Webhook step, Moxo envelope

Atlas Labs reaches Moxo directly. For calls back into Atlas Labs, Moxo's Webhook step posts to the third tool, which then calls Atlas Labs with the `Authorization: Bearer` key. The key never enters Moxo.

## How do I start a Moxo flow from an Atlas Labs event?

1. **Create the template.** In Moxo AI open **Flow templates** → **+ Create template**. The builder opens as “Untitled template”; click the name and type `Atlas Labs test: sales order received`.
2. **Add a role.** Under **Human roles** click **+ Add role**, type `Reviewer` and press Enter. Click the role chip → **Who fills this role** → **Person** → **Search people** and pick yourself. The chip then reads “Fixed: [your name]”.
3. **Add a To-Do.** On the canvas click **+** → **To-Do**. Set Name to `Review new Atlas Labs sales order` and Assignees to `Reviewer`, then **Save**.
4. **Open the trigger settings.** On the Trigger card click **Customize >**. The “Flow start configuration” panel lists Manual start, Start link, **Webhook** (“Triggered by an external system via API”) and Connected app. Click **Add** beside Webhook.
5. **Choose the verification.** In the **Webhook** dialog, under “How we verify each request”, choose **None (secret URL)**. The dialog says the URL contains a secret token and no additional authentication headers are required. That suits Atlas Labs, which sends a fixed Standard Webhooks request and cannot add Moxo headers. The **Signature** option expects an `X-Moxo-Signature` header that Atlas Labs does not produce.
6. **Copy the URL.** Click **Your webhook URL** → **Copy webhook URL**. It has the form `https://api.moxo.com/v1/webhooks/incoming/<templateId>/<token>`. Treat it like a password: anyone holding it can start flows from this template.
7. **Save and publish.** Click **Save**, then **Publish**. The banner reads “[template name] is live! Anyone can now start flows from it.” The URL answered as soon as the template was published. Manual start stays on beside Webhook.
8. **Subscribe the URL in Atlas Labs.** Subscribing sends a verification ping at once. With no mapping saved yet, Moxo answers it with `400`, and the subscription shows `verification_failed`. That is expected here: Moxo keeps the rejected body as the sample for the next step.
   Either sandbox key works. Save the `secret` from the response; it is shown once. In Moxo, the Webhook dialog's **Delivery log** shows the failed ping as “Failed”, `VALIDATION_ERROR`.
   *curl · Subscribe the Moxo URL · run against the live API on `19 Oct 2026`*

   ```bash
   curl -sS -X POST https://automationatlas.io/labs/api/v1/webhooks \
     -H "Authorization: Bearer lab_off_YOUR_KEY" \
     -H "Content-Type: application/json" \
     -d '{"url": "https://api.moxo.com/v1/webhooks/incoming/<templateId>/<token>",
          "events": ["office.sales_order.received"]}'
   ```
9. **Set up the field mapping.** Reopen the **Webhook** dialog (Flow templates → your template → **Edit** → Trigger **Customize**), then **Field mapping** → **Set up mapping**. In “Webhook field mapping” the sample request options are **Use generated sample**, **Paste your own** and **Capture live**. Moxo had already loaded the Atlas Labs body it rejected (“`11` fields found”), so you can pick fields straight away. Fill the Moxo fields, mixing typed text with fields from the **+** picker:
   - Flow name: `Atlas Labs sales order ` + **Data / Sales Order Id**
   - Description: **Links / Self**
   - Due date: left empty
   **Use literal text plus one field.** The wizard drops a typed space between two field tokens, so a name built from **Id** and **Type** came out as one run-together word. Click **Validate mapping** (“It looks good. Here is what Moxo would create.”; it does not start a flow), then **Save mapping**. The dialog then shows “Field mapping: Detected JSON webhook”.
10. **Add a condition.** Open **Conditions** (“Checks raw incoming payload paths before mapping”) → **Match all of the following** → **+ Condition**. Set Property `type` (pick it from the sample), Operator **is**, Value `office.sales_order.received`. The row shows “Passes” and the section “Saved”. Without it, the `webhook.test` ping would start a flow of its own.
11. **Send the ping again.** The mapping is saved now, so Moxo accepts the body. Re-send the ping and read the answer.
   The test call returns `202` (queued); Moxo's answer is the `status_code` in the deliveries list. With the condition in place Moxo answers the ping `200` and logs it “Skipped”, and any `2xx` turns the subscription `active`.
   *curl · Re-send the ping, read the deliveries · run against the live API on `19 Oct 2026`*

   ```bash
   curl -sS -X POST https://automationatlas.io/labs/api/v1/webhooks/WEBHOOK_ID/test \
     -H "Authorization: Bearer lab_off_YOUR_KEY"

   curl -sS https://automationatlas.io/labs/api/v1/webhooks/WEBHOOK_ID/deliveries \
     -H "Authorization: Bearer lab_off_YOUR_KEY"
   ```
12. **Check the result in Moxo.** Moxo answered each `office.sales_order.received` delivery with `201`. The template page lists the new flows under Recent Flows as “In Progress”. A flow shows a “Flow start” node with a **Webhook** chip and the To-Do “Review new Atlas Labs sales order”, waiting for the reviewer with an **Act** button. In the **Delivery log** (filters All, Failed, Skipped, Succeeded) each entry reads “Succeeded”, then “Created flow [flow id]”, then the Atlas Labs JSON.

## How do I call Atlas Labs from Moxo?

Atlas Labs needs an `Authorization: Bearer` header holding one of the two sandbox keys (`lab_fac_` for `/factory/*`, `lab_off_` for `/office/*`). Moxo AI's **Webhook** automation step (added from the canvas **+** under Automations) has fields for Name, URL, “Include data from step”, Context and two toggles, and no method, header, authentication or body fields. It POSTs Moxo's standard event envelope, plus any Context key and value pairs you add. Moxo's own tooltip on the URL field points to the REST API step “if you need a different HTTP method, custom headers, or a custom body shape”, and that step was not available on the plan used for this guide. So the Webhook step cannot carry the key, and a key placed in a URL is rejected and revoked.

1. **Create a webhook trigger in Make, n8n or Zapier.** Make: a Custom webhook. n8n: a Webhook node. Zapier: Webhooks by Zapier → **Catch Raw Hook**. Copy its URL. The Atlas Labs half of each is on the [Make](https://automationatlas.io/labs/docs/tools/make/), [n8n](https://automationatlas.io/labs/docs/tools/n8n/) and [Zapier](https://automationatlas.io/labs/docs/tools/zapier/) pages.
2. **Add the Moxo step.** In a Moxo flow template click **+** → **Automations** → **Webhook**. Paste the URL into **URL**. Under **Context** click **+ Add field** and add the values the Atlas Labs call needs; Moxo sends them in the webhook payload, and their values can reference earlier steps. Leave **Block the workflow if this step fails** on (the default) if the flow should halt when Moxo cannot reach the hook.
3. **Call Atlas Labs from the middle tool.** Add an HTTP step that sets `Authorization: Bearer lab_off_YOUR_KEY` (or `lab_fac_YOUR_KEY` for Factory routes) and `Content-Type: application/json`. On a write, set an `Idempotency-Key` that is stable per Moxo event, the same on any retry. The key stays in that tool and never enters Moxo.

[Moxo's API reference](https://api.moxo.com/docs) also documents per-template outgoing webhooks, with events such as `flow.started`, `step.completed` and `flow.completed`, an `X-Webhook-Signature` header and a Moxo event envelope as the body. The URL they post to can be the Make, n8n or Zapier hook from the first step above.

## Common errors

*Reference table — what Moxo AI and Atlas Labs returned in the `19 Oct 2026` test, not part of the fictional simulation.*

| You see | Why, and the fix |
| --- | --- |
| Moxo's Delivery log shows Failed, VALIDATION_ERROR, Unrecognized keys: "id", "type", "created_at", "sim_date", "sandbox_id", "system", "simulation", "data", "links"; Atlas Labs' `/deliveries` shows `status_code` `400` | No field mapping is saved. Without one, Moxo accepts only its own body (`name`, `description`, `dueAt`, `roleAssignments`, `fieldValues`). Open Webhook → **Field mapping** → **Set up mapping**, map Flow name and Description, then send `POST /webhooks/{id}/test` again. |
| Subscription `verification_failed`, `last_error_class` `http_4xx` | The same cause: the verification ping reached Moxo before the mapping existed. Save the mapping and the condition, then `POST /webhooks/{id}/test`; a `2xx` answer turns the subscription `active`. |
| Flow named `evt_…office.sales_order.received`, no space | The wizard dropped a typed space between two field tokens. Use literal text plus one field: `Atlas Labs sales order ` + **Data / Sales Order Id**. |
| A flow started by the `webhook.test` ping | No condition. Add Property `type`, Operator **is**, Value `office.sales_order.received`; the ping is then answered `200` and logged “Skipped”. |
| `403 wrong_system` | On the Make, n8n or Zapier call: the wrong key for the route. `/factory/*` wants `lab_fac_`, `/office/*` wants `lab_off_`. |

## Gotchas

- **Moxo AI, not Moxo Classic.** The steps here are for app.moxo.com and were written in Moxo AI. Moxo Classic (getstarted.moxo.com) is a separate product.
- **The URL is the secret.** With **None (secret URL)**, the token in the path is the only protection. Do not paste the URL into chats or screenshots, and delete the subscription when you are done (`DELETE /webhooks/{id}`).
- **Published templates only.** Moxo's API reference says the webhook starts flows from a published template. In the test, the URL answered as soon as the template was published.

## Questions people ask

**Can Atlas Labs call Moxo directly?** Yes, for Moxo AI. A template with a **Webhook** trigger set to **None (secret URL)** and a saved field mapping accepted the Atlas Labs events in our `19 Oct 2026` test, answering `201`. The other two options, **Signature** and **API key**, need headers (`X-Moxo-Signature`, and `X-API-Key` in Moxo's API reference) that Atlas Labs does not send.

**Can Moxo call Atlas Labs directly?** Not with Moxo AI's Webhook step: it has no header or method settings, so it cannot send the `Authorization: Bearer` key, and the REST API step was not available on the plan used for this guide. Send from Moxo to a Make, n8n or Zapier webhook and let that tool call Atlas Labs.

**Why does Moxo reject the first ping?** Subscribing sends a verification ping at once. Without a saved field mapping Moxo rejects the Atlas Labs body with `VALIDATION_ERROR`. Save the mapping, then send `POST /webhooks/{id}/test`.

**Does Zapier's Moxo app work with Moxo AI?** No. The app (zapier.com/apps/moxo) is for Moxo Classic, the former Moxtra product, and uses its workspace, binder and transaction objects, and its listing points to the Moxtra-based app. Moxo AI users should use the routes above.

Sources (checked `19 Oct 2026`): the Moxo AI interface at app.moxo.com, tested on `19 Oct 2026` against a fictional Atlas Labs sandbox; Moxo's API reference at api.moxo.com/docs; zapier.com/apps/moxo. Atlas Labs facts from the API source, observed live.

[Power Automate](https://automationatlas.io/labs/docs/tools/power-automate/) · [Frends](https://automationatlas.io/labs/docs/tools/frends/)