- Användaren väljer kontakt
- Er server kontrollerar åtkomst
- Anrop till telefoni-API
- Status kopplas till försöket
- Resultatet visas i appen
Principbild av kundens integration, inte ett löfte om en färdig systemkoppling.
1. Skilj samtalsstyrning från ljud
Ett HTTP-anrop kan initiera eller påverka ett samtalsflöde utan att webbläsaren själv är telefonen. Om ljudet ska gå genom datorns mikrofon och högtalare behövs även en stödd medieanslutning och ett användargränssnitt för den.
Rita därför två enkla flöden: vägen för kommandot och vägen för ljudet. Det hindrar er från att välja en teknik som löser knapptryckningen men inte användarens faktiska samtal.
2. Lägg integrationens ansvar på servern
Webbläsaren skickar användarens avsikt till er backend. Servern kontrollerar vem användaren är, vilket företag den tillhör och vilka åtgärder som är tillåtna. Servern håller leverantörens hemligheter och väljer rätt kundkontext.
Ett kund-ID som kommer från webbläsaren är inte i sig ett behörighetsbevis. Kontrollera relationen till sessionen innan ett API-anrop utförs. Visa begripliga fel i appen utan att skicka tillbaka känsliga uppgifter från leverantörens svar.
3. Gör första steget läsbart och ofarligt
Börja med att läsa en resurs som testkontot har rätt att se. Telnect-projektets API-referens innehåller exempelvis GET /v1/SelfAdmin/subscriptions. Det visar om anslutning och behörighet fungerar utan att ni behöver skapa ett samtal.
När läsningen är verifierad kan ni planera ett separat samtalstest med avsedda testnummer. Kontrollera faktiska parametrar och åtgärder i kontraktet. Ett inkommet HTTP-svar betyder inte automatiskt att mottagaren har svarat.
4. Visa ett ärligt tillstånd i gränssnittet
- Begäran pågår: förhindra oavsiktliga dubbeltryck.
- Begäran accepterad: visa att samtalsförsöket har startat.
- Besvarat eller avslutat: uppdatera utifrån verifierad information.
- Okänt resultat: läs status innan en ny trafikalstrande begäran skickas.
5. Testa avbrotten
Prova upptaget, felaktigt nummer, timeout och nekad åtkomst. Låt användaren förstå skillnaden mellan ett misslyckat API-anrop och ett samtal som inte besvaras. Kontrollera även vad som händer om sidan laddas om mitt i försöket.
Spara en intern korrelationsreferens som gör det möjligt att följa ett test genom era system. Håll testloggar fria från hemligheter och onödigt samtalsinnehåll. Avsluta med att dokumentera vad som är verifierat och vilka delar som återstår.
Bygg gränsen mellan webbläsare och server
Låt webbläsaren skicka användarens avsikt och en intern kontaktreferens till er server. Servern kontrollerar session, behörighet och tillåtet mål innan den gör ett leverantörsanrop. En beständig referens binder ihop användarens knapptryckning med leverantörens samtals-ID.
Visa minst väntar, pågår, avslutat och kunde inte bekräftas. Det sista tillståndet behövs när en begäran kan ha nått leverantören men svaret försvann. Inaktivera upprepade knapptryckningar i gränssnittet, men lägg det verkliga dubblettskyddet på servern.
Kontrollera anrop och samtalshändelser · Testa avbrott och återförsök
Felsök ett första samtalsflöde
| Symtom | Kontroll | Nästa steg |
|---|---|---|
| Åtkomst nekas | Rätt konto, rättighet och resurs | Korrigera åtkomsten innan nytt försök |
| Begäran får inget svar | Intern referens och eventuell leverantörsreferens | Stäm av status innan ni upprepar en skrivning |
| Samtalet har fel kundkoppling | Kund-ID och matchningsbeslut | Stoppa automatisk CRM-skrivning och granska |
| Samtalet syns men ljud saknas | Vald röstkanal, enhet och anslutning | Felsök ljudvägen separat från API-status |
Underlag och avsändare
Guiderna beskriver tekniska mönster. Syntetiska exempel är märkta och ersätter inte verifiering av er anslutning.