Integrationen · Aktualisiert 6. April 2026 · ~8–12 Min

Make Integrationen (2026)

In Make bedeutet „Integration“ nicht nur „App verbinden“. In der Praxis hast du vier Bausteine:

• Native App-Module (z. B. Shopify, Stripe, Google Sheets)
• Webhooks (Echtzeit-Trigger bei Events)
• HTTP (jede API anbinden, auch ohne native Module)
• Custom Apps (wiederverwendbarer Connector mit Auth + Endpoints)

Dieses Guide hilft dir, den richtigen Ansatz zu wählen – und typische Fehler zu vermeiden, die später Duplicates, Ausfälle oder unnötige Operations verursachen.

1) Connector wählen (native App vs Webhook vs HTTP)

Ein pragmatisches Entscheidungsmodell:

• Native App, wenn sie den Endpoint abdeckt, den du brauchst.
• Webhook, wenn du Events in Echtzeit brauchst (Bestellung, Zahlung, Formular).
• HTTP, wenn du ein API-Feature brauchst, das der native Connector nicht anbietet.
• Custom App, wenn du dieselbe API wieder und wieder nutzt (und Auth sauber kapseln willst).

Wenn du unsicher bist: Starte nativ. Für Edge-Cases baust du ein „Escape Hatch“ mit HTTP.

2) Stacks mit hohem ROI (bewährte Kombinationen)

Ein paar Muster, die in der Praxis gut skalieren:

• E-Commerce: Shopify/WooCommerce → Stripe → Sheets/Airtable → Slack/Email
• Lead Gen: Webhook (Form) → CRM (HubSpot/Pipedrive) → Enrichment → Routing/Alerts
• Finance/Ops: Rechnungen → Drive/Storage → Sheets/ERP → Alerts + Archiv
• Support: Email/Ticket → KI-Klassifizierung → Routing → SLA-Alerts
• Content: Notion/Airtable → KI-Module → CMS → Social/Newsletter

Wichtig: Definiere pro Stack eine Source of Truth (z. B. Order-ID, Customer-ID). Ohne stabile IDs sind Duplicates fast garantiert.

3) Auth & Rechte (Sicherheit + DSGVO/Compliance)

Viele „Integrationsprobleme“ sind eigentlich Berechtigungsprobleme:

• Nutze, wenn möglich, dedizierte Service-Accounts statt persönlicher Logins.
• Vergib Rechte nach dem Prinzip Least Privilege (nur lesen/schreiben, was nötig ist).
• Plane Key-Rotation (API Keys/Secrets regelmäßig erneuern).
• Halte fest, welche Systeme PII (personenbezogene Daten) enthalten.

Für EU-Setups (DSGVO) lohnt sich ein Mini-Check:

• Datenminimierung (nur Felder übertragen, die du wirklich brauchst)
• Logging/Run-History ohne sensible Inhalte (keine Passwörter, Tokens, unnötige PII)
• Prüfe je Tool, ob ein AVV/DPA verfügbar ist und wer Datenverarbeiter ist

4) Typische Fallen (und wie du sie vermeidest)

• Duplicates: Idempotenz-Key (z. B. Order-ID) + Dedupe über Data Store/Unique Keys.
• Pagination: immer „next page“ sauber implementieren; sonst fehlen Daten oder du loopst endlos.
• Rate Limits: Requests drosseln, batchen, Caches nutzen.
• Unbounded Trigger: Polling ohne Filter (z. B. „Watch all“) frisst Operations.
• Silent Failures: Error Handler + Alerts (Slack/Email) + Dead-letter-Strategie für problematische Items.

Wenn du Produktions-Workflows baust: plane Fehlerpfade explizit. „Happy Path only“ ist die häufigste Ursache für spätere Notfälle.

5) Kosten & Operations (was wirklich zählt)

In Make hängen Kosten stark an Operations:

• viele Module pro Run = mehr Operations,
• Loops multiplizieren Steps,
• Retries und Fehlerpfade erhöhen Verbrauch zusätzlich,
• Polling kann „leere Runs“ erzeugen, die trotzdem zählen.

Quick Wins:

• früh filtern (vor Routern/Loops),
• batchen (erst sammeln, dann einmal schreiben),
• deduplizieren (Data Store / Unique Keys),
• Polling-Intervalle nur so eng wie nötig.

6) Produktions-Checkliste

• Stabile IDs + Dedupe-Strategie (Data Store/Unique Key)
• Pagination + Backoff bei APIs
• Error Handler + Alerting + Wiederanlauf (Retries mit Grenzen)
• Operatives Budget: geschätzte Operations/Monat + Sicherheitsmarge
• Dokumentation: welche Felder übertragen werden und warum (Compliance)

Wenn du den schnellsten Start willst: baue zuerst einen Webhook-basierten Flow und beobachte 7 Tage lang Runs/Fehler/Operations.