- Ge 3 verkliga anrop, inte ett ”leksaks”-exempel. Ta med ett typiskt lyckat fall, ett listanrop med paginering och ett write/update-anrop om du har ett. Prompten är byggd för att hitta systemiska mönster, så den behöver en liten bit av verkligheten. Om du kan, klistra in request/response-exempel med statuskoder.
- Ange driftskontexten direkt. Lägg till en kort rubrik som: ”Detta körs som en nattlig batch, bearbetar ~200k poster och måste vara klart på 45 minuter.” Fråga sedan: ”Granska dessa anrop för rate-limit-stormar och säkra retries givet den här genomströmningen.” Begränsningar ändrar rekommenderade timeouts, concurrency och backoff-beteende.
- Inkludera felkontraktet du tror gäller. Om leverantören dokumenterar specifika 429-headers, idempotency keys eller retry-after-beteende, klistra in den delen. Om du inte vet, säg det och be uttryckligen granskaren lista vilken evidens den behöver: ”Behandla odokumenterat beteende som okänt och säg vilka dokument eller tester som skulle bekräfta det.”
- Iterera genom att tvinga fram tradeoffs. Efter första outputen, prova att fråga: ”Gör nu åtgärdsplanen produktionsrealistisk för en tvåveckors sprint, och peka ut vad vi inte ska göra än.” Eller: ”Gör alternativ A aggressivt (högre concurrency) och alternativ B konservativt (lägre concurrency) och förklara riskerna.”
- Kör en andra passering som bara fokuserar på en felmod. Välj den läskigaste punkten (ofta 429-hantering, token-refresh eller icke-idempotenta retries) och följ upp med: ”Zooma in på detta. Ge mig en checklista med acceptanskriterier för en code review och vilka loggar/mätvärden som skulle bevisa att det fungerar.” Ärligt talat är det här prompten blir som mest värdefull.
- Granskar varje angivet API-anrop (kod eller pseudokod) utifrån REST-semantik, inklusive verb, resurser och förväntningar kring idempotens.
- Utvärderar användningsmönster för autentisering och auktorisering och lyfter riskfylld tokenhantering, saknade scopes och otydliga antaganden om identitet.
- Granskar resiliensbeteenden som retries, exponentiell backoff med jitter, timeout-budgetar och hantering per felklass.
- Identifierar systemiska antipatterns som pratiga gränssnitt, saknad paginering, långkörande synkrona anrop och risk för rate-limit-stormar.
- Gör en obligatorisk föranalys som återger din kontext och listar vilka indata som saknas för en komplett granskning, i stället för att hitta på okända detaljer.
- Du är på väg att skeppa en ny integration och vill fånga designmissar innan de blir jourincidenter.
- Återkommande driftstörningar sker och du misstänker att retry-beteende, kvothantering eller otydligt 4xx/5xx-beteende är grundorsaken.
- Ett leverantörs-API har ändrats, dokumentationen är ofullständig och du behöver en granskare som vägrar anta odokumenterat beteende.
- Trafiken skalar och din integration börjar slå i rate limits, timeouts eller få datakonsistensdrift mellan system.
- Du gör en genomgång av säkerhet och driftsberedskap och behöver prioritera att förebygga felmoder framför diskussioner om kodstil.
- En prioriterad granskningsrapport som täcker REST-korrekthet, säkerhetsläge, resiliens och effektivitet för alla angivna anrop.
- En checklista över ”saknade indata” (dokumentation, rate limits, felkontrakt, idempotensgarantier) så att granskningen kan slutföras utan gissningar.
- En felmodskarta som pekar ut sannolika incidentmönster, som kaskaderande retries, loopar vid token-expirering och konsistensdrift vid partiella skrivningar.
- Konkreta rekommendationer för åtgärder, inklusive vägledning för retry-strategi (backoff + jitter), timeout-budgetar och säkra pagineringsupplägg.
- Ett kort avsnitt om ”vad detta inte är” som förhindrar scope creep till refaktorering, benchmarkning eller leverantörsspecifika SDK-genomgångar.
- Ge 3 verkliga anrop, inte ett ”leksaks”-exempel. Ta med ett typiskt lyckat fall, ett listanrop med paginering och ett write/update-anrop om du har ett. Prompten är byggd för att hitta systemiska mönster, så den behöver en liten bit av verkligheten. Om du kan, klistra in request/response-exempel med statuskoder.
- Ange driftskontexten direkt. Lägg till en kort rubrik som: ”Detta körs som en nattlig batch, bearbetar ~200k poster och måste vara klart på 45 minuter.” Fråga sedan: ”Granska dessa anrop för rate-limit-stormar och säkra retries givet den här genomströmningen.” Begränsningar ändrar rekommenderade timeouts, concurrency och backoff-beteende.
- Inkludera felkontraktet du tror gäller. Om leverantören dokumenterar specifika 429-headers, idempotency keys eller retry-after-beteende, klistra in den delen. Om du inte vet, säg det och be uttryckligen granskaren lista vilken evidens den behöver: ”Behandla odokumenterat beteende som okänt och säg vilka dokument eller tester som skulle bekräfta det.”
- Iterera genom att tvinga fram tradeoffs. Efter första outputen, prova att fråga: ”Gör nu åtgärdsplanen produktionsrealistisk för en tvåveckors sprint, och peka ut vad vi inte ska göra än.” Eller: ”Gör alternativ A aggressivt (högre concurrency) och alternativ B konservativt (lägre concurrency) och förklara riskerna.”
- Kör en andra passering som bara fokuserar på en felmod. Välj den läskigaste punkten (ofta 429-hantering, token-refresh eller icke-idempotenta retries) och följ upp med: ”Zooma in på detta. Ge mig en checklista med acceptanskriterier för en code review och vilka loggar/mätvärden som skulle bevisa att det fungerar.” Ärligt talat är det här prompten blir som mest värdefull.
Vanliga frågor
Backendutvecklare använder den för att stresstesta API-anrop för idempotens, retries, rate limits och edge cases innan de blir uppkallade. Site reliability engineers använder den för att identifiera mönster för kaskadfel (retry-stormar, thundering herds, noisy neighbors) och omsätta dem till konkreta skyddsräcken. Tekniska produktchefer får värde eftersom prompten skapar en granskningstext de kan dela med intressenter, inklusive önskemål om saknade indata och prioriterade åtgärder. Integrationskonsulter använder den för att snabbt granska kunders implementationer, samtidigt som de håller en strikt linje: ”anta inte odokumenterat beteende”.
SaaS-bolag använder den när de bygger CRM-, betalnings- eller analysintegrationer där misstag kring rate limits och paginering i tysthet växer till kundpåverkande incidenter. E-handel och retail-team använder den för lager-, fulfillment- och marketplace-API:er, särskilt när batchjobb och webhook-retries kan skapa dubbla ordrar eller inkonsekvent lagersaldo. Fintech-team tjänar på den eftersom auth-läge, idempotens och felhantering är tätt kopplade till compliance-krav, och små oklarheter kan skapa verklig risk. Sjukvård och reglerade tjänster använder den för att göra tokenhantering, åtkomstgränser och driftsäkerhet explicit när de kopplar mot tredjepartssystem.
En typisk prompt som ”Granska min API-kod och säg vad som är fel” misslyckas eftersom den: saknar ett felmodsperspektiv (den spårar inte nedströmskonsekvenser som rate-limit-stormar), saknar strukturerad föranalys för att be om saknade dokument och antaganden, ignorerar REST-semantik och idempotens så att den missar icke-uppenbara skrivrisker, producerar generiska best practices i stället för fynd per anrop, och hittar ofta på odokumenterat leverantörsbeteende i stället för att behandla det som okänt. Den här prompten är striktare: den ber om bevis, prioriterar säkerhet och resursslöseri och fokuserar på driftsäkerhet.
Ja, genom att lägga till din egen kontext innan du klistrar in anropen, eftersom prompten i sig inte har några inbyggda variabler. Börja med att ange arbetslastens form (batch vs realtid), concurrency, latensbudget och vad ”korrekthet” betyder (eventual consistency vs strikt). Ta sedan med kända begränsningar som dokumenterade rate limits, retry-after-headers, tokenlivslängder och stöd för idempotency keys. En bra uppföljning är: ”Givet den här kontexten, skriv om de 5 viktigaste åtgärderna som acceptanskriterier för en pull request, inklusive vilka loggar/mätvärden vi ska lägga till för att validera beteendet.”
Det största misstaget är att ge anrop utan kontext – i stället för ”Här är endpointen”, säg ”Den här endpointen körs i en webhook-handler med 3 sekunders timeout och kan retrys av leverantören.” Ett annat vanligt fel är att utelämna fel- och rate limit-detaljer; ”Den returnerar ibland fel” är svagt, medan ”Vi ser 429 med Retry-After ibland, plus intermittent 503” ger granskaren något att agera på. Många klistrar också bara in en enda GET och hoppar över write-paths; inkludera minst ett create/update-flöde där idempotens och retries blir farliga. Till sist glömmer team att ta med vad som är okänt; att uttryckligen säga ”Vi vet inte om den här endpointen är idempotent” hjälper prompten att be om rätt bevis och undvika dåliga antaganden.
Den här prompten är inte idealisk för team som vill ha en fullständig kodrefaktor, prestandabenchmarkning eller en leverantörsspecifik SDK-tutorial, eftersom den medvetet undviker de områdena. Den är inte heller en ersättning för officiell dokumentation eller en formell säkerhetsgranskning när du behöver försäkran på compliance-nivå. Om du bara vill ha ett snabbt copy-paste-snippet utan att dela någon kontext kommer du få tillbaka många ”saknade indata”. I så fall: samla request/response-exempel och leverantörsdokumentation först och kör sedan granskningen.
De flesta API-avbrott är förutsägbara i efterhand. Använd den här prompten för att upptäcka mönstren tidigt, dokumentera vad som saknas och gå in i produktion med färre överraskningar.
API-integrationer fallerar sällan i det lyckade standardflödet. De fallerar på måndag kl. 02:00 för att en retry-loop rusade in i en rate limit, en auth-token gick ut mitt i en batch, eller en ”enkel” GET blev ett anrop med bieffekter som ingen behandlade som riskfyllt. Du behöver inte snyggare kod. Du behöver färre felmoder.
Den här API integrationsgranskningen är byggd för backendutvecklare som tar över en skör integration precis före lansering, tekniska produktchefer som behöver en audit trail av risker och åtgärder för intressenter, och konsulter som snabbt måste granska kunders API-användning utan att gissa odokumenterat beteende. Outputen är en strukturerad granskningsrapport som flaggar REST- och auth-problem, resilienstapp (retries, backoff, idempotens) och slöserimönster (överhämtning, pratiga anrop), plus prioriterad vägledning för åtgärder.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Vad du får |
|---|---|---|
|
|
|
|
Hela AI-prompten: granskningsrapport för API-integration
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[KONTEXT] |
Ge bakgrundsinformation om API-integrationen, inklusive syfte, omfattning samt relevanta begränsningar eller krav. Till exempel: "En e-handelsplattform som integrerar med ett betalväxel-API för att behandla transaktioner säkert och effektivt."
|
|
[FORMAT] |
Ange förväntat format eller struktur för API-anropen eller den pseudokod som ska granskas. Till exempel: "REST-API-anrop skrivna i JSON, inklusive headers, frågeparametrar och exempel på payloads."
|
|
[UTMANING] |
Beskriv det huvudsakliga problemet eller den fråga du vill få adresserad i granskningen av API-integrationen. Till exempel: "Säkerställa robust felhantering och återförsökslogik för att förhindra kedjefel vid hög belastning."
|
|
[BUDGET] |
Ange uppskattad budget eller resursbegränsningar för att utveckla och förvalta API-integrationen. Till exempel: "10 000 USD avsatt för utveckling och test, med fokus på att minimera driftskostnaderna."
|
|
[HUVUDMAL] |
Ange projektets huvudsakliga mål eller önskade resultat för API-integrationen. Till exempel: "Möjliggöra smidig betalningshantering med hög tillgänglighet och minimal latens."
|
|
[BRANSCH] |
Ange bransch eller domän som är relevant för projektet med API-integrationen. Till exempel: "Hälso- och sjukvårdsteknik med fokus på hantering av patientdata och säker kommunikation."
|
|
[MALGRUPP] |
Definiera de primära användarna eller intressenterna för API-integrationen, inklusive deras viktigaste egenskaper och behov. Till exempel: "Småföretagare som använder e-handelsplattformar och behöver pålitlig betalningshantering samt bedrägeridetektering."
|
|
[VERSALER_MED_UNDERSCORE] |
Ange ett värde formaterat med versaler separerade med underscore, vanligtvis använt för konstanter eller miljövariabler. Till exempel: "API_RATE_LIMIT_REACHED"
|
Proffstips för bättre resultat med AI-prompten
Vanliga frågor
Backendutvecklare använder den för att stresstesta API-anrop för idempotens, retries, rate limits och edge cases innan de blir uppkallade. Site reliability engineers använder den för att identifiera mönster för kaskadfel (retry-stormar, thundering herds, noisy neighbors) och omsätta dem till konkreta skyddsräcken. Tekniska produktchefer får värde eftersom prompten skapar en granskningstext de kan dela med intressenter, inklusive önskemål om saknade indata och prioriterade åtgärder. Integrationskonsulter använder den för att snabbt granska kunders implementationer, samtidigt som de håller en strikt linje: ”anta inte odokumenterat beteende”.
SaaS-bolag använder den när de bygger CRM-, betalnings- eller analysintegrationer där misstag kring rate limits och paginering i tysthet växer till kundpåverkande incidenter. E-handel och retail-team använder den för lager-, fulfillment- och marketplace-API:er, särskilt när batchjobb och webhook-retries kan skapa dubbla ordrar eller inkonsekvent lagersaldo. Fintech-team tjänar på den eftersom auth-läge, idempotens och felhantering är tätt kopplade till compliance-krav, och små oklarheter kan skapa verklig risk. Sjukvård och reglerade tjänster använder den för att göra tokenhantering, åtkomstgränser och driftsäkerhet explicit när de kopplar mot tredjepartssystem.
En typisk prompt som ”Granska min API-kod och säg vad som är fel” misslyckas eftersom den: saknar ett felmodsperspektiv (den spårar inte nedströmskonsekvenser som rate-limit-stormar), saknar strukturerad föranalys för att be om saknade dokument och antaganden, ignorerar REST-semantik och idempotens så att den missar icke-uppenbara skrivrisker, producerar generiska best practices i stället för fynd per anrop, och hittar ofta på odokumenterat leverantörsbeteende i stället för att behandla det som okänt. Den här prompten är striktare: den ber om bevis, prioriterar säkerhet och resursslöseri och fokuserar på driftsäkerhet.
Ja, genom att lägga till din egen kontext innan du klistrar in anropen, eftersom prompten i sig inte har några inbyggda variabler. Börja med att ange arbetslastens form (batch vs realtid), concurrency, latensbudget och vad ”korrekthet” betyder (eventual consistency vs strikt). Ta sedan med kända begränsningar som dokumenterade rate limits, retry-after-headers, tokenlivslängder och stöd för idempotency keys. En bra uppföljning är: ”Givet den här kontexten, skriv om de 5 viktigaste åtgärderna som acceptanskriterier för en pull request, inklusive vilka loggar/mätvärden vi ska lägga till för att validera beteendet.”
Det största misstaget är att ge anrop utan kontext – i stället för ”Här är endpointen”, säg ”Den här endpointen körs i en webhook-handler med 3 sekunders timeout och kan retrys av leverantören.” Ett annat vanligt fel är att utelämna fel- och rate limit-detaljer; ”Den returnerar ibland fel” är svagt, medan ”Vi ser 429 med Retry-After ibland, plus intermittent 503” ger granskaren något att agera på. Många klistrar också bara in en enda GET och hoppar över write-paths; inkludera minst ett create/update-flöde där idempotens och retries blir farliga. Till sist glömmer team att ta med vad som är okänt; att uttryckligen säga ”Vi vet inte om den här endpointen är idempotent” hjälper prompten att be om rätt bevis och undvika dåliga antaganden.
Den här prompten är inte idealisk för team som vill ha en fullständig kodrefaktor, prestandabenchmarkning eller en leverantörsspecifik SDK-tutorial, eftersom den medvetet undviker de områdena. Den är inte heller en ersättning för officiell dokumentation eller en formell säkerhetsgranskning när du behöver försäkran på compliance-nivå. Om du bara vill ha ett snabbt copy-paste-snippet utan att dela någon kontext kommer du få tillbaka många ”saknade indata”. I så fall: samla request/response-exempel och leverantörsdokumentation först och kör sedan granskningen.
De flesta API-avbrott är förutsägbara i efterhand. Använd den här prompten för att upptäcka mönstren tidigt, dokumentera vad som saknas och gå in i produktion med färre överraskningar.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.