Bygg med Kassalapp API og en kodeassistent

Denne guiden viser hvordan du kan bruke en kodeassistent til å bygge mot Kassalapp API. Arbeidsmåten fungerer med blant annet Claude Code, Codex, ChatGPT, Cursor og andre verktøy som kan lese dokumentasjon og redigere kode.

Målet er ikke å få mest mulig kode i ett svar. Målet er å gi assistenten nok kontekst, avgrense oppgaven og kontrollere resultatet underveis.

Før du begynner

Du trenger:

• en Kassalapp API-nøkkel
• et prosjekt der du kan kjøre kode og tester
• API-referansen eller OpenAPI-spesifikasjonen
• en kodeassistent som passer arbeidsflyten din

Opprett en API-nøkkel fra Kassalapp-profilen din. Bruk deretter disse verdiene som miljøvariabler:

KASSALAPP_API_KEY=din-api-nøkkel
KASSALAPP_BASE_URL=https://kassal.app/api/v1

Ikke lim en ekte API-nøkkel inn i en samtale, kildekode, skjermdump eller Git-commit. Be assistenten lese nøkkelen fra miljøet.

Gi assistenten riktig kontekst

En kodeassistent kjenner ikke nødvendigvis den nyeste versjonen av Kassalapp API. Gi den derfor autoritative kilder før den begynner å implementere:

• API-referanse
• OpenAPI-spesifikasjon
• eksisterende kode, tester og prosjektinstruksjoner

Be assistenten kontrollere endepunkter, parametere og responsfelter mot spesifikasjonen. Den skal ikke finne på felter når dokumentasjonen er uklar.

Et godt startprompt kan se slik ut:

Du skal legge til Kassalapp API i dette prosjektet.

Før du endrer kode:
1. Les prosjektets eksisterende struktur og instruksjoner.
2. Les OpenAPI-spesifikasjonen på https://kassal.app/docs/api.json.
3. Finn endepunktene og responsfeltene som oppgaven trenger.
4. Beskriv en kort implementeringsplan og hvilke filer som må endres.

Krav:
- Les API-nøkkelen fra KASSALAPP_API_KEY.
- Bruk https://kassal.app/api/v1 som base-URL.
- Legg inn timeout og forståelig feilhåndtering.
- Håndter 401, 404, 422, 429 og 5xx-responser.
- Ikke logg API-nøkkelen.
- Legg til tester med falske HTTP-responser.
- Kjør relevante tester og formattering før du avslutter.

Arbeid i små, kontrollerbare steg

Be assistenten fullføre én vertikal del av funksjonen om gangen:

1. Lag en liten API-klient.
2. Implementer ett endepunkt.
3. Legg til datatyper eller validering.
4. Koble klienten til brukergrensesnittet.
5. Legg til tester og feiltilstander.
6. Kjør løsningen og kontroller resultatet.

Små steg gjør det enklere å oppdage feil og gir mer presise kodegjennomganger.

Prompt: produktsøk

Implementer produktsøk med Kassalapp API i dette prosjektet.

Bruk API-referansen og OpenAPI-spesifikasjonen som fasit. Ikke anta navn på
parametere eller responsfelter.

Brukerflyt:
- Brukeren skriver minst tre tegn.
- Søket starter etter en kort debounce.
- Tidligere forespørsler avbrytes når søket endres.
- Resultatet viser produktnavn, butikk og pris når feltene finnes.
- Grensesnittet har tydelige tilstander for lasting, tomt resultat og feil.

Tekniske krav:
- API-nøkkelen leses fra miljøet og eksponeres ikke i nettleseren.
- Nettleserklienten kaller vår egen server-side rute.
- Klienten bruker timeout og håndterer rate limiting.
- Legg til tester for suksess, tomt resultat, 401 og 429.

Vis først hvilke filer du vil endre. Implementer deretter løsningen og kjør testene.

Prompt: produktoppslag med EAN

Legg til oppslag av dagligvarer med EAN-strekkode.

Les korrekt endepunkt og responsskjema fra Kassalapp sin OpenAPI-spesifikasjon.
Valider EAN før forespørselen sendes. Vis produktinformasjon og tilgjengelige
priser uten å anta at alle valgfrie felter finnes.

Håndter disse tilfellene eksplisitt:
- ugyldig EAN
- produktet finnes ikke
- manglende eller ugyldig API-nøkkel
- rate limit
- midlertidig serverfeil

Legg til enhetstester for valideringen og integrasjonstester med falske
HTTP-responser. Ikke bruk ekte API-kall i den vanlige testsuiten.

Prompt: prissammenligning

Bygg en prissammenligning for ett produkt basert på data fra Kassalapp API.

Før implementering skal du kontrollere i API-spesifikasjonen hvordan et produkt,
butikk og pris representeres. Normaliser responsen i et lite internt datalag før
den vises i grensesnittet.

Vis:
- produktnavn
- pris per butikk
- laveste tilgjengelige pris
- tidspunkt for siste prissjekk når feltet finnes
- en tydelig melding dersom ingen priser er tilgjengelige

Sorter bare på gyldige numeriske priser. Ikke presenter manglende data som null
kroner. Legg til tester for ufullstendige responser og flere butikker med samme pris.

Prompt: eksisterende prosjekt

Når prosjektet allerede finnes, bør du be om en avgrenset endring i stedet for en komplett omskriving:

Undersøk hvordan dette prosjektet gjør HTTP-kall, konfigurasjon, logging og tester.
Legg Kassalapp-integrasjonen inn i de eksisterende mønstrene.

Oppgave: [beskriv én konkret brukerflyt]

Begrensninger:
- Ikke bytt rammeverk eller sentrale biblioteker.
- Ikke endre offentlig API uten å forklare hvorfor.
- Bevar eksisterende kode som ikke er relevant for oppgaven.
- Vis diffen og påpek eventuelle antakelser.
- Kjør den minste relevante testsuiten, og utvid ved behov.

Klientside eller serverside

En hemmelig API-nøkkel skal normalt brukes på serversiden. For en nettleser- eller mobilapplikasjon kan du la din egen backend kommunisere med Kassalapp API:

Nettleser eller app
        |
        v
Din server-side rute
        |
        v
Kassalapp API

Dette gjør det mulig å:

• holde API-nøkkelen utenfor klienten
• validere og begrense innkommende parametere
• legge til caching og rate limiting
• samle feilrapportering på ett sted

Be assistenten forklare sikkerhetsmodellen dersom den foreslår direkte kall fra klienten.

Feilhåndtering

Be om feiltilstander som hjelper både brukeren og utvikleren:

Sett en eksplisitt timeout. Automatisk retry bør bare brukes for forespørsler som trygt kan gjentas.

Testing

Tester skal være raske og forutsigbare. Bruk falske HTTP-responser i stedet for å kontakte produksjons-API-et i hver testkjøring.

Be minst om tester for:

• vellykket respons
• tomt resultat
• ufullstendige valgfrie felter
• ugyldig input
• timeout
• 401 og 429
• parsing av priser og identifikatorer

Et eget, manuelt smoke-teststeg kan brukes for å bekrefte at integrasjonen fortsatt fungerer mot det virkelige API-et.

Gjennomgå generert kode

Kontroller dette før du beholder endringen:

• Stemmer endepunkter og felter med API-spesifikasjonen?
• Holdes hemmeligheter utenfor kildekode, logger og klient-bundles?
• Følger koden prosjektets eksisterende mønstre?
• Finnes det timeout, validering og forståelige feiltilstander?
• Er alle valgfrie responsfelter håndtert?
• Tester koden reell oppførsel og ikke bare implementasjonsdetaljer?
• Har assistenten faktisk kjørt testene den viser til?
• Er diffen liten nok til å kunne gjennomgås?

Be gjerne assistenten gjøre en egen kodegjennomgang etter implementeringen:

Gjennomgå diffen som om den skulle i produksjon. Se spesielt etter feil bruk av
Kassalapp API, lekkasje av hemmeligheter, manglende validering, dårlig
feilhåndtering og tester som ikke ville oppdage en regresjon. Oppgi konkrete
funn med fil og linje før du foreslår endringer.

Når du bør bruke MCP-serveren

Hvis målet er å la en AI-assistent søke etter produkter og priser direkte, trenger du ikke nødvendigvis bygge en egen API-integrasjon. Kassalapp tilbyr også en offentlig, skrivebeskyttet MCP-server uten API-nøkkel.

Se MCP Server-guiden for oppsett i Claude, Codex, ChatGPT og OpenCode.

Neste steg

Start med én konkret brukerflyt, gi assistenten den autoritative API-spesifikasjonen, og krev at løsningen testes. Utvid først når den første delen fungerer og diffen er gjennomgått.