Omnisend node reference - all 41 operations, the credential it needs, and a worked example.
Omnisend (Email Marketing). 41 v3 REST operations: contacts (create/sync, get, list, update) with per-channel marketing consent, address and custom properties; custom events (trigger by system name, trigger a defined event by id, list and get definitions); campaigns (list, get); the product catalog and its categories (list, get, create, replace, delete); carts and cart line items, which drive abandoned-cart automations; orders (list, get, create, replace, update status and tracking, delete); and batches for bulk-syncing up to 1000 records in one asynchronous call.
Credential: Omnisend API key - see Credentials.
Each operation below lists the API key permission it needs. API key permissions are ticked when you create the API key, per store, under Store Settings -> Integrations & API -> API keys. Omnisend has no OAuth and no per-operation scopes, but a key is NOT all-access: the creation screen carries one checkbox per RESOURCE - Campaigns, Contacts, Orders, Products, Carts and Events - under the heading "Permissions control which Omnisend data the API key can access", and the v3 spec leans on the same model where it says "You can list batches with endpoint for which API Key has permission". So the grants below are per resource rather than per operation: Omnisend documents no read/write split, which is why getProduct and deleteProduct both read Products, and why Categories - the catalog's taxonomy, with no permission of its own - sits under Products. The batch operations state a rule instead of a token because a batch's permission is whichever resource its endpoint names. Two things a refusal usually is NOT: a 429 is the rate limit rather than a permission (400 requests per 60 seconds per brand, and just 1 request per second on the two Campaigns reads), and a 404 on an order is usually Omnisend's answer for an order that was synced automatically from Shopify, BigCommerce or WooCommerce - the v3 Orders API only returns orders created through it. If a run fails with a permission error, the node names the missing API key permission in the error - grant it and re-run; you do not need to rebuild the workflow.
| Operation | What it does | API key permission |
|---|
upsertContact | Create / sync contact | Contacts |
getContact | Get contact | Contacts |
listContacts | List contacts | Contacts |
updateContact | Update contact | Contacts |
| Operation | What it does | API key permission |
|---|
triggerEvent | Trigger custom event | Events |
triggerExistingEvent | Trigger a defined event by ID | Events |
listEvents | List custom event definitions | Events |
getEvent | Get custom event definition | Events |
| Operation | What it does | API key permission |
|---|
listCampaigns | List campaigns | Campaigns |
getCampaign | Get campaign | Campaigns |
| Operation | What it does | API key permission |
|---|
listProducts | List products | Products |
getProduct | Get product | Products |
createProduct | Create product | Products |
replaceProduct | Replace product | Products |
deleteProduct | Delete product | Products |
| Operation | What it does | API key permission |
|---|
listCategories | List categories | Products |
getCategory | Get category | Products |
createCategory | Create category | Products |
replaceCategory | Replace category | Products |
deleteCategory | Delete category | Products |
| Operation | What it does | API key permission |
|---|
listCarts | List carts | Carts |
getCart | Get cart | Carts |
createCart | Create cart | Carts |
replaceCart | Replace cart | Carts |
updateCart | Update cart | Carts |
deleteCart | Delete cart | Carts |
addCartProduct | Add product to cart | Carts |
replaceCartProduct | Replace a cart line item | Carts |
updateCartProduct | Update a cart line item | Carts |
removeCartProduct | Remove a cart line item | Carts |
| Operation | What it does | API key permission |
|---|
listOrders | List orders | Orders |
getOrder | Get order | Orders |
createOrder | Create order | Orders |
replaceOrder | Replace order | Orders |
updateOrder | Update order status / tracking | Orders |
deleteOrder | Delete order | Orders |
| Operation | What it does | API key permission |
|---|
createBatch | Create batch | (the permission for the resource the batch targets — Contacts, Orders, Products, Events or Categories, whichever the Target resource field names) |
listBatches | List batches | (the permission for the resource named in the Target resource field — Omnisend only lists batches for endpoints the key may read) |
getBatch | Get batch status | (the permission for the resource the batch targeted — Omnisend only returns a batch whose endpoint the key may read) |
listBatchItems | List batch items | (the permission for the resource the batch targeted — Omnisend only returns a batch whose endpoint the key may read) |
getBatchItem | Get batch item | (the permission for the resource the batch targeted — Omnisend only returns a batch whose endpoint the key may read) |
Subscribe a contact so Omnisend may actually email them
The field that matters here is emailStatus, not the address. Omnisend addresses contacts by an identifiers array whose channel status is what grants permission to send — a contact created without it is stored and then never emailed, which looks like the integration silently doing nothing. The node builds that structure from the plain email field, so this stays a one-field form.
Set Operation to upsertContact, then fill in:
| Field | Value | Notes |
|---|
email | {{ myTrigger.email }} | The node wraps this into Omnisend's identifiers array for you |
emailStatus | subscribed | The permission flag. Without it Omnisend stores the contact and never sends to it |
firstName | {{ myTrigger.firstName }} | |
lastName | {{ myTrigger.lastName }} | |
tags | newsletter | Comma-separated |
Sets {{contact.contactID}} — the original field name, preserved from before the operation wave, so saved workflows reading it keep resolving.