Acasă/Metode

E-commerce · Rețele sociale

Programarea postărilor pe rețele sociale prin API: de ce „programat” nu înseamnă „publicat”

Un API de programare care răspunde HTTP 200 a acceptat postarea, nu a publicat-o; publicarea vine mai târziu și poate pica separat pe fiecare rețea. În perioada măsurată, posterul nostru a raportat succes la fiecare rulare, în timp ce toate cele 17 postări pe Facebook și 12 pe Instagram au picat. Acum citim starea finală pe fiecare rețea după ora publicării, punem expirare pe orice listă de conturi conectate ținută în cache și verificăm descrierile generate în cod, pe textul care chiar pleacă.

Actualizat 2026-10-11

Ce înseamnă „programat” și „publicat” într-un API de postare

Când programezi o postare pe rețele sociale printr-un API, un răspuns 200 înseamnă că planificatorul a acceptat cererea, nu că vreo rețea a publicat postarea. Publicarea are loc la ora programată, separat pentru fiecare rețea (TikTok, Instagram, Facebook, YouTube), și fiecare poate pica fără să schimbe răspunsul pe care l-ai salvat în log. Ca să știi dacă o postare a plecat, cere planificatorului starea finală pe fiecare rețea după ora publicării.

Publicăm clipuri verticale scurte pentru mai multe branduri de magazin printr-un serviciu extern de programare: o cerere API duce un clip, o descriere și o listă de rețele, iar serviciul publică pe fiecare la ora aleasă. Pentru unele pagini postăm și direct prin Graph API de la Meta. Diferența dintre acceptat și publicat e valabilă pe ambele drumuri.

Cum funcționează lanțul nostru de postare

1. Sursa. Clipurile editate vin dintr-un drive comun, un folder pe brand. Un model cu viziune se uită la fiecare clip și întoarce calitatea, dacă e pe brand, dacă are watermarkul altui brand și o descriere propusă. Fiecare verdict, inclusiv respingerile, e salvat cu ID-ul fișierului drept cheie, ca niciun clip să nu fie descărcat sau evaluat de două ori.

2. Filtrul de format. Trece doar videoul vertical adevărat: înălțimea mai mare decât lățimea și lățimea împărțită la înălțime cel mult 0,65, adică 9:16. Clipurile pătrate, 4:5 și orizontale primesc bare de la platforme. O a doua verificare întreabă modelul dacă barele sunt arse în imagine, de exemplu un clip orizontal pus pe o pânză verticală. Dublurile se potrivesc pe nume normalizat plus durată; un clip fusese urcat de 8 ori, cu nume puțin diferite.

3. Coada. Un job zilnic de reumplere completează coada fiecărui brand când scade sub un minim (la început 3 elemente, completate până la 5; acum 4, până la 7). Un brand fără nimic nou în folder nu costă nimic și se reia singur când apare conținut.

4. Postarea. Un job zilnic golește coada prin rotație și programează postările zilei la ore fixe. Reumplerea și posterul folosesc același lacăt, fiindcă un picker și un poster care scriau coada în același timp suprascriau marcajele „postat”. Un registru separat cu ce s-a postat pe fiecare brand e sursa de adevăr când coada se strică.

5. Verificarea. După ora publicării se citește înapoi starea fiecărei rețele. Pasul ăsta lipsea la început, iar secțiunea următoare arată cât ne-a costat.

Eșecul: HTTP 200 la fiecare rulare, nimic pe două rețele

În perioada măsurată, logul posterului arăta HTTP 200 la fiecare rulare. Starea pe fiecare rețea spunea altceva: TikTok 17 din 17 publicate, YouTube 11 din 11 publicate, Facebook 17 din 17 eșuate, Instagram 12 eșuate. Răspunsul din log era al cererii de programare; publicarea se petrecea mai târziu, pe fiecare rețea, iar rezultatul ei nu ajungea niciodată în log.

Cauza de dedesubt era un cache. Lista noastră de branduri și rețele conectate era un fișier local vechi de 2 luni, citit fără expirare, așa că posterul trimitea mai departe spre Facebook și Instagram la branduri ale căror conexiuni căzuseră. Același cache vechi a făcut și alt rău: un profil redenumit pentru altă afacere și-a păstrat ID-ul intern, iar conținut destinat vechii afaceri a fost publicat pe profilul redenumit.

Reparația are trei părți. Cache-ul de rețele conectate expiră acum după 12 ore și cade pe copia veche doar când API-ul nu răspunde. Starea finală a fiecărei rețele e citită înapoi de la planificator; cererea vrea date și ore în format ISO complet, fiindcă un format compact de dată întoarce 400. Iar când o postare pe toate rețelele pică, se reîncearcă fără YouTube, ca o rețea care respinge un clip să nu le tragă după ea pe celelalte.

Cererea care ne-a adus aici a fost „postează mai des”. Dacă am fi crescut doar frecvența, am fi înmulțit postările eșuate și am fi raportat succes.

Descrierile: modelul le scrie, codul le verifică

O descriere generată dintr-un clip poate repeta ce spune omul din clip. Pe un clip cu un creator care vorbea la cameră și se prezenta cu numele, modelul a scris descrierea ca și cum contul brandului ar fi fost acea persoană, iar numele a devenit un substantiv comun fără sens. A plecat pe trei rețele, iar pe YouTube descrierea devine titlu, tăiat la mijlocul cuvântului. O scanare a cozii a găsit un astfel de caz la circa 90 de descrieri. Descrierile la persoana întâi, ca un client anonim („am testat”), rămân permise; prezentarea cu nume, nu.

Regula stă acum în două locuri: în prompt și într-o verificare pe rezultat, care cere o rescriere și respinge clipul dacă nici rescrierea nu trece. Scrierea verificării a avut capcana ei. O expresie regulată fără diferențiere între majuscule și minuscule a transformat tiparul „nume cu majusculă” în „orice cuvânt”, iar prima scanare a raportat 23 de descrieri stricate, când era una singură. Testează o verificare pe exemple bune și rele înainte s-o crezi.

Numele de brand și de produs se corectează determinist, după model și înainte de coadă, fiindcă modelul le tot stâlcea: numele unei linii de produse a plecat cu o literă greșită pe trei rețele, iar o a treia variantă aștepta în coadă. Greșelile cunoscute se înlocuiesc exact; o potrivire aproximativă de cel puțin 0,82 le prinde pe cele noi, doar pe cuvinte cu majusculă, fiindcă într-o rulare pe uscat cuvinte obișnuite, scrise cu literă mică, erau destul de apropiate de nume de brand încât să fie „corectate”. Lista de nume corecte vine din titlurile de produs din magazin, nu din memorie. O descriere corectată sau respinsă trebuie reparată și în cache-ul de verdicte, altfel revine la următoarea reconstruire.

Corectează textul care chiar pleacă

Aceeași lecție a venit dintr-un alt lanț de text al nostru, răspunsurile propuse pentru relații cu clienții, și se aplică și descrierilor. Un corector determinist rula o singură dată, la intrarea într-un lanț de verificări, în timp ce cel puțin cinci pași de după rescriau textul, unii regenerându-l cu un model. Aceeași greșeală a revenit de trei ori, pe trei căi diferite, și de fiecare dată am crezut că e reparată. Diagnosticul a venit când am rulat corectorul de mână pe textul final: îl repara, deci textul nu trecuse niciodată prin el.

Corectorii determiniști pentru nume, punctuație și formule fixe stau la ieșirea comună, pe textul care se publică. Dacă sunt idempotenți, rulează-i și la intrare, și la ieșire. Un verificator care respinge o regenerare nu e un corector: nu curăță prima variantă.

Orare, fusuri orare, plafoane ascunse și regulile platformelor

Fusul orar. Ceasul serverului era cu o oră în urma orei locale, deci „acum” etichetat cu fusul local era cu o oră în trecut, iar planificatorul respingea sloturile apropiate ca fiind în trecut. Orele se calculează acum într-un fus explicit, independent de ceasul sistemului.

Plafonul ascuns. Posterul ia primele N ore dintr-o listă de ore de postare, deci numărul de postări pe zi nu poate depăși numărul de ore din listă: cu 13, 15, 18 și 20, maximul e 4, orice ar scrie în setarea de sloturi. Orele adăugate trebuie să fie după 10, ora la care rulează jobul zilnic, altfel programul zilei se golește și alunecă pe mâine. Am crescut frecvența de la 1, 2 și 3 postări pe zi (celelalte zile, vineri, sâmbătă) la 2, 3 și 4, adică de la 10 la 17 postări pe săptămână, pe 15 branduri în rotație.

Două canale pentru un brand. Un brand are două canale YouTube; planificatorul publică pe unul, iar tokenul nostru de administrare e pe celălalt, deci un titlu greșit nu se poate repara prin API. O verificare a tokenului care răspunde „write OK” confirmă un canal, nu canalul pe care îl voiai.

Drumul direct. Prin Graph API, o postare pe o pagină de Facebook se poate programa între 10 minute și 6 luni înainte. Drumul nostru spre Instagram nu poate programa și publică imediat; are nevoie de o imagine la un URL public și merge în doi pași: creezi un container media, aștepți să fie gata, apoi publici. Doar 8 din cele 22 de pagini ale noastre aveau un cont de Instagram legat. O postare pe o pagină publică nu se poate retrage, așa că unealta directă rulează implicit pe uscat.

Unde am greșit și ce nu garantează metoda

Am tratat o cerere acceptată ca pe o postare livrată, am ținut un cache de conturi conectate fără expirare și ne-am bazat pe un prompt ca să prevină o greșeală pe care o prinde doar o verificare a rezultatului. Toate trei arătau sănătos în logurile noastre.

Citirea stării finale dovedește că o postare a fost publicată, nu că a mers. Analiza noastră pe 9.404 postări TikTok din trecut a găsit sâmbăta la de 2,6 ori vizualizările mediane ale celorlalte zile, cu conținutul de ofertă și urgență în frunte; e o corelație din istoricul nostru, nu un test, iar tiparul pe ore poate fi în parte un efect al fusului orar.

Listă de verificare. Salvează în log răspunsul de programare și, separat, starea finală pe fiecare rețea; pune expirare pe orice cache de conturi conectate; filtrează clipurile la 9:16 adevărat și respinge barele arse; elimină dublurile după nume și durată; un singur lacăt pentru tot ce scrie în coadă; corectează numele în cod, la ieșire; verifică descrierile generate pentru impersonare; calculează orele într-un fus explicit; rulează pe uscat tot ce postează pe o pagină publică.

Întrebări și răspunsuri

Dacă API-ul de programare răspunde 200, postarea mea e live?

Nu. Un răspuns 200 înseamnă că planificatorul a acceptat postarea. Publicarea vine mai târziu, la ora programată, separat pentru fiecare rețea, deci o rețea poate publica în timp ce alta pică. La noi, logul arăta 200 la fiecare rulare, iar toate cele 17 postări pe Facebook picaseră. Cere planificatorului starea finală pe fiecare rețea după ora publicării.

De ce ar pica postările programate pe Facebook și Instagram, dar ar merge pe TikTok?

O cauză des întâlnită e că legătura cu Facebook sau Instagram a căzut în serviciul de programare, în timp ce sistemul tău o crede încă activă. Al nostru citea o listă de rețele conectate veche de 2 luni, fără expirare. Reîmprospătează lista regulat, noi folosim 12 ore, și verifică starea fiecărei postări pe fiecare rețea.

Pot programa postări pe Instagram prin Instagram Graph API?

În integrarea noastră, nu: drumul spre Instagram publică imediat. Are nevoie și de o imagine la un URL public și merge în doi pași: creezi un container media, aștepți să fie gata, apoi publici. Postările pe paginile de Facebook se pot programa prin Graph API între 10 minute și 6 luni înainte. Postările doar cu text nu pot merge pe Instagram.

Cum împiedic descrierile scrise de AI să se dea drept persoana din clip?

Pune regula în prompt, apoi verifică rezultatul în cod, fiindcă promptul singur nu ajunge. Verificarea noastră caută tipare de autoprezentare cu un nume scris cu majusculă, cere modelului o rescriere și respinge clipul dacă rescrierea pică. Testează verificarea pe descrieri bune și rele: un tipar fără diferențiere de majuscule a făcut prima noastră scanare să raporteze 23 de probleme când era una.

De ce jobul meu de postare nu programează mai mult de câteva postări pe zi?

Verifică dacă numărul de postări pe zi e plafonat de o listă de ore de postare. Posterul nostru ia primele N ore din lista aceea, deci cu patru ore în listă maximul e 4 postări pe zi, orice ar scrie în setarea de sloturi. Orele noi trebuie să fie și după ora la care rulează jobul, altfel programul alunecă pe ziua următoare.

Toate metodele