Utvikler-API og MCP

Alt du administrerer i appen, kan du også administrere via din egen kode eller via en AI-assistent. Workflow Webhooks tilbyr to grensesnitt: et REST-API og en MCP-server. Begge finnes på utviklersiden.

API-nøkler

Begge tjenestene bruker en API-nøkkel for autentisering. På utviklersiden, under API-nøkler, oppretter du en nøkkel og velger tilgangsnivå:

• Skrivebeskyttet - vise webhooks, lese utløsningshistorikk og statistikk.
• Les og skriv - samt opprett, oppdater og slett webhooks.
• Les, skriv og kjør - du kan også utføre en testkall eller gjenta en tidligere testkall.

Hele nøkkelen vises én gang, når den opprettes. Kopier den da og oppbevar den på et sikkert sted; du vil ikke kunne se den igjen. Nøklene lagres i hashform, aldri i klartekst, og du kan tilbakekalle en nøkkel når som helst.

Send nøkkelen som et «Bearer»-token ved hver forespørsel:

Authorization: Bearer fwk_your_key_here

Hvorfor «execute» er et eget nivå

Når du utløser en webhook, utløser det faktisk arbeidsflytene dine i Shopify Flow, og disse arbeidsflytene kan endre butikken din - for eksempel ved å merke bestillinger, sende e-post eller oppdatere lagerbeholdningen. Ved å holde dette på et eget nivå sikrer du at en nøkkel du gir til et skript eller en AI-assistent for det daglige arbeidet, ikke kan utløse automatiseringene dine ved et uhell. Del ut lesenøkler som standard, og opprett kun en utførelsesnøkkel der du virkelig trenger en.

Grunn-URL

API-et og MCP-serveren er tilgjengelige via et eget vertsnavn:

https://shopify.workflow-webhooks.app

REST-API-et ligger altså på https://shopify.workflow-webhooks.app/api/v1, og MCP-serveren på https://shopify.workflow-webhooks.app/api/mcp. På utviklersiden vises begge med en kopieringsknapp.

Dette vertsnavnet betjener kun /api - det innebygde administrasjonsgrensesnittet forblir på sin egen Shopify-registrerte URL. Ved å holde dem adskilt sikrer man at adressen du limer inn i et skript, en CI-jobb eller en AI-klient er stabil og uavhengig av appens innbygging.

REST-API

Grunn-URL-en vises på utviklersiden. De viktigste endepunktene:

Metode	Sti	Nivå	Formål
HENT	/api/v1	ingen	API-indeks - bekrefter at API-et er oppe og går
HENT	/api/v1/me	les	Sjekk autorisasjonen og se nivået på nøkkelen din
HENT	/api/v1/webhooks	les	Vis webhooks
INNLEGG	/api/v1/webhooks	skrive	Opprett en webhook
HENT	/api/v1/webhooks/:id	les	Få én webhook
PUT / PATCH	/api/v1/webhooks/:id	skrive	Oppdater en webhook
SLETT	/api/v1/webhooks/:id	skrive	Slett en webhook
INNLEGG	/api/v1/webhooks/:id/test	utføre	Utfør en testkall
HENT	/api/v1/history	les	Liste over påkallinger
HENT	/api/v1/history/:id	les	Hent én påkalling, sammen med dens nyttelast
INNLEGG	/api/v1/history/:id/replay	utføre	Spill av en tidligere påkalling
HENT	/api/v1/stats	les	Totaltall, suksessrate, daglige serier
HENT	/api/v1/templates	les	Innebygde webhook-maler

En rask sjekk for å se om nøkkelen din fungerer:

curl https://shopify.workflow-webhooks.app/api/v1/me \
  -H "Authorization: Bearer fwk_your_key_here"

{ "authenticated": true, "shop": "your-store.myshopify.com", "level": "READ" }

MCP-server

MCP-serveren gjør det mulig for en AI-assistent (Claude, Cursor, VS Code, Gemini CLI og andre) å bruke webhookene dine i samtalen. På utviklersiden viser MCP-fanen serverens URL og en koblingskommando som er klar til å kopieres for hver klient, med nøkkelen din allerede lagt inn.

Verktøyene speiler REST-endepunktene, og verktøysettet avhenger av nøkkelens nivå: En skrivebeskyttet nøkkel har ikke engang tilgang til verktøyene som oppretter, sletter eller utløser webhooks. All autentisering og datahåndtering foregår på serversiden.

Hvordan opplysningene dine beskyttes

Det er to ting du bør vite før du kobler en automatiseringsløsning eller en AI-assistent til dette API-et.

Autentiseringstokenet til webhooken din er aldri lesbart. Tokenet eller signeringsnøkkelen du angir for en webhook, kan ikke leses ut via API-et eller MCP på noe nivå. Svarene forteller deg bare om et token er angitt (hasToken), aldri verdien av det. Du kan angi et nytt token, men du kan aldri hente det gamle.

Personopplysninger i nyttelaster blir maskert. Webhook-nyttelaster kommer fra eksterne systemer og inneholder ofte kundeopplysninger. Før en invokasjonspayload forlater serveren, erstattes verdier som ser ut som personopplysninger med ***: e-postadresser, telefonnumre, kortnumre og felt oppkalt etter en person (customerName, shippingAddress og lignende). Forespørselshoder renses på samme måte som appens historikkskjerm gjør det.

Denne maskeringen er grundig, men gir ingen garanti. Den fungerer på feltnavn og verdimønstre, så personopplysninger som finnes i et fritekstfelt - en notat, en kommentar eller en meldingstekst - kan fortsatt komme til syne. Behandle API-svar som om de potensielt inneholder kundedata, og lagre dem deretter.

Test og gjengivelse bruker ikke kvoten din. Anrop du utfører via API-et registreres som tester, så de teller ikke med i den månedlige kvoten for abonnementet ditt. Gjengivelser teller heller ikke med, siden det opprinnelige anropet allerede har gjort det.

Neste trinn

• Introduksjon til Workflow Webhooks - hvordan webhooks og tilordning av nyttelast fungerer.

Ratebegrensninger

REST-API-et og MCP-serveren deler ett budsjett per API-nøkkel.

• 300 forespørsler per 60 sekunder per nøkkel, som et fast tidsvindu.
• Kall på utførelsesnivå tildeles et sekundært, strammere budsjett på 60 per time. De bruker begge deler, så en bølge av utførelser tærer også på den felles kvoten. For denne appen betyr det å utløse en webhook for testing og å gjengi en historikkoppføring - begge deler kjører faktisk Shopify Flow-arbeidsflytene dine.
• Det er det samme for alle abonnementer. Abonnementet ditt måler antall invokasjoner, ikke API-anrop, så en oppgradering fører ikke til at disse tallene øker.
• Ved behandling av svar returneres HTTP 429. Vent litt og prøv på nytt, helst med eksponentiell ventetid.
• Hvis cachen vår er midlertidig utilgjengelig, vil begrenseren gå i åpen stilling i stedet for å blokkere integrasjonen din.

Innkommende webhooks er ikke underlagt noen hastighetsbegrensning

Det er verdt å presisere dette, siden det er det spørsmålet vi får oftest: Vi begrenser ikke mottak av innkommende webhooks. Vi sender dem videre så fort de kommer inn, uansett hvor mange som kommer på en gang fra kildesystemet ditt - vi har ingen begrensning per sekund eller per minutt.

Den eneste begrensningen er planens kvote på 30 dager for utløsning av trigger. Når denne er brukt opp, vil ikke flere utløsninger bli behandlet før perioden starter på nytt eller du oppgraderer. Utover dette gjelder Shopifys begrensninger: Shopify Flow har egne utførelsesbegrensninger, og størrelsen på en trigger-payload er begrenset til 50 KB.

Shopify

Dette er Shopifys begrensninger for Shopifys API-er, ikke våre. De gjelder hva denne appen (og arbeidsflytene dine) kan gjøre på Shopify-siden, og du kan komme til å støte på dem i en stor nettbutikk, selv om du holder deg godt innenfor våre egne begrensninger.

• Inndatamatriser er begrenset til 250 elementer i alle Shopify-API-er. En forespørsel med en større matrise blir avvist.
• Paginering stopper ved 25 000 objekter. Antallene er nøyaktige opp til 25 000; over dette tallet returnerer Shopify 25001, som betyr «mer enn 25 000». Hvis du trenger å gå dypere, må du filtrere først.
• GraphQL Admin API måles ut fra den beregnede kostnaden per forespørsel, i poeng per sekund, og taket avhenger av butikkens Shopify-abonnement:

Shopify-abonnement	Poeng per sekund
Standard	100
Avansert	200
I tillegg	1000
Enterprise (handelskomponenter)	2000

Storefront API har ingen begrensninger på antall forespørsler.

Fullstendig informasjon: Begrensninger på Shopify-API