# Automations vs. creating an order (/automations-vs-creating-an-order)



LettrLabs gives you two ways to put mail in motion. They are not competitors —
they sit at different points on the "how much do I want to run myself" scale.

## The two paths [#the-two-paths]

* **Create an order (API)** — you call [`POST /v1/order`](/api-reference/orders/v1-order-post)
  yourself, attach recipients, and check out. You own the trigger, the timing,
  and the recipient list. Fully programmatic, one order at a time. See
  [Creating an Order](/creating-an-order).
* **Automations (app)** — you configure a rule in the LettrLabs app
  ([Automations](https://app.lettrlabs.com/automations)) that places orders for
  you when something happens (a CRM event, a list import, a proximity trigger).
  The matching API surface is the **Automations** group
  (`/v1/integration-orders`, see the [API Reference](/api-reference)), used to
  feed and inspect those integration‑driven orders.

## Which should I use? [#which-should-i-use]

| Use **Create an Order** when…               | Use **Automations** when…                              |
| ------------------------------------------- | ------------------------------------------------------ |
| Your own system decides when to mail        | A recurring or event‑driven rule should mail for you   |
| You want full control of each order in code | You want the app to manage the trigger and cadence     |
| One‑off or batch sends on your schedule     | Ongoing campaigns tied to CRM / list / location events |

## Rule of thumb [#rule-of-thumb]

If you can answer *"my code decides exactly when and to whom"*, create orders
directly. If you'd rather *"set it up once and let an event drive it"*, use
Automations. Many integrations use both — Automations for the steady‑state flow,
direct order creation for the exceptions.