Shopify a introdus o limită nouă pentru Customer Account API: 3000 de cereri pe minut pentru fiecare client, în fiecare magazin, iar plafonul este partajat între toate aplicațiile instalate care apelează acest API. Concret, dacă un magazin are cinci aplicații care vorbesc cu Customer Account API, toate cele cinci contribuie la același buget de 3000 de cereri pe minut pentru un singur cumpărător. Limita se adaugă peste plafonul existent bazat pe cost al API-ului, nu îl înlocuiește. Când plafonul este depășit, API-ul returnează HTTP 429 Too Many Requests, cu eroarea THROTTLED și un header Retry-After. În majoritatea cazurilor nu e nevoie de nicio modificare, pentru că traficul obișnuit de cumpărători rămâne mult sub acest prag. Sursa: Shopify Changelog.

Ce s-a schimbat exact și de ce contează

Până acum, discuția despre rate limiting în ecosistemul Shopify se învârtea în jurul plafoanelor bazate pe cost, adică un model în care fiecare cerere „consumă" dintr-un bucket de puncte care se reîncarcă în timp. Noul mecanism este diferit prin construcție: nu mai vorbim despre un buget global al aplicației, ci despre un buget per client final. Este o schimbare de perspectivă importantă. Protecția nu mai este orientată spre dezvoltator, ci spre cumpărătorul individual.

Trei consecințe practice decurg direct din textul anunțului:

  1. Plafonul este partajat. Nu contează câte aplicații are magazinul. Toate trag din aceeași limită de 3000 de cereri pe minut pentru un client dat. O aplicație „gălăgioasă" poate epuiza bugetul pentru toate celelalte, dacă rulează pe același client în același interval.
  2. Se cumulează cu limita existentă. Nu e o relaxare mascată. Rămâne și plafonul bazat pe cost, iar noul plafon per client se aplică în plus.
  3. Răspunsul la depășire este standard și explicit. HTTP 429, eroarea THROTTLED, header Retry-After. Adică serverul îți spune exact cât să aștepți, dacă implementarea ta citește header-ul.

Partea care merită subliniată pentru echipele tehnice: anunțul spune clar că în majoritatea cazurilor nu este necesară nicio acțiune, pentru că traficul normal de cumpărători rămâne mult sub prag. Aceasta este o constatare a furnizorului, nu o garanție universală. Ea descrie comportamentul tipic, nu comportamentul fiecărei integrări.

Ce înseamnă asta pentru aplicațiile care ating Customer Account API

Diferența dintre o aplicație care doarme liniștită și una care începe să piardă cereri nu stă în volumul mediu de trafic. Stă în vârfuri. Media de trafic nu declanșează niciodată un rate limit. Vârfurile o fac.

Gândește-te la scenarii reale de comerț electronic. Un flash sale care începe la ora fixă. O campanie de email trimisă către o listă mare, care aduce mii de oameni în cont simultan. Un eveniment de tip Black Friday, când autentificarea, verificarea stării comenzii și actualizarea datelor de cont se suprapun. Sau, mai subtil, un client care, printr-un client de email sau un tool de automatizare, generează cereri repetate pentru același cont.

Aici intervine nuanța pe care o ratăm dacă citim anunțul pe diagonală. Limita este per client, nu per magazin. Un magazin cu un milion de clienți nu are o problemă dacă fiecare client generează câteva zeci de cereri pe minut. Problema apare când un singur client generează mii de cereri pe minut, ceea ce înseamnă aproape întotdeauna fie o eroare de implementare, fie un client care rulează un script, fie o buclă de retry agresivă.

Prin urmare, întrebarea de verificat nu este „cât trafic am", ci „ce se întâmplă când același client face multe cereri foarte repede". Răspunsul stă în logica de retry și de backoff, nu în arhitectura generală a aplicației.

Ce trebuie să facă concret o aplicație, pas cu pas

Anunțul enumeră trei cerințe pentru logica de retry. Le transformăm în pași operaționali, pentru echipele care vor să verifice dacă sunt expuse:

  1. Detectează HTTP 429. Pare banal, dar multe SDK-uri și wrapper-e tratează 429 ca pe o eroare generică, o aruncă mai departe și nu o tratează distinct. Verifică dacă 429 ajunge într-o ramură dedicată de cod, nu într-un catch-all.
  2. Citește header-ul Retry-After. Acesta este momentul cel mai important. Serverul îți comunică durata de așteptare. Dacă aplicația ta ignoră acest header și folosește un backoff fix sau, mai rău, un retry imediat, vei agrava situația: vei lovi din nou plafonul și vei consuma buget din nou.
  3. Așteaptă durata indicată, apoi reîncearcă. Retry-ul trebuie să respecte valoarea din Retry-After, nu o presupunere proprie.
  4. Verifică ce se întâmplă cu cererile pierdute. Dacă retry-ul eșuează definitiv, ce se întâmplă cu acțiunea cumpărătorului? Rămâne într-o coadă? Se pierde? Utilizatorul primește un mesaj clar? Această întrebare nu are răspuns în anunț, dar este exact locul unde apar incidentele reale.
  5. Documentează comportamentul în timpul vârfurilor. Nu ai nevoie de un studiu formal, ai nevoie să știi dacă aplicația ta poate distinge un vârf legitim de un ciclu de retry care se auto-alimentează.

Un punct de atenție metodologică, care se aplică oricărei verificări tehnice de acest tip: dacă nu ai observat niciodată erori 429, asta nu dovedește că logica ta de retry este corectă. Poate însemna doar că nu ai avut încă un vârf care să o pună la încercare. Absența unei erori nu este dovada robusteții. Pentru o evaluare serioasă ai nevoie de log-uri, nu de impresii.

Ce înseamnă pentru tine, antreprenor sau marketer român

Dacă ai un magazin online pe Shopify și folosești câteva aplicații de cont client, newsletter, program de loialitate sau suport, această schimbare probabil nu te va atinge direct în operațiunea de zi cu zi. Traficul tău normal, chiar și într-o zi bună, rămâne mult sub 3000 de cereri pe minut pentru un singur client. Nu trebuie să scrii cod. Nu trebuie să migrezi nimic.

Ce trebuie să faci, în schimb, este să pui o întrebare furnizorilor tăi de aplicații. Nu una tehnică, ci una simplă, de business: „cum vă asigurați că, în timpul unui vârf de trafic sau al unei campanii mari, nu pierdeți acțiuni de client din cauza rate limiting-ului?" Este o întrebare legitimă, mai ales dacă rulezi campanii de email sau promoții cu ferestre scurte, unde orice secundă de indisponibilitate se traduce în coșuri abandonate.

Pentru echipele de marketing, implicația este mai ales de planificare. Când programezi o campanie majoră, verifică dacă aplicațiile din stack-ul tău au fost actualizate pentru comportamentul de retry cerut de Shopify. Dacă lucrezi cu un dezvoltator intern sau cu o agenție, pune întrebarea înainte de campanie, nu după. Costul unei verificări este de câteva ore. Costul unei campanii în care contul clienților nu se încarcă este cu totul altceva.

Aici se leagă și de discuția mai largă despre GEO și vizibilitate: cum urmărești sursele citate de AI cu Semrush este un exemplu de instrument care îți arată ce spun motoarele despre brandul tău, dar niciun instrument nu compensează un checkout sau un cont de client care nu se încarcă în timpul vârfului. La fel, dacă folosești email tranzacțional, presiunea pe infrastructură în momentele de vârf este o temă recurentă, de care se leagă și discuția despre SMTP tranzacțional sub presiunea inboxului.

Ipoteze, nu concluzii: ce nu știm încă

Este important să separăm ce spun datele de ce presupunem noi. Anunțul confirmă existența limitei, valoarea de 3000 de cereri pe minut per client, partajarea între aplicații, codul de răspuns 429 și header-ul Retry-After. Acestea sunt fapte confirmate de sursă.

Ce nu știm din materialul furnizat: dacă limita a fost deja întâlnită în practică de aplicații reale, cât de des este atinsă în magazine cu volum mare, dacă există praguri diferite pe planuri sau regiuni, sau dacă Shopify oferă instrumente de monitorizare dedicate. Nu avem date despre asta. Orice afirmație de tipul „această aplicație va pierde clienți" sau „vânzările tale vor scădea" ar fi o speculație, nu o concluzie. Nu o facem.

Ceea ce putem spune cu certitudine este că anunțul are o structură tipică de schimbare „low-touch": majoritatea utilizatorilor nu fac nimic, minoritatea care are retry logic defectuos trebuie să o repare. Iar acea minoritate este exact segmentul care află de problema abia când apare incidentul.

FAQ

Se aplică limita și dacă am o singură aplicație instalată pe magazin? Da. Limita este per client, per magazin, indiferent de câte aplicații apără Customer Account API. O singură aplicație poate atinge plafonul, la fel cum mai multe îl pot atinge împreună.

Ce fac dacă nu am văzut niciodată erori 429? Absența erorilor 429 nu dovedește că logica ta de retry este corectă. Înseamnă doar că nu ai întâlnit încă un vârf care să o testeze. Dacă aplicația ta apelează Customer Account API, verifică implementarea retry-ului pe baza documentației, nu pe baza impresiei că „nu s-a întâmplat nimic până acum".

Trebuie să schimb ceva în stack-ul meu de marketing? Cel mai probabil nu. Întrebarea utilă nu este dacă schimbi ceva, ci dacă furnizorii aplicațiilor tale tratează corect erorile 429 și header-ul Retry-After, mai ales în timpul campaniilor mari. Este o verificare de furnizor, nu o migrare de platformă.

AI-ul ajută, dar decizia și execuția rămân umane

Un asistent AI poate face parte din proces foarte bine: poate citi documentația, poate genera un checklist de verificare pentru logica de retry, poate scrie teste care simulează un răspuns 429 și poate analiza log-urile pentru tipare de cereri repetate. Toate acestea economisesc timp real.

Ce nu poate face AI-ul este să decidă pentru tine dacă aplicația ta este expusă, să interpreteze un incident în contextul campaniei tale și să răspundă de impactul asupra clienților tăi. Rate limiting-ul nu este o problemă de cod izolată, ci o problemă de operare: cine răspunde când un client nu își poate accesa contul în mijlocul unei promoții. Acea decizie rămâne la media buyer, la omul care cunoaște calendarul campaniilor și prioritățile business-ului, nu la un script.

Iar pasul concret, de la verificare la implementare, îl face echipa. La ALLSoft Agency traducem exact această separare în practică: AI-ul pentru analiză și planificare, omul pentru decizie, agenția pentru execuție. Fără hype, fără promisiuni pe care nu le putem susține cu date.