
Shopify Custom-Automatisierung: Wann Plugins versagen
Wann stoßen Shopify-Apps und Flow an ihre Grenzen? Ich zeige 8 kritische Prozesse, die nur Custom-Code löst — mit echten Zahlen, API-Beispielen und ROI-Kalkulation für 2026.
Mittelgroße Shopify-Shops verlieren laut einer Bitvea-Analyse durchschnittlich 40 % ihrer Betriebszeit an repetitive Aufgaben, die längst automatisiert sein könnten. Zehn installierte Apps, drei Zapier-Zaps, Shopify Flow bis zum Anschlag ausgebaut — und trotzdem sitzt jemand jeden Morgen zwei Stunden vor Excel und tippt Bestandsdaten ab.
Das Problem liegt nicht bei den Tools. Es liegt daran, dass Standard-Plugins für Standard-Probleme gebaut werden. Sobald Ihr Shop komplexe Lagerlogik, ERP-Anbindungen oder unternehmensweite Preisregeln hat, reichen vorgefertigte Lösungen strukturell nicht mehr aus.
In diesem Artikel zeige ich Ihnen acht konkrete Prozesse, bei denen ich in Kundenprojekten auf genau diese Wand gestoßen bin — und wie Custom-Automatisierung diese Lücken schließt. Mit aktuellem Code, echten ROI-Zahlen und einer klaren Entscheidungshilfe, wann sich der Aufwand lohnt.
Das Wichtigste in Kürze
- 40 % der Betriebszeit gehen in Shopify-Shops durchschnittlich an manuelle, automatisierbare Aufgaben verloren.
- Standard-Apps haben drei strukturelle Limits: One-size-fits-all-Logik, geteilte API-Kontingente und kein System-übergreifendes Denken.
- Plugin-Stacking ab 4–5 zusammenhängenden Apps kostet oft mehr als eine Custom-Lösung — und bleibt trotzdem lückenhaft.
- Shopify Flow nutzt seit Januar 2026 die GraphQL Admin API 2026-01 mit erweiterten Metafield-Abfragen und Bulk-Mutations.
- Custom-Automatisierung amortisiert sich bei 300 €+/Monat laufenden App-Kosten typischerweise in 12–18 Monaten.
- Acht Prozesse in diesem Artikel — von Multi-Warehouse-Sync bis Compliance-Prüfung — lassen sich nur mit eigenem Code zuverlässig lösen.
Warum Standard-Plugins strukturell scheitern
Bevor wir in die konkreten Prozesse einsteigen, lohnt sich ein kurzer Blick auf die Wurzel des Problems — denn das ist kein Qualitätsproblem einzelner Apps.
Die drei fundamentalen Limitierungen
| Limitierung | Technische Ursache | Konsequenz |
|---|---|---|
| One-size-fits-all | Apps müssen für Tausende Shops funktionieren | Ihre spezifische Businesslogik passt nicht rein |
| Geteilte API-Kontingente | Jede installierte App verbraucht Ihr Shopify-API-Budget | Bei vielen Apps: Race-Conditions und Sync-Fehler |
| Shopify-only-Denken | Plugins kennen nur Shopify-Daten | ERP, PIM, WMS, CRM bleiben außen vor |
Die versteckten Kosten des Plugin-Stacking
Ein typischer Stack, den ich bei Bestandskunden sehe:
Bestandsmanagement-App: 49 $/Monat
Pricing-App: 79 $/Monat
Fulfillment-App: 39 $/Monat
B2B-App: 99 $/Monat
Returns-App: 59 $/Monat
Sync-App: 29 $/Monat
─────────────────────────────────────
Gesamt: 354 $/Monat = 4.248 $/JahrFast 4.300 $ pro Jahr — und trotzdem bleiben Lücken, weil jede App ihr eigenes Datenmodell mitbringt. Wenn dann zwei Apps denselben Webhook abfangen, beginnt das Chaos.
Prozess 1: Multi-Warehouse-Bestandsabgleich mit verschiedenen ERP-Systemen
Das Problem
Sie betreiben drei Lager: Deutschland (SAP), Polen (eigenes WMS), Dropshipper (CSV per SFTP). Jedes System hat andere Update-Zyklen, andere Protokolle, andere Datenformate. Overstock in einem Lager, während ein anderes Stockout meldet.
Warum Apps scheitern
Standard-Inventory-Apps wie Stocky oder Katana unterstützen eine Datenquelle. Multi-ERP-Setups mit REST, SOAP und SFTP parallel kennen sie nicht. Auch Priorisierungslogik — welches Lager bei Bestelleingang zuerst bedient wird — ist nicht vorgesehen.
Die Custom-Lösung
// Zentraler Bestandsabgleich — läuft alle 15 Minuten via Cron
async function syncInventoryFromAllSources() {
const [sapStock, wmsStock, dropshipStock] = await Promise.all([
fetchSAPInventory({ warehouse: 'DE-MAIN', apiVersion: '2026-01' }),
fetchWMSInventory({ protocol: 'soap', warehouse: 'PL-FULFILLMENT' }),
fetchDropshipCSV({ sftp: process.env.SFTP_HOST, path: '/exports/stock_daily.csv' }),
]);
// Priorisierte Zusammenführung: DE > PL > Dropship
const mergedInventory = mergeWithPriority([
{ source: sapStock, priority: 1, locationId: 'gid://shopify/Location/1001' },
{ source: wmsStock, priority: 2, locationId: 'gid://shopify/Location/1002' },
{ source: dropshipStock, priority: 3, locationId: 'gid://shopify/Location/1003' },
]);
// Shopify Admin API 2026-01: Bulk-Inventory-Update mit Idempotency-Keys
await shopify.graphql(`
mutation inventorySetQuantities($input: InventorySetQuantitiesInput!) {
inventorySetQuantities(input: $input) {
inventoryAdjustmentGroup { reason }
userErrors { field message }
}
}
`, { input: { reason: 'correction', quantities: mergedInventory, ignoreCompareQuantity: true } });
}Ergebnis aus einem Kundenprojekt: 3 Stunden tägliche Bestandspflege entfallen, Überverkäufe um 94 % reduziert, Amortisierung innerhalb von 8 Wochen.
Prozess 2: Dynamische Preisanpassung mit Margen-Schutz
Das Problem
2.000 Produkte, 100 preissensible Top-Artikel, die Wettbewerber täglich ändern. Das Ziel: immer 2–5 % unter dem günstigsten Wettbewerber — aber nur wenn die Marge über 15 % bleibt. Premium-Marken werden ausgenommen, außerhalb der Geschäftszeiten keine Änderungen.
Warum Apps scheitern
Repricing-Tools wie Prisync arbeiten mit festen Prozentsätzen. Mehrstufige Bedingungslogik (Marge + Wettbewerber + Markenausnahme + Tageszeit + Lagerbestand) übersteigt ihr Regelwerk. Eine direkte Anbindung an Ihren ERP-Einkaufspreis? Fehlanzeige.
Die Custom-Lösung
async function adjustPrices() {
const [products, competitors, margins] = await Promise.all([
getCompetitiveProducts(), // Top-100 aus Shopify
scrapeCompetitorPrices(), // Eigene Crawling-Pipeline
getMarginDataFromERP(), // Einkaufspreise aus SAP/Sage
]);
for (const product of products) {
const comp = competitors[product.sku];
const margin = margins[product.sku];
if (!comp || !margin || product.vendor === 'PremiumBrand') continue;
const targetPrice = comp.lowestPrice * 0.97; // 3 % darunter
const effectiveMargin = (targetPrice - margin.purchasePrice) / targetPrice;
// Mindestmarge 15 % einhalten
const finalPrice = effectiveMargin < 0.15
? margin.purchasePrice / 0.85
: targetPrice;
await shopify.graphql(`
mutation productVariantUpdate($input: ProductVariantInput!) {
productVariantUpdate(input: $input) {
productVariant { id price }
userErrors { field message }
}
}
`, { input: { id: product.variantGid, price: roundToNine(finalPrice).toString() } });
}
}
const roundToNine = (price) => (Math.floor(price) + 0.99);Ergebnis: +3,2 % Gesamtumsatz bei gleichbleibender Marge, 4 Stunden/Woche manuelle Preisprüfung entfallen.
Prozess 3: Custom Fulfillment-Routing nach Produkttyp und Gewicht
Das Problem
Eine Bestellung, drei Zeilen: Sperrgut (Spedition), zwei Normalpakete (DHL), digitales Produkt (Sofort-Download). Die Bestellung soll automatisch aufgeteilt, an verschiedene Carrier übergeben und dem Kunden als eine einheitliche Sendungsverfolgung präsentiert werden.
Warum Apps scheitern
ShipStation und Sendcloud beherrschen Multi-Carrier-Versand. Die automatische Aufteilung einer Bestellung nach Produkteigenschaften — Typ, Gewicht, Gefahrgut-Status, Lager-Zuweisung — in verschiedene Fulfillments inklusive Speditionslogik liegt außerhalb ihres Funktionsumfangs.
Die Custom-Lösung
const ROUTES = {
SPERRGUT: { carrier: 'spedition_api', locationId: 'LOC_WAREHOUSE_DE' },
STANDARD: { carrier: 'dhl_api', locationId: 'LOC_WAREHOUSE_DE' },
DIGITAL: { carrier: null, locationId: null },
DROPSHIP: { carrier: 'supplier_api', locationId: 'LOC_SUPPLIER' },
};
function classifyProduct(lineItem) {
if (!lineItem.requiresShipping) return 'DIGITAL';
if (lineItem.grams > 31_500) return 'SPERRGUT'; // > 31,5 kg
if (lineItem.vendor === 'DropShipCo') return 'DROPSHIP';
return 'STANDARD';
}
async function routeOrderFulfillment(order) {
const grouped = {};
for (const item of order.lineItems) {
const cat = classifyProduct(item);
(grouped[cat] ??= []).push(item);
}
for (const [category, items] of Object.entries(grouped)) {
if (category === 'DIGITAL') {
await fulfillDigitalItems(order.id, items);
continue;
}
const route = ROUTES[category];
const fulfillment = await createFulfillmentOrder({ orderId: order.id, items, locationId: route.locationId });
await submitToCarrier(route.carrier, fulfillment);
}
}Ergebnis: Bei 50 Mixed-Bestellungen/Tag = 6,6 Stunden Zeitersparnis täglich (vorher 8 Min. pro Bestellung manuell).
Prozess 4: PIM-zu-Shopify Metafield-Sync mit Transformation
Das Problem
Produktdaten leben in Akeneo oder Pimcore: technische Spezifikationen, Pflegehinweise, CE-Kennzeichnungen, Zertifizierungen. Diese müssen als Metafields strukturiert, validiert und in der richtigen Sprache in Shopify landen.
Warum Apps scheitern
Akeneo-Konnektoren synchronisieren Basisdaten. Aber komplexes Mapping (ein PIM-Feld → mehrere Shopify-Metafields mit Transformation), bedingte Generierung (Metafield X nur wenn Produkttyp = Textil) und Validierung gegen externe Schemas gehen über Plugin-Fähigkeiten hinaus.
Die Custom-Lösung
// Shopify Admin API 2026-01: Metafields in einer Batch-Mutation setzen
async function syncMetafieldsFromPIM(pimProduct, shopifyGid) {
const metafields = [];
// Basis: für alle Produkte
metafields.push({ ownerId: shopifyGid, namespace: 'specs', key: 'material',
type: 'single_line_text_field', value: pimProduct.attributes.material?.de ?? '' });
// Konditional: Nur für Textilien (Textile Labelling Regulation EU 1007/2011)
if (pimProduct.category === 'textiles') {
metafields.push({ ownerId: shopifyGid, namespace: 'specs', key: 'textile_composition',
type: 'single_line_text_field',
value: formatTextileComposition(pimProduct.attributes.composition) });
}
// Zertifizierungen als strukturierte Liste
if (pimProduct.certifications?.length) {
metafields.push({ ownerId: shopifyGid, namespace: 'compliance', key: 'certifications',
type: 'list.single_line_text_field',
value: JSON.stringify(pimProduct.certifications.map(c => c.name)) });
}
await shopify.graphql(`
mutation metafieldsSet($metafields: [MetafieldsSetInput!]!) {
metafieldsSet(metafields: $metafields) {
metafields { key namespace value }
userErrors { field message }
}
}
`, { metafields });
}Ergebnis: 312 Arbeitsstunden/Jahr eingespart, Fehlerrate von 12 % auf 0,3 % gesenkt.
Prozess 5: Cross-Store-Synchronisation im Multi-Brand-Betrieb
Das Problem
Drei Shopify-Stores, verschiedene Marken, ein gemeinsamer Bestandspool. Produkte existieren in allen Stores mit unterschiedlichen Preisen und Beschreibungen. Bestellungen sollen in einem zentralen Dashboard konsolidiert und gemeinsam gefulfilled werden.
Warum Apps scheitern
Syncio kann Produkte kopieren — aber keine selektive Synchronisation (nur bestimmte Felder, unterschiedliche Preise pro Store), keine konsolidierte Bestandslogik mit Store-Priorisierung und kein einheitliches Order-Management.
Die Custom-Lösung
const STORES = [
{ name: 'Brand A', priority: 1, reserveStock: 5, client: shopifyClientA },
{ name: 'Brand B', priority: 2, reserveStock: 3, client: shopifyClientB },
{ name: 'Brand C', priority: 3, reserveStock: 0, client: shopifyClientC },
];
async function crossStoreInventorySync() {
const centralStock = await getCentralInventoryFromERP();
for (const sku of Object.keys(centralStock)) {
let remaining = centralStock[sku].quantity;
for (const store of STORES) {
const mapping = await getProductMapping(store.name, sku);
if (!mapping) continue;
const allocated = Math.max(0, remaining - store.reserveStock);
remaining -= allocated;
// Shopify Inventory API mit Idempotency-Key (neu in 2026-01)
await store.client.graphql(`
mutation inventorySetQuantities($input: InventorySetQuantitiesInput!) {
inventorySetQuantities(input: $input) {
userErrors { field message }
}
}
`, { input: {
reason: 'correction',
quantities: [{ inventoryItemId: mapping.inventoryItemId,
locationId: mapping.locationId, quantity: allocated }],
}});
}
}
}Ergebnis: 40 % weniger Operations-Aufwand, Überverkäufe eliminiert, 15 % weniger entgangener Umsatz durch Stockouts.
Prozess 6: Automatisierte B2B-Preislogik mit ERP-Vertragsanbindung
Das Problem
200 B2B-Kunden mit individuellen Strukturen: Kunde A bekommt 25 % auf Kategorie X, aber 10 % auf Y. Kunde B hat Festpreise für seine Top-50-Artikel. Kunde C erhält gestaffelte Mengenrabatte ab 100 Stück. All das soll live mit Shopify B2B und den Preis-Katalogen zusammenarbeiten.
Warum Apps scheitern
Shopify B2B bietet Preis-Kataloge — aber statisch. Dynamische Staffelpreise, kombinierte Regeln (Menge + Kundenstatus + Saison) und automatische Preisübertragung aus ERP-Verträgen gehen darüber hinaus.
Die Custom-Lösung
async function calculateB2BPrice(companyId, variantId, quantity) {
const [contract, variant] = await Promise.all([
getB2BContract(companyId), // Aus ERP geladen
getVariant(variantId),
]);
let price = parseFloat(variant.price);
const rules = [];
// Stufe 1: Kategorierabatt
const catDiscount = contract.categoryDiscounts?.[variant.productType];
if (catDiscount) { price *= (1 - catDiscount / 100); rules.push(`Kat. -${catDiscount}%`); }
// Stufe 2: Festpreise überschreiben
if (contract.fixedPrices?.[variant.sku]) {
price = contract.fixedPrices[variant.sku];
rules.splice(0, rules.length, `Festpreis ${price} €`);
}
// Stufe 3: Mengenstaffel
const tier = contract.volumeTiers
?.sort((a, b) => b.minQty - a.minQty)
.find(t => quantity >= t.minQty);
if (tier) { price *= (1 - tier.discount / 100); rules.push(`Menge -${tier.discount}%`); }
return { originalPrice: parseFloat(variant.price), finalPrice: Math.round(price * 100) / 100, rules };
}Ergebnis: 60 % weniger Pricing-Fehler, 3× schnellere Angebotserstellung, 1 Tag/Woche Verwaltungsaufwand entfällt.
Prozess 7: Orchestrierte Order-Workflows mit Fehlerbehandlung
Das Problem
Bestellung eingehend → Betrugsprüfung → parallel: Rechnung + Fulfillment + CRM-Update → wenn B2B: Lieferschein mit Custom-Template → nach Versand: Tracking-Seite mit Upsells personalisieren. Und wenn ein Schritt fehlschlägt, darf das nicht den gesamten Workflow korrumpieren.
Warum Apps scheitern
Shopify Flow beherrscht einfache Wenn-Dann-Ketten. Parallele Ausführung, Fehlerbehandlung mit Retry-Logik, bedingte Verzweigungen über externe Systeme und transaktionale Sicherheit (Rollback bei Teilfehler) sind in Flow nicht abbildbar.
Die Custom-Lösung
class OrderWorkflowOrchestrator {
async handleNewOrder(order) {
const fraudCheck = await this.checkFraud(order);
if (fraudCheck.risk === 'high') {
await Promise.all([this.holdOrder(order.id), this.notifySupport(order)]);
return;
}
// Parallele Verarbeitung — Promise.allSettled verhindert Cascade-Fehler
const results = await Promise.allSettled([
this.generateInvoice(order),
this.initiateFulfillment(order),
this.updateCRM(order),
]);
// Fehler einzelner Schritte: Retry mit Exponential Backoff
for (const [i, res] of results.entries()) {
if (res.status === 'rejected') await this.scheduleRetry(i, order.id);
}
if (order.customer?.tags?.includes('b2b')) {
await this.generateCustomDeliveryNote(order);
}
}
async scheduleRetry(stepIndex, orderId, attempt = 1) {
const delay = Math.min(1_000 * 2 ** attempt, 60_000); // max 60 s
setTimeout(async () => {
try { await this.retryStep(stepIndex, orderId); }
catch (e) { attempt < 5
? this.scheduleRetry(stepIndex, orderId, attempt + 1)
: this.escalateToSupport(stepIndex, orderId); }
}, delay);
}
}Ergebnis: Verarbeitungsquote 99,7 % (vorher 91 %), 4 Apps eingespart.
Prozess 8: Automatisierte Compliance-Prüfung (GPSR, WEEE, VerpackG)
Das Problem
Als Shopify-Händler in Deutschland greifen mehrere Regelwerke gleichzeitig: GPSR (General Product Safety Regulation, seit Dezember 2024 Pflicht), WEEE für Elektrogeräte, VerpackG, CE-Kennzeichnung, Textilkennzeichnung. Bei 500+ Produkten aus verschiedenen Quellen ist manuelle Prüfung ein Vollzeitjob.
Warum Apps scheitern
Es gibt schlicht keine Standard-Plugins für deutsche E-Commerce-Compliance. Die Anforderungen sind zu spezifisch, zu dynamisch und zu stark von Produktkategorie und Lieferkette abhängig. Internationale App-Entwickler bauen keine Apps für das Verpackungsgesetz.
Die Custom-Lösung
async function runComplianceCheck() {
const products = await getAllActiveProducts();
const issues = [];
for (const product of products) {
const productIssues = [];
// GPSR: Seit 13.12.2024 EU-Pflicht — verantwortliche Person angeben
if (!product.metafields?.compliance?.gpsr_responsible) {
productIssues.push({ severity: 'critical', type: 'GPSR',
message: 'Verantwortliche Person nach GPSR fehlt' });
}
// WEEE: Elektrogeräte brauchen stiftung ear Registrierung
if (isElectrical(product) && !product.metafields?.compliance?.weee_number) {
productIssues.push({ severity: 'critical', type: 'WEEE',
message: 'WEEE-Registrierungsnummer fehlt (Bußgeld bis 100.000 €)' });
}
// VerpackG: Lizenzierung bei LUCID für alle physischen Produkte
if (product.requiresShipping && !product.metafields?.compliance?.verpackg_licensed) {
productIssues.push({ severity: 'warning', type: 'VerpackG',
message: 'Verpackungslizenz bei LUCID nicht nachgewiesen' });
}
if (productIssues.length) {
issues.push({ product: product.title, issues: productIssues });
await tagProduct(product.id, productIssues.map(i => `compliance:${i.type}:missing`));
}
}
await sendReportEmail(generateComplianceReport(issues));
return issues;
}| Schweregrad | Typ | Konsequenz ohne Prüfung |
|---|---|---|
| Kritisch | GPSR | Abmahnrisiko, Produktsperrung |
| Kritisch | WEEE | Bußgeld bis 100.000 € |
| Warnung | VerpackG | Bußgeld bis 200.000 € |
| Kritisch | CE | Marktverbot innerhalb der EU |
Ergebnis: Wöchentlicher automatischer Audit, sofortige Benachrichtigung bei neuen Produkten, Compliance-Risiken systematisch sichtbar gemacht.
Wann lohnt sich Custom-Automatisierung wirklich?
Custom lohnt sich, wenn...
- Mehr als 300 €/Monat für Automatisierungs-Apps ausgegeben werden
- Regelmäßige manuelle Workarounds für Plugin-Limitierungen nötig sind
- Prozesse mehrere externe Systeme einbeziehen (ERP, PIM, WMS)
- Spezifische deutsche Compliance-Anforderungen gelten
- Multi-Store oder Multi-Brand-Betrieb vorliegt
- B2B-Preislogik zu komplex für Standard-Kataloge ist
- Mehr als 500 Bestellungen/Monat verarbeitet werden
Standard-Apps reichen, wenn...
- Einzelner Store mit Standardprozessen betrieben wird
- Fulfillment: ein Lager, ein Carrier
- Unter 200 Bestellungen/Monat
- Preis- und Rabattlogik einfach und einheitlich ist
- Keine ERP-Integration benötigt wird
- Shopify Flow und 1–2 spezialisierte Apps ausreichen
Die Break-Even-Formel
Monatliche Einsparung = manuelle Arbeitsstunden × Stundensatz
+ entfallende App-Kosten
+ vermiedene Fehlerkosten
Break-Even (Monate) = Entwicklungskosten ÷ Monatliche EinsparungKonkretes Beispiel: 2 Mitarbeiter à 5 h/Monat manuell (350 €) + 3 Apps à 50 € (150 €) + 2 Fehler/Monat (70 €) = 570 €/Monat Einsparung. Bei 5.000 € Entwicklungskosten: Break-Even nach 9 Monaten, danach 570 € netto monatlich gespart.
Fazit: Automatisierung ist kein Plugin-Problem
Die meisten Shopify-Händler starten richtig: Apps für Standardaufgaben, Flow für einfache Wenn-Dann-Logik. Aber ab einem gewissen Wachstumspunkt werden die Lücken zwischen den Apps größer als die Funktionalität der Apps selbst.
Custom-Automatisierung ist kein Luxus — es ist die logische nächste Stufe für Shops, die skalieren wollen, ohne proportional mehr Personal für repetitive Prozesse einzustellen. Die acht Prozesse in diesem Artikel sind keine theoretischen Szenarien, sondern genau die Herausforderungen, die mir Händler regelmäßig schildern.
Wenn Sie sich in zwei oder mehr dieser Szenarien wiederfinden: Der richtige Zeitpunkt ist meistens früher, als Sie denken.
Häufige Fragen
Ab wann lohnt sich Custom-Automatisierung für Shopify?
Als Faustregel: Wenn Sie mehr als 300–400 € monatlich für Automatisierungs-Apps ausgeben oder wenn Ihr Team regelmäßig manuelle Zwischenschritte für Prozesse übernimmt, die "eigentlich automatisch laufen sollten". Bei 500+ Bestellungen/Monat und ERP-Anbindung ist Custom fast immer die wirtschaftlichere Wahl.
Was kostet Custom-Automatisierung für Shopify?
Einfache Middleware-Lösungen beginnen bei 2.000–5.000 € Entwicklungskosten, komplexe Multi-System-Integrationen bei 10.000–25.000 €. Hosting kostet 5–50 €/Monat. Der Break-Even liegt bei typischen Projekten zwischen 9 und 18 Monaten — danach sparen Sie dauerhaft Monat für Monat.
Kann ich Custom-Automatisierung mit Shopify Flow kombinieren?
Ja — und das ist oft die klügste Strategie. Flow übernimmt einfache interne Automatisierungen (Tags setzen, Benachrichtigungen), Custom-Middleware die systemübergreifenden, geschäftskritischen Workflows. Beide können zusammenarbeiten: Flow setzt einen Tag, die Middleware reagiert darauf.
Welche Shopify API-Version sollte für neue Automatisierungen genutzt werden?
Seit Januar 2026 ist die GraphQL Admin API Version 2026-01 aktuell. Sie bringt u. a. verbesserte Bulk-Operations, Idempotency-Keys für Inventory-Mutations und erweiterte Metafield-Abfragen. Alle neuen Projekte sollten diese Version einsetzen. Shopify unterstützt API-Versionen 24 Monate lang.
Brauche ich für Custom-Automatisierung eine Shopify Plus-Lizenz?
Nein. Custom Apps und Middleware-Lösungen funktionieren auf allen Shopify-Plänen. Shopify Plus bietet zusätzliche API-Endpunkte (z. B. für Checkout-Erweiterungen und B2B-Kataloge), ist aber für die meisten Automatisierungsszenarien keine Voraussetzung.
Wie lange dauert die Entwicklung einer Custom-Automatisierung?
Einfache Middleware (ein System angebunden, ein Workflow): 1–2 Wochen. Komplexe Multi-System-Integration mit Dashboard und Monitoring: 4–8 Wochen. Ich arbeite iterativ mit wöchentlichen Demos, sodass Sie früh Feedback geben können.
Weiterführende Artikel
- Shopify Flow vs. Custom Automatisierung – Detaillierter Vergleich: Was Flow wirklich kann, wo seine harten Grenzen liegen und die 5-Fragen-Checkliste für die richtige Entscheidung.
- Mechanic für Shopify: Der Praxis-Guide – Die Automatisierungsplattform, die die Lücke zwischen Flow und Custom App schließt — mit realem Multi-Store-Sync-Beispiel.
- Shopify ERP-Integration – Wie SAP, Sage und andere ERP-Systeme sauber mit Shopify verbunden werden: Architekturen, Protokolle, typische Stolperfallen.

Geschrieben von
Justin Kreutzmann
Shopify-Entwickler für Custom Apps, ERP-Integrationen und Prozessautomatisierung. Ich helfe Marken, technische Grenzen zu überwinden — mit Lösungen, die im Alltag von Händlern wirklich funktionieren.
Projekt anfragen

