Integrarea care se rupe în tăcere: de ce un webhook nu e o integrare
Un script care trimite apelurile în CRM merge perfect până la prima eroare de rețea. Ce trebuie să aibă o legătură între centrală și softul tău ca să nu descoperi peste o lună că lipsesc date.
Cele mai multe integrări între o centrală telefonică și un CRM arată la fel: cineva a scris cândva un script care ia apelurile și le trimite mai departe. A mers. Toată lumea a fost mulțumită.
Apoi, într-o marți, serverul de CRM a fost repornit pentru un update. Trei minute. Scriptul a trimis în gol, n-a primit răspuns, și a mers mai departe la următorul apel.
Nimeni n-a aflat nimic. Peste o lună, cineva a observat că raportul nu bate.
Ce lipsește, de fapt
Nu API-ul. Nu formatul datelor. Lipsesc lucrurile care se văd abia când ceva nu merge:
Ce s-a întâmplat cu ce n-a ajuns? Un POST care a primit 502 e o informație. Dacă nu o scrii undeva, nu s-a întâmplat niciodată. O integrare serioasă are un jurnal al livrărilor: ce a plecat, ce a răspuns serverul tău, ce cod, și când e următoarea încercare.
Cine reîncearcă? Și, mai important, cum. O reluare imediată, la infinit, transformă o defecțiune de trei minute într-un atac asupra propriului tău server. Reîncercarea trebuie să crească intervalul, iar după prea multe refuzuri să se oprească singură câteva minute înainte să reia.
Ce se pierde definitiv? Trebuie să existe un răspuns explicit, nu o tăcere. Un rând marcat „Renunțat“, vizibil, pe care poți da clic. Restul se recuperează.
Cum recuperezi? Ăsta e miezul: dacă singurul tău canal e trimiterea, orice minut de indisponibilitate e o gaură permanentă în date. De aceea prima întrebare la orice integrare nu e „îmi trimiteți apelurile?“, ci „pot să vă cer eu ce am pierdut?”.
Ordinea corectă a canalelor
Din experiența noastră, integrările care rezistă arată așa:
1. API-ul de istoric e temelia. Tu ceri apelurile, pe ce perioadă vrei, cu filtre. E plictisitor și nu impresionează pe nimeni la demo, dar e singurul canal care nu poate „pierde“ nimic — datele stau acolo și le ceri când vrei. Îl folosești pentru sincronizări de noapte, pentru rapoarte, și pentru reparat orice a ratat alt canal.
2. Timpul real e stratul de deasupra. Ăsta e cel care impresionează: fișa clientului se deschide singură când sună. Merită, dar construit peste temelie, nu în locul ei.
3. Fișierul periodic e pentru cine nu are programator. Un CSV pe email, pe programul tău. Se deschide în Excel, intră în contabilitate, nu cere nicio linie de cod. Nu e o soluție de mâna a doua — e soluția potrivită pentru o categorie întreagă de firme.
4. Înregistrările sunt o discuție separată. Un răspuns cu metadate are kiloocteți; unul cu sunet are megaocteți, iar aducerea lui ocupă centrala clientului, nu serverul furnizorului. Orice sistem care le tratează la fel cu celelalte fie n-a ajuns încă la scară, fie o să te limiteze fără să-ți spună de ce.
Capcana pe care o vedem cel mai des
Adresa.
Portalul unui furnizor de servicii e, aproape întotdeauna, servit printr-un strat de protecție făcut pentru browsere — verificări de robot, provocări în JavaScript, reguli care presupun că de partea cealaltă e un om cu un mouse. Un browser trece prin ele fără să observe. O integrare între două servere nu trece niciodată.
De aceea adresa de integrare se ia din documentație, nu din bara de adrese a portalului. La noi e cool.pbxtools.ro, scrisă literal, separată de portal exact din motivul ăsta.
Dacă furnizorul tău îți dă aceeași adresă și pentru interfață și pentru API, întreabă-l ce se întâmplă când pune protecție anti-bot.
Și partea de care nu vorbește nimeni: factura
O integrare pe consum are un risc pe care furnizorii îl trec sub tăcere: un script rupt la tine, care intră într-o buclă, poate genera într-o noapte un consum pe care nu-l aștepta nimeni.
Răspunsul corect nu e „aveți grijă“. E un plafon dur care oprește servirea, plus consumul vizibil zi de zi, cu aceleași cifre pe care le vede și furnizorul. Nu afli la factură ce ai folosit.
Ce facem noi
PBX Connect e exact cele patru canale de mai sus, în ordinea aia, cu jurnalul, reluarea în trepte, plafonul și consumul la vedere. Cheile de API se văd o singură dată, se revocă individual, iar dreptul de a citi metadate e separat de dreptul de a descărca sunet — o cheie de raportare nu ajunge niciodată la conținutul conversațiilor.
Pentru integratorii care administrează o centrală cu mai multe firme: fiecare firmă are cheile ei și vede doar apelurile ei, apărat la nivel de date, nu doar în interfață.
Are un tarif lunar pe firmă, cu toate cele patru canale incluse — descărcarea înregistrărilor între ele — și cu o cotă de trafic în el. Nu se plătește pe extensie și nici pe apel. Merge pe centralele bazate pe Asterisk — FreePBX, VitalPBX și centraletelefonice.ro PBX, inclusiv cu mai multe firme — și pe cele custom. FusionPBX e în lucru. Iar dacă tu ai altceva, spune-ne — construim la cerere, așa a intrat fiecare platformă de pe listă.