O integrare Salesforce nu eșuează aproape niciodată din cauza protocolului. Autentificarea este o problemă rezolvată, iar scrierea unei înregistrări la fel. Ce încheie proiectele sunt cota zilnică de apeluri și forma modelului de date, ambele descoperite de obicei la vreo trei săptămâni după lansare, când jobul de noapte începe să returneze erori și nimeni nu poate spune de ce mergea la testare.

Tiparul este suficient de constant încât să poată fi anticipat. Un dezvoltator construiește pe un org Developer Edition, totul trece, clientul semnează. Codul întâlnește apoi un org de producție care conține deja un conector de marketing, o extragere către depozitul de date și un trigger Apex din 2019, iar bugetul de apeluri care părea generos se dovedește a fi un fond comun din care alții cheltuiesc deja.

Articolul acesta aduce surprizele în față: ce API ar trebui să folosiți, cum se calculează cota, ce se întâmplă când scrierea voastră pornește cod pe care nu l-ați scris, cum s-a schimbat autentificarea și ce decizii de model de date sunt scumpe de întors.

Ce decide dacă o integrare Salesforce reușește? Cota și modelul de date, nu protocolul. Cota zilnică de cereri API este valabilă pentru tot org-ul și se calculează din ediție și numărul de licențe, așa că o integrare bine făcută poate fi înfometată de una prost scrisă din același org. Proiectați gruparea în loturi de la prima linie de cod, stabiliți external ID-urile și upsert-ul înainte să se scrie ceva și presupuneți că fiecare înregistrare trimisă va porni codul Apex al altcuiva.

Ce trebuie să nimerească o integrare Salesforce

Sunt patru lucruri și nu cântăresc la fel.

Primul este cota. Fiecare apel sincron făcut de codul vostru se scade dintr-o singură cotă zilnică valabilă pentru tot org-ul și împărțită cu toți ceilalți consumatori ai org-ului.

Al doilea este platforma de dedesubt. Salesforce nu este o bază de date cu o interfață HTTP. Este o platformă de aplicații, iar scrierile voastre execută triggere, flow-uri, reguli de validare, reguli de duplicat și însumări configurate de administratori care nu au auzit niciodată de proiectul vostru.

Al treilea este modelul de date. Lead, Contact, Account și Opportunity nu sunt interschimbabile, conversia între ele merge într-un singur sens și are efecte secundare, iar o alegere greșită înseamnă o migrare de date, nu o schimbare de cod.

Al patrulea este identitatea: cum se înțeleg sistemul vostru și Salesforce asupra înregistrării despre care este vorba. Dacă greșiți, veți crea duplicate cu viteza mașinii. Tot restul de aici decurge din unul dintre aceste patru puncte.

Peisajul API, și de care aveți nevoie de fapt

Salesforce publică o familie largă de API-uri. Indexul API Salesforce este lista de referință, iar numele de mai jos vin de acolo, nu din memorie.

REST API și SOAP API

REST API este alegerea implicită pentru orice are formă de înregistrare: creare, citire, actualizare, ștergere, interogare, descriere. Este alegerea potrivită pentru un formular web care scrie un Lead, pentru un portal care citește Case-urile deschise ale unui client și pentru orice traseu interactiv cu volum mic.

SOAP API face aceeași treabă printr-un WSDL și supraviețuiește pentru că foarte mult middleware de întreprindere îl vorbește nativ și pentru că oferă un contract strict tipizat din care se poate genera un client. Greșeala obișnuită este presupunerea că SOAP e învechit și REST modern. Ambele sunt actuale, iar apelurile SOAP create() și update() acceptă până la 200 de înregistrări fiecare, ceea ce contează mai mult decât formatul de transport.

Bulk API 2.0

Bulk API 2.0 este calea asincronă, bazată pe joburi, pentru volum. Încărcați un CSV, Salesforce îl împarte și îl procesează în fundal, iar voi interogați rezultatele. Limitele Bulk API permit până la 15.000 de loturi pe fiecare 24 de ore glisante și până la 150 de milioane de înregistrări preluate în aceeași fereastră, cu un plafon de 150 MB pe fișierul de job.

Greșeala obișnuită este să tratați Bulk ca pe un reglaj de mai târziu. Este un alt model de programare: rezultatele vin asincron, înregistrare cu înregistrare, iar codul vostru trebuie să le consume așa de la bun început.

Composite și sObject Collections

Acestea două sunt partea cea mai valoroasă și cea mai puțin folosită din REST API. O cerere composite duce până la 25 de subcereri într-un singur apel, dintre care cel mult 5 pot fi interogări sau operații sObject Collections, iar subcererile ulterioare pot referi ID-uri returnate de cele anterioare. sObject Collections tratează până la 200 de înregistrări ale aceluiași obiect într-o singură cerere. Ambele contează ca un singur apel din cota zilnică, și exact acesta este rostul.

Greșeala obișnuită este să nu știți că există. Crearea unui Account, apoi a unui Contact, apoi a unei Opportunity ca trei apeluri succesive costă de trei ori cota unei cereri composite și de trei ori latența.

Streaming, Change Data Capture și Pub/Sub

Streaming API este canalul de abonare bazat pe CometD pentru evenimente PushTopic, generice, Platform și Change. Change Data Capture publică notificări aproape în timp real când înregistrările sunt create, actualizate, șterse sau restaurate, astfel încât un depozit extern poate urmări Salesforce fără interogare periodică. Platform Events sunt propriile voastre definiții de evenimente.

Pub/Sub API este interfața mai nouă, în gRPC și HTTP/2, care adună publicarea, abonarea, obținerea schemei și descoperirea topicurilor într-un singur API, cu încărcături în Avro în loc de JSON. Pentru o construcție nouă bazată pe evenimente, porniți de acolo.

Greșeala obișnuită este să tratați evenimentele ca pe un flux garantat. Ele nu înlocuiesc reconcilierea, din motivul explicat în secțiunea următoare.

Limitele de cereri API sunt constrângerea reală

Aceasta este secțiunea care vă decide arhitectura și este cea citită cel mai des după ce proiectarea s-a încheiat.

Cum se calculează cota zilnică

Documentația privind limitele de cereri API stabilește cota după ediție și numărul de licențe, nu după utilizator sau aplicație. Edițiile Enterprise și Professional cu acces API primesc 100.000 de apeluri plus 1.000 pentru fiecare licență Salesforce sau Salesforce Platform. Edițiile Unlimited și Performance primesc 100.000 plus 5.000 per licență. Developer Edition primește forfetar 15.000, iar un sandbox Full primește 5.000.000.

Din asta decurg două lucruri. Un org Enterprise cu șaizeci de utilizatori are în jur de 160.000 de apeluri pe zi, nu o rezervă nelimitată. Și fiindcă cota derivă din licențe, singurele moduri de a o ridica sunt mai multe licențe de utilizator sau apeluri API cumpărate suplimentar, ambele prin aplicația Your Account de la Salesforce.

Ce se numără și ce se întâmplă când se termină

Cota se măsoară pe totalul tuturor apelurilor primite de org într-un interval de 24 de ore și acoperă împreună REST API, SOAP API, Bulk API, Bulk API 2.0 și majoritatea apelurilor Connect REST API. Apelurile anumitor aplicații conectate ale Salesforce, cum este aplicația mobilă, sunt excluse.

Tocmai însumarea aceasta prinde lumea pe picior greșit. Integrarea voastră nu are un buget al ei. Îl împarte cu conectorul de raportare, cu platforma de marketing și cu orice altă integrare din org, iar un singur consumator prost scris care interoghează la fiecare treizeci de secunde îl poate goli și poate înfometa cod care se poartă impecabil.

Când org-ul își depășește cota, cererile eșuează cu un 403 și REQUEST_LIMIT_EXCEEDED. Salesforce lasă org-urilor de producție plătite o marjă de depășire înainte de a aplica limita strict, însă org-urile de probă și Developer Edition nu primesc nicio îngăduință. Proiectați ca și cum nu ar exista.

Măsurați înainte să vă angajați la un proiect

Cereți administratorului cota org-ului și consumul zilnic actual înainte să scrieți cod; REST API expune o resursă cu limitele org-ului tocmai pentru asta. Dacă cei existenți folosesc deja 70 la sută, o integrare sincronă înregistrare cu înregistrare nu este viabilă, iar reglajele nu o vor face viabilă.

Gruparea în loturi este o decizie de proiectare, nu o optimizare

Odată ce acceptați că este finită și împărțită, cota vă dictează singură proiectarea.

Nu puneți niciodată într-o buclă un apel pentru o singură înregistrare. Un job care creează 5.000 de Contacte pe rând cheltuiește 5.000 de apeluri. Aceleași 5.000 prin sObject Collections, la 200 pe cerere, cheltuiesc 25. Factorul acela de 200 este diferența dintre o integrare care încape în cota unui org mediu și una care nu încape.

Folosiți Composite acolo unde treaba este un graf, nu o listă. Crearea unui părinte și a copiilor lui într-o singură cerere elimină și dus-întorsurile, și starea intermediară pe care codul ar trebui altfel să o țină în timp ce așteaptă un ID.

Folosiți Bulk API 2.0 pentru orice seamănă cu o încărcare sau un export, nu cu o tranzacție. Pentru trasee interactive este greșită, fiind asincronă prin proiectare și neîntorcând niciun răspuns sincron către utilizator.

Păstrați în cache datele de referință. Valorile de picklist, ID-urile de record type și rezultatele describe se schimbă rar și totuși sunt recitite la fiecare rulare fără niciun motiv. Singura schimbare aceasta scoate adesea un sfert din volumul de apeluri al unei integrări naive.

Governor limits: scrierea voastră execută codul altcuiva

Salesforce execută codul Apex scris de clienți în plafoane stricte pe tranzacție. Governor limits Apex care contează pentru o integrare sunt 100 de interogări SOQL pe tranzacție sincronă, 50.000 de înregistrări aduse de SOQL, 150 de instrucțiuni DML, 10.000 de înregistrări procesate de DML, 10 secunde de timp CPU sincron și 6 MB de heap.

Nu voi scrieți acel Apex. Tot în plafoanele acelea intrați, pentru că scrierea voastră de intrare deschide o tranzacție care execută toate triggerele existente pe obiect.

Bulkificarea, fără să scrieți Apex

Ideea merită înțeleasă chiar dacă nu deschideți niciodată un fișier Apex.

Salesforce dă triggerului o colecție de înregistrări, nu una singură. Un trigger scris corect procesează toată colecția cu o interogare și o actualizare. Un trigger scris ca și cum ar primi mereu o singură înregistrare rulează o interogare și o actualizare pentru fiecare înregistrare.

Al doilea trigger funcționează impecabil ani la rând, pentru că utilizatorii salvează câte o înregistrare pe rând din interfață. Apoi integrarea voastră trimite 200 de înregistrări într-o cerere, triggerul își rulează interogarea de 200 de ori, trece de plafonul de 100 de interogări și tot lotul cade.

Bulk API 2.0 procesează datele de intrare în blocuri de 200 de înregistrări, fiecare o tranzacție separată, deci lucrul acesta nu este teoretic. Este forma obișnuită a unei prime încărcări masive într-un org cu istorie.

Ce se poate face

Auditați triggerele și flow-urile de pe fiecare obiect în care veți scrie, înainte să acceptați un termen de livrare. Dacă un trigger nu este bulkificat, cineva trebuie să îl repare, iar acel cineva are nevoie de competențe Apex și de o fereastră de implementare. Treceți-l în buget ca poziție separată.

Acolo unde reparația iese din perimetru, reduceți dimensiunea lotului. Două sute pe cerere este un maxim, nu o obligație, iar coborârea la cincizeci cumpără uneori destul aer cât să livrați în timp ce munca la trigger se planifică. Costă cotă, așa că tratați-o ca pe o măsură temporară.

O autentificare care va merge și la anul

Zona aceasta s-a schimbat semnificativ, iar multe ghiduri publicate sunt acum greșite.

Fluxul OAuth 2.0 cu nume de utilizator și parolă este cel de evitat. Expune datele de acces direct în cerere, Salesforce îl blochează implicit în org-urile mai noi, iar retragerea lui pentru connected apps este programată. Orice integrare care încă îl folosește are nevoie de un plan de migrare cu o dată atașată.

Pentru munca server la server, fără om în buclă, cele două răspunsuri actuale sunt fluxul JWT bearer, care semnează o aserțiune cu un certificat, și fluxul client credentials, care schimbă consumer key și secret pe un token. Ghidul Salesforce despre apelarea API-urilor REST cu utilizatorul de integrare și client credentials spune explicit că fluxul acesta nu emite niciun refresh token, deci clientul cere un access token nou când cel vechi expiră.

Connected apps și external client apps

Recipientul pentru toate acestea a fost connected app. Acum este external client app. Salesforce spune limpede că crearea de connected apps este restricționată începând cu Spring ‘26 și recomandă în locul lor external client apps, descrise ca generația nouă gândită să îmbunătățească securitatea și să rezolve problemele de împachetare.

Dacă documentația voastră de integrare spune “creați o connected app”, descrie un drum pe care org-urile noi s-ar putea să nu îl ofere. Verificați ce se aplică org-ului țintă înainte să estimați lucrarea.

Rulați cu un utilizator de integrare dedicat și planificați rotația

Dați integrării un utilizator propriu, cu un profil cu acces minim și limitat la API. Nu o rulați sub un angajat cu nume. Când angajatul acela pleacă și contul îi este dezactivat, integrarea se oprește, în cel mai prost moment posibil și cu o eroare care nu duce nicăieri.

Certificatele expiră și secretele se rotesc. Amândouă sunt tăcute până în ziua în care nu mai sunt, și amândouă scot o integrare complet din funcțiune, nu parțial. Puneți datele de expirare într-un calendar de care răspunde o persoană, țineți datele de acces într-un manager de secrete și testați rotația într-un sandbox înainte să aveți nevoie de ea la nervi.

Capcanele modelului de date

Acestea sunt cele care costă trei săptămâni, pentru că întoarcerea din ele înseamnă mutat date, nu schimbat cod.

Lead, Contact, Account și Person Account

Un Lead este un potențial client necalificat, încă nelegat de o înregistrare de firmă. Un Contact este o persoană atașată unui Account. Un Account este o organizație. Conversia transformă un Lead într-un Account și un Contact, opțional și cu o Opportunity, iar apelul SOAP convertLead spune explicit că se suprascriu doar câmpurile goale din destinație, așa că numele de câmpuri completate cu grijă pe Lead s-ar putea să nu ajungă unde vă așteptați.

Person Accounts complică lucrurile. Org-urile orientate spre consumatori le activează pentru ca o persoană fizică să fie reprezentată ca Account și Contact la un loc, iar o integrare scrisă pentru un model de Account de firmă nu va funcționa nemodificată pe un org care le folosește. Se descoperă târziu cu o regularitate descurajantă.

Decideți cu partea de business, în scris, în ce obiect se transformă o anumită înregistrare de intrare. Nu este o decizie tehnică.

External ID-uri și upsert

Este singurul mecanism de idempotență sănătos pe care vi-l dă Salesforce și nu ar trebui să fie negociabil. Creați pe obiect un câmp personalizat marcat ca External ID și păstrați acolo cheia primară a sistemului vostru. Puteți folosi apoi operația upsert, un PATCH pe /sobjects/{Object}/{ExternalIdField}/{Value}, care creează înregistrarea când nu se potrivește nimic și o actualizează când se potrivește exact una. Zero potriviri returnează 201, o potrivire returnează 200, iar mai multe potriviri eșuează cu un 300 în loc să ghicească.

Consecința merită spusă limpede. Cu upsert, reîncercarea unei cereri eșuate este sigură. Fără el, fiecare reîncercare este un posibil duplicat, iar o pană de rețea în timpul unui job de noapte devine o curățenie măsurată în zile.

Regulile care se declanșează la scrierile voastre

Regulile de duplicat pot bloca sau semnala înregistrările create de integrarea voastră. Regulile de validare resping înregistrările care nu trec de condiții puse de un administrator. Câmpuri obligatorii pot fi adăugate la luni după livrare, moment în care o integrare care funcționa începe să eșueze la fiecare înregistrare.

Niciuna dintre acestea nu este un defect; org-ul lucrează așa cum este configurat. Greșeala este să tratați o scriere respinsă ca pe o eroare de transport și să reîncercați la nesfârșit, când răspunsul corect este să o duceți la un om, cu motivul la nivel de câmp atașat. Ghidul nostru despre modurile de eșec ale integrărilor cu API-uri terțe acoperă aceeași categorie în altă parte.

Tratarea erorilor, idempotență și reluare

O integrare fără mecanism de reluare devine o reparație manuală de date. Nu este o prezicere, este ce se întâmplă.

Succesul parțial este cazul normal. sObject Collections pune allOrNone pe false implicit, deci o cerere cu 200 de înregistrări poate returna 187 de reușite și 13 eșecuri cu motive individuale, iar Bulk API 2.0 întoarce rezultate pe înregistrare la fel. Codul care verifică doar statusul HTTP exterior va raporta succes în timp ce pierde tăcut înregistrări.

Clasificați eșecurile înainte să reîncercați. Condițiile trecătoare precum blocajele de rând, expirările și cota epuizată merită o retragere exponențială. Eșecurile deterministe precum erorile de validare și câmpurile obligatorii lipsă vor cădea identic la nesfârșit, iar reîncercarea lor arde cotă de care nu vă puteți lipsi.

Fiecare înregistrare irecuperabilă merge într-un depozit de rebut, cu încărcătura și eroarea ei, ca o persoană să o cerceteze și să o retrimită. Fiindcă scrierile voastre sunt cheiate pe un external ID, retrimiterea este sigură. Jurnalizați pe ambele părți corespondența dintre identificatorul vostru și ID-ul Salesforce; peste șase luni jurnalul acela va fi singurul lucru care explică de ce înregistrarea unui client este greșită.

Și reconciliați. Evenimentele Platform și Change rămân 72 de ore în magistrala de evenimente, iar alocările de platform events plafonează livrarea zilnică la 25.000 de evenimente pe Enterprise și 50.000 pe Unlimited și Performance. O comparație programată a numărului de înregistrări și a datelor de modificare prinde ce a pierdut fluxul.

Middleware sau legătură directă

Punct la punct este corect mai des decât recunosc furnizorii de platforme. O sursă, o destinație, un sens, volum modest, un contract stabil: construiți direct și economisiți licența.

Middleware-ul își merită costul când topologia încetează să fie o linie. Mai multe sisteme care schimbă date, transformări pe care utilizatorii de business trebuie să le schimbe fără o implementare, orchestrare între sisteme care cad independent, o nevoie reală de monitorizare și reîncercare centralizate.

Nota onestă este că middleware-ul mută costul, nu îl elimină. Plătiți în continuare maparea, tratarea erorilor și cunoașterea operațională, iar în plus adăugați o licență, o a doua conductă și un al doilea set de competențe de angajat. Cota API nu se schimbă, pentru că middleware-ul apelează aceleași API-uri pe care le-ar fi apelat codul vostru.

Alegeți-l pentru că topologia voastră îl cere, nu pentru că pare să reducă din cod. Ghidul nostru pentru decizia de a construi sau de a cumpăra parcurge același compromis pentru sistemele de dedesubt, iar ghidul de integrare CRM și ERP acoperă cazul cu mai multe sisteme. Dacă vreți asta evaluată, nu dezbătută, de acolo pornesc proiectele noastre de dezvoltare software.

Sandbox-uri, implementare și versiuni de API

Construiți într-un sandbox. Niciodată pe producție și niciodată pe un org Developer Edition care nu împarte configurația de producție, pentru că tocmai configurația vă va rupe.

Înțelegeți ce face un refresh. Înlocuiește sandbox-ul cu o copie proaspătă din producție, deci orice date de test care existau doar acolo dispar. Ce trebuie să supraviețuiască unui refresh trebuie scriptat și făcut reluabil. Echipele învață asta pierzând o săptămână de date de test.

Fixați explicit versiunea de API în fiecare traseu de cerere și cunoașteți politica de retragere. Politica Salesforce de încheiere a vieții API-urilor se angajează să susțină fiecare versiune cel puțin trei ani și să anunțe clienții cu cel puțin un an înainte de încetarea suportului. Versiunile de la 21.0 la 30.0 au fost retrase în Summer ‘25, iar cererile către o versiune retrasă întorc 410 Gone.

Este o oprire seacă, nu o degradare, și de aceea fixarea versiunii aparține planului vostru de întreținere. Aceeași disciplină se aplică oricărui API pe care îl publicați voi, cum arată articolul nostru despre versionarea API.

Protecția datelor în Regatul Unit și datele din CRM

Un CRM este aproape în întregime date cu caracter personal: nume, angajatori, numere de telefon, adrese de e-mail, notițe despre discuții. Mutarea lor între sisteme este prelucrare în sensul UK GDPR.

Prima întrebare este cine este operatorul. Ghidul ICO despre operatori și persoane împuternicite definește operatorul ca partea care stabilește scopurile și mijloacele prelucrării, iar persoana împuternicită ca cea care prelucrează în numele operatorului. Când o agenție construiește și operează o integrare pentru voi, agenția aceea este de regulă persoană împuternicită, iar un contract scris care îndeplinește cerințele articolului 28 este obligatoriu, nu opțional.

A doua este transferul internațional. Org-urile Salesforce și orice middleware pot sta în afara Regatului Unit, iar ghidul ICO despre transferurile internaționale prezintă mecanismele disponibile și cazurile în care este nevoie de o evaluare a riscului de transfer. Stabiliți unde ajung datele înainte să semnați.

Din asta decurg trei consecințe. Nu copiați câmpuri de care nu aveți nevoie, pentru că minimizarea este deopotrivă o cerință legală și mai puțină muncă de mapare. Nu puneți date personale de producție într-un sandbox fără o decizie asumată. Și asigurați-vă că ștergerea se propagă, pentru că un contact șters în Salesforce și lăsat intact în depozitul vostru de date este o problemă de conformitate în viață, iar același lucru este valabil și când agenții AI ajung la acele înregistrări.

Cât costă o integrare Salesforce

Salesforce își publică prețurile de ediții și licențe pe propriile pagini, iar noi nu dăm nicio cifră pentru ele aici, pentru că numărul care guvernează proiectarea integrării este cota API pe care o produc licențele, nu prețul de listă.

Cifrele de mai jos sunt estimările proprii ale Mecanik pentru servicii profesionale în Regatul Unit, nu prețuri de la furnizor, și presupun un org deja existent, cu un administrator care poate răspunde la întrebări.

O integrare simplă într-un singur sens, un formular web care creează un Lead cu external ID și tratare rezonabilă a erorilor, ajunge de obicei la GBP 3.000 până la GBP 7.000. O sincronizare bidirecțională a unuia sau două obiecte, cu rezolvarea conflictelor și un job de reconciliere, costă de regulă între GBP 15.000 și GBP 40.000. O integrare bazată pe evenimente pe Pub/Sub, cu reluare, tratarea rebuturilor și monitorizare, aterizează în general între GBP 30.000 și GBP 80.000.

Ce ar trebui să conțină livrarea

Un document de mapare la nivel de câmp agreat cu partea de business, nu dedus. Un external ID pe fiecare obiect sincronizat. Tratarea erorilor cu depozit de rebut și proces de retrimitere documentat. Un job de reconciliere. Monitorizarea consumului de API față de cota org-ului, cu alerte mult sub plafon. Proceduri scrise pentru rotația tokenurilor, expirarea certificatelor și reluare. Configurație de sandbox scriptată, ca să supraviețuiască unui refresh. O integrare fără acestea este un prototip, orice ar scrie pe factură.

Costul recurent

Alocați între GBP 400 și GBP 1.500 pe lună pentru monitorizare, cele trei lansări Salesforce pe an, rotația datelor de acces și schimbările de câmpuri pe care un administrator le va face fără să vă spună. Org-urile care finanțează asta sunt org-urile în care integrările continuă să funcționeze.

Cum se ajunge la construit

Modurile de eșec de aici sunt plictisitor de constante: cotă descoperită târziu, un trigger pe care nu l-a auditat nimeni, un Lead care ar fi trebuit să fie un Contact, niciun mod de a relua un lot căzut. Toate patru sunt ieftin de prevenit la proiectare și scump de reparat odată ce există înregistrări reale.

Mecanik construiește și întreține integrări Salesforce ca parte a muncii noastre de dezvoltare software, pornind de la un audit al cotei, triggerelor și modelului de date din org înainte să se scrie o linie de cod. Pentru o bucată de lucrare de integrare bine definită, nu un proiect întreg, puteți angaja direct un dezvoltator web.

Întrebări frecvente

Câte apeluri API primește pe zi o integrare Salesforce? Depinde de ediție și de numărul de licențe, iar cota este valabilă pentru tot org-ul, nu pentru fiecare integrare. Edițiile Enterprise și Professional cu acces API primesc 100.000 de apeluri plus 1.000 pentru fiecare licență Salesforce sau Salesforce Platform, Unlimited și Performance primesc 100.000 plus 5.000 per licență, iar Developer Edition primește forfetar 15.000 într-un interval glisant de 24 de ore.

Pentru Salesforce folosesc REST API sau Bulk API? Folosiți REST API pentru munca interactivă, cu volum mic și formă de înregistrare, și Bulk API 2.0 pentru încărcări și exporturi unde volumul este mare și un răspuns asincron este acceptabil. Pentru orice se află la mijloc, sObject Collections cu 200 de înregistrări pe cerere și Composite cu 25 de subcereri pe cerere contează fiecare ca un singur apel din cotă și scot cea mai mare parte din presiune.

Ce flux OAuth ar trebui să folosească o integrare Salesforce de la server la server? Fluxul JWT bearer sau fluxul client credentials, rulate ca utilizator de integrare dedicat, limitat la API. Fluxul cu nume de utilizator și parolă este blocat implicit în org-urile mai noi și programat pentru retragere, deci nu ar trebui folosit la lucrări noi. Rețineți și că, începând cu Spring ‘26, crearea de connected apps este restricționată, iar Salesforce recomandă acum external client apps.

De ce eșuează integrarea mea Salesforce doar la loturile mari? Aproape întotdeauna din cauza unui trigger Apex care nu a fost bulkificat. Salesforce dă triggerelor o colecție de înregistrări, iar un trigger scris ca și cum ar primi câte una pe rând își va rula interogările o dată pentru fiecare înregistrare, depășind limita de 100 de interogări SOQL când sosește lotul vostru. Pentru utilizatorii din interfață care salvează pe rând merge perfect, și de aceea a rămas nedescoperit.

Am nevoie de middleware ca să mă integrez cu Salesforce? Nu pentru o integrare cu o sursă, o destinație și un singur sens, la volum modest, unde construitul direct este mai ieftin și mai simplu. Middleware-ul își merită costul din momentul în care mai multe sisteme schimbă date, utilizatorii de business trebuie să schimbe mapări fără o implementare sau aveți nevoie de orchestrare și reîncercare centralizate. Mută costul, nu îl elimină, și nu vă crește cota API.