Integrating Magento 2 REST APIs with n8n
Why I finally wrote this down
A teammate wiring n8n HTTP nodes asked where Magento REST authentication comes from. The endpoint URL made sense; the validation headers did not. That gap is common: Magento admin UI hides integration keys behind OAuth terminology, and n8n's generic HTTP node does not magically know your store code.
This post is the distilled answer I sent in chat, cleaned up for anyone connecting n8n to Magento 2 REST without treating OAuth like a black box.
Why not only PHP cron
Magento cron is fine for batch jobs inside the application boundary. n8n earns its place at the edges:
Retries and manual replay from a UI.
Branching on HTTP status without redeploying PHP.
Quick workflow edits when marketing changes a sync mapping.
Visible execution history for ops, not just
cron.loglines.
I reach for n8n when the work crosses systems (PIM, ESP, spreadsheet, chat) or when non-developers need to pause and resume flows.
Auth shapes you will see
Pick the token model by the workflow's role:
Integration access token: Server-to-server automations. Create under System → Integrations. Use the access token as a Bearer credential.
Admin/customer tokens: When the workflow must act as a specific user (rare in n8n; prefer integration scope).
Full OAuth: Required on some hardened installs. Avoid for batch automation unless security policy demands it.
Modern integrations expose four OAuth-related keys. For n8n you usually want the access token with an Authorization header shaped like Bearer <token> (no extra colon).
Standalone bearer tokens may be disabled. Check Stores → Configuration → Services → OAuth → Allow OAuth access tokens as standalone Bearer tokens. If that is off, automation either enables it (with security sign-off) or implements the full OAuth handshake. The handshake is painful in long-running workflows.
Store code in the URL matters
Magento REST URLs follow:
https://example.com/rest/<store_code>/V1/<endpoint>Use all or default for many admin operations. Product searches and store-scoped catalog reads need the correct store code or results look empty while auth succeeds.
Async and bulk variants exist:
/rest/<store_code>/async/V1/...
/rest/<store_code>/async/bulk/V1/...Bulk endpoints had rough edges in 2.4.4/2.4.5 for some payloads. When bulk misbehaves, fan out async single calls and compare results before blaming n8n.
n8n node layout
Token node: HTTP Request to your token route if you fetch dynamically, or store a long-lived integration token in n8n credentials.
Credential helper: Prefer Header Auth / Magento 2 API credential type so tokens are obfuscated in the UI.
Downstream nodes: Reference the credential; send JSON bodies with
Content-Type: application/json.401 branch: Re-auth or fail loudly. Silent failure produces partial catalog syncs.
Fastest debug path: get the call working in Postman or Swagger, export cURL, import into n8n's HTTP node, then remove the inline Authorization header and attach the credential instead.
Operational guardrails
Log SKU, order increment IDs, or request IDs in execution history, not raw PII.
Rate-limit burst workflows against catalog endpoints.
Version-control workflow JSON for critical syncs; treat changes like code review.
Alert on consecutive failures; n8n retries can amplify load on a struggling Magento node.
When to stop using n8n
Transactional work that must share Magento's DB boundary belongs in a module or message queue consumer: inventory reservations, checkout, payment capture. Keep n8n at the edges for sync, notification, and transformation. If a workflow needs two-phase commit semantics across Magento and another database, that is a sign to move inward.
Quick review before production sync
Is standalone bearer allowed, or do I need OAuth?
Does the store code in the URL match the catalog scope I expect?
Are credentials in n8n, not hard-coded in node headers?
Did I test with Postman/cURL first?
What happens on 401 after token expiry?