Integration with other systems / APIs

Collaboration, product, and users

Integration with other systems / APIs

Det externa API:et som vi anropar är tyvärr helt nere, vilket just nu blockerar hela vår kassa.

Vi måste vänta in att webhooken från betalleverantören triggas innan vi kan skicka kvittot.

Kontraktet för API:et har tydligen ändrats i tysthet, vilket fick vår kod att krascha inatt.

Integrationen mot affärssystemet krånglar ständigt, vi behöver ha ett möte med deras tekniker.

Vi får 'Rate Limit'-fel (för många anrop) från API:et eftersom vi gör för många uppslagningar för snabbt.

Har de publicerat någon uppdaterad dokumentation för den nya versionen av deras REST API?

Vi bygger en adapter som översätter XML-svaret från deras gamla system till smidig JSON för oss.

Integrationen kräver att vi implementerar OAuth 2.0 för att hantera inloggningen på ett säkert sätt.

Vi måste säkerställa att vi hanterar nätverkstidsutlösningar (timeouts) snyggt när vi pratar med leverantören.

Jag håller på att sätta upp en ny anslutning (connection) i middleware-plattformen för detta.

Deras API returnerar tyvärr väldigt opålitlig data, vi måste validera varje fält noggrant på vår sida.

Vi måste stämma av med partnern vilka IP-adresser som ska vitlistas i deras brandvägg för integrationen.

Kan vi bygga in en omprövningsmekanism (retry logic) för när anropen tillfälligt misslyckas?

Det är ett enormt beroende (dependency), om deras tjänst går ner så går vår tjänst också ner.

Vi använder en meddelandekö (message queue) för att skicka över informationen asynkront till dem.

Vår partner skickar datan till oss i batchar via en säker FTP-server varje natt klockan två.

Jag kollar loggarna för att se om vi skickade fel format, eller om felet ligger hos deras server.

Vi saknar en säkerhetsnyckel (API key) för att kunna autentisera oss mot testmiljön.

Integrationen med fraktbolaget är äntligen certifierad och redo att rullas ut i produktion.

De skickar med en hel del överflödig information i API-svaret som vi bara filtrerar bort.

Vi måste kartlägga (mappa) fälten i deras databas mot våra egna interna fältnamn.

Det är svårt att testa integrationen fullt ut eftersom deras testmiljö är så pass instabil.

Vi funderar på att använda GraphQL istället för REST för att minska mängden data vi behöver hämta.

Den nya leverantören erbjuder tyvärr inga webhooks, så vi måste istället fråga deras API regelbundet (polling).

Ett 'Circuit Breaker'-mönster är nödvändigt här för att skydda vårt system om leverantörens API kraschar.

Kan du verifiera att vi skickar med rätt 'Content-Type'-header i anropet (application/json)?

Vi skickar ett hjärtslag (heartbeat-anrop) varje minut för att kontrollera att anslutningen fortfarande lever.

Den externa tjänsten genomför ett planerat underhållsarbete, så integrationen ligger nere i två timmar.

Vi måste skriva ner exakt vilka endpoints som faktiskt används i den här enorma integrationen.

Payloaden (datapaketet) vi skickar är för stor, vi måste komprimera den innan den skickas iväg.

Integrationen är byggd för att vara så löst kopplad (loosely coupled) till vårt eget system som möjligt.

Deras API stödjer tyvärr inte sökning, så vi måste ladda ner allt och söka lokalt på vår server.

Vi får in väldigt mycket dubblettdata från deras system, vi måste hantera det på ett smartare sätt.

Vi måste byta ut den utgångna API-nyckeln i produktionsmiljön innan den slutar fungera imorgon bitti.

Svaret vi får tillbaka från servern är kodat (enkodat) felaktigt, svenska tecken ser helt konstiga ut.

Jag bygger ett gränssnitt för att supporten manuellt ska kunna trigga om misslyckade API-anrop.

Det är viktigt att vi inte loggar kundernas kreditkortsnummer i klartext när vi skickar dem till banken.

Vi använder en API-gateway för att hantera trafiken och strypa hastigheten vid behov.

Ska vi överväga att byta leverantör? Den nuvarande integrationen kräver alldeles för mycket underhåll.

Vi synkroniserar vår databas mot deras system en gång i timmen (cron-jobb).

Deras API är mycket snabbare på att hämta data än vad vårt eget gamla system är.

Har vi fått det formella API-kontraktet påskrivet från deras tekniska avdelning än?

Jag rekommenderar att vi cacher svaret från det externa API:et i fem minuter för att minska svarstiderna.

Det verkar som att vi saknar rätt scope i vår token för att få radera data hos dem.

Vi måste sköta migreringen extremt försiktigt så att vi inte råkar skicka ut dubbla mejl via det nya API:et.

Vi planerar att fasa ut den gamla SOAP-integrationen helt och hållet till förmån för REST.

Token för autentiseringen löper ut efter en timme, så vi måste automatiskt begära en ny (refresh token).

Integrationstesterna lyser grönt, vilket betyder att kommunikationen mellan systemen nu fungerar felfritt.

Det är ofta integrationerna, snarare än den interna koden, som är de mest komplexa delarna av ett projekt.

Tack för det smidiga samarbetet, det är alltid en fröjd att integrera mot välbyggda system.