ConnectWiz + API og webhooker

Live integrasjon

API-et vi selger er API-et vi selv bruker

Hele plattformen er spesifisert i én OpenAPI-kontrakt som vårt eget panel og vår egen mobilapp genereres fra – ingen skjulte endepunkter, ingen dokumentasjon på avveie. Oppå den ligger Commerce-API-nøkler med scopes, sikrede webhook-utløsere og flyter som kaller systemene dine.

Én OpenAPI-kontrakt API-nøkler med scopes HMAC-verifiserte webhooker
API og webhooker × ConnectWiz
Payloads er data, aldri kommandoer
Nøkkel med scopes: katalog lese · ordrer skrive
Webhook → HMAC-verifisert → flyt starter
REST-steg i flyten kaller ditt API
1
OpenAPI-kontrakt som fasit – den samme fila vårt eget panel og våre egne mobilapper genereres fra
3
Commerce-scopes – katalog lese, ordrer lese, ordrer skrive – utstedt per nøkkel
100
Maks rader per lesing, klemt fast på serversiden – en limit-parameter valideres, den stoles aldri på
50
Ordrelinjer per ordre gjennom API-et – en oppgitt grense, ikke en du må oppdage selv

Utviklere

Hva den gjør – presist

Én kontrakt som fasit

Ett enkelt OpenAPI 3-dokument spesifiserer plattformen, og våre egne TypeScript-klienter genereres fra det – dokumentasjonen kan ikke komme på avveie fra virkeligheten, fordi virkeligheten er bygd fra dokumentasjonen.

Commerce-API-nøkler

Nøkler utstedt per tenant med eksplisitte scopes – katalog lese, ordrer lese, ordrer skrive – driver din egen nettbutikk eller app på den samme ordremotoren, med priser alltid avgjort på serversiden.

Innkommende webhooker, sikret

Hver webhook-utløser i en flyt har sin egen URL og sin egen hemmelighet, HMAC-verifisering over rå body og replay-beskyttelse. En payload kan navngi en person; den kan aldri styre det som skjer inne i flyten.

Utgående via flyter

REST-steget kaller systemene dine i nøyaktig de øyeblikkene du tegner opp på lerretet – ordre lagt inn, samtykke gitt, booking gjort.

Under panseret

Standpunktene i API-designet, sagt rett ut

Priser kommer aldri fra klienten

En ordreforespørsel sier hva og hvor mange – navn og pris leses fra katalogen i det øyeblikket, på serversiden, og skrives inn på linjen som et øyeblikksbilde. En manipulert forespørsel kan ikke dikte opp en rabatt.

Hva som er mulig, før du kaller

Hver integrasjonsflate publiserer en kapabilitetskontrakt – kan den matche på telefonnummer, liste gjesteordrer, opprette ordrer? – og et kall forbi et uttalt «nei» kaster feil med én gang i stedet for å ryke et sted langt nede.

Feil som betyr noe

Transporten skiller «ikke autorisert» fra «tjenesten er nede» – slik at «butikken er utilgjengelig» aldri blir gjengitt som «denne kunden har aldri kjøpt noe». Navngitte feil er forskjellen på et API og en gjettekonkurranse.

Webhooker som tåler replay

Hver innkommende hendelse gjør krav på en unik nøkkel i et idempotensregister før den behandles – en leveranse som gjentas eller spilles av på nytt, dør i databaselaget og ikke i automatiseringen din.

Nøkler hashet, hemmeligheter avgrenset

API-nøkler lagres som hasher, og bare hashen og scopene kan slås opp i døra – en lekket databaserad navngir ingen arbeidsområder og låser ikke opp noe utover sine egne scopes.

Utkast og bekreftelser er eksplisitte

Oppretting av ordre tar en eksplisitt confirm-parameter – det offentlige API-et har bekreftet som standard, og flyter i panelet kan legge opp utkast – slik at «er dette ekte?» er et felt, ikke en konvensjon.

Oppsett

Slik kobles den til

01

Utsted en nøkkel

Opprett en Commerce-API-nøkkel med scopes i panelet; trekk den tilbake like enkelt.

02

Koble opp en webhook

Lag en flyt med en webhook-utløser, og signer forespørslene med hemmeligheten dens.

03

Kall ut igjen

Legg inn REST-steg der systemene dine trenger å få vite om det.

Bedre sammen

Hva den spiller sammen med

Flows

Webhook-utløsere starter flyter; REST-steg kaller systemene dine tilbake i de øyeblikkene du tegner – innkommende og utgående automatisering deler ett og samme lerret.

Commerce

Vår katalog- og ordremotor bak API-et er den samme som chat-butikken og AI-en bruker – én ordresannhet, fire dører.

Din egen nettbutikk

Team kjører headless nettbutikker på Commerce-API-et allerede i dag – det er veien Shopify-siden ærlig anbefaler mens den native koblingen bygges.

Sikkerhet og garantier

De kjedelige garantiene

HMAC over rå body

Webhook-verifiseringen signerer den rå request-bodyen med en hemmelighet per utløser og sammenligner i konstant tid – parsingen skjer først etter at beviset er på plass.

Payloads er data, aldri kommandoer

En webhook-payload kan vise til en person; den kan aldri styre det som skjer inne i en flyt, skrive om prompter eller kalle verktøy. Grensen mellom data og instruksjoner er arkitektonisk, ikke atferdsmessig.

Ratebegrensning på hver dør

Offentlige endepunkter går på standard struping, og leselimitene klemmes fast på serversiden – en klient som oppfører seg dårlig, forringer seg selv og ikke plattformen.

Det med liten skrift, uten pynt

Grensene, sagt rett ut

Ingen firehose ennå

En generisk webhook-strøm der du abonnerer på alt, er ikke bygd – utgående hendelser skjer gjennom steg i flyter i dag. Det står her, slik at ingen salgssamtale trenger å antyde noe annet.

Avgrensede lesinger, med vilje

En lesing returnerer opptil 100 rader med markør – API-et er bygd for operativ integrasjon, ikke for masseeksport. Behov for masseuttrekk er en samtale, ikke et smutthull.

FAQ om API og webhooker

Klare svar

Mer finner du i vår fullstendige FAQ, eller spør oss direkte.

Plattformen er spesifisert i én OpenAPI 3-kontrakt – den samme fila vårt webpanel og vår mobilapp genererer typene sine fra. Det du integrerer mot, er det vi selv kjører på.

Egen hemmelighet per utløser, HMAC-verifisering over rå body og replay-beskyttelse gjennom et idempotensregister. Og som regel gjelder det at payloads er data: de kan vise til en person, men aldri kommandere automatiseringen.

Gjennom REST-steg i flyter, avfyrt i de øyeblikkene du velger på lerretet. En generisk utgående webhook-strøm står på veikartet, og vi lover den bevisst ikke før den faktisk kommer.

Ja – lesing av katalog og skriving av ordrer er den støttede veien, med priser avgjort på serversiden og nøkler med scopes du kan trekke tilbake per flate. Grensene på 50 linjer og 100 rader står skrevet, slik at du designer etter dem i stedet for å snuble i dem.

Leveranser er idempotente hos oss – registeret kjenner igjen en replay og forkaster den, så systemene dine kan prøve på nytt trygt. Utgående REST-steg fra flyter har sin egen retry-policy, med feil synliggjort på selve flytkjøringen.

Ærlig koblet slår høylytt koblet.

Hver eneste integrasjon her er beskrevet ut fra hva den faktisk gjør – retning, eierskap og grenser inkludert.