01
Date înțelese la ambele capete
Tipurile, identificatorii și regulile de validare sunt documentate înainte de schimb.
Conectăm aplicațiile în jurul procesului tău.
Integrări custom și dezvoltare API-uri proprii
Conectăm sisteme sau construim interfețe proprii cu date, acces și rezultate explicite. Explorează o cerere realistă, repetarea ei și traseul până la confirmarea finală.
Buget orientativ / proiect1.900–8.900 RON
Disponibil pentru proiecte noi
Contract clar, operații delimitate și cod propriu predat echipei tale.
01 / REZULTATUL URMĂRIT
Procesul tău are reguli. API-ul trebuie să le înțeleagă.
Dezvoltăm integrări custom și API-uri proprii pentru WordPress și WooCommerce: contract de date, autentificare, cozi, reguli de procesare și documentație pentru echipă.
02
Acces legat de operație
Fiecare aplicație primește drepturile aprobate pentru resursele necesare.
03
Interfață predată echipei
Exemplele, codul și ghidul explică operarea și continuarea dezvoltării.
KEPA / INTEGRATION LAB
Dintr-o regulă de business, un contract API clar.
Un mic laborator de integrare: rute documentate, validare de payload, răspunsuri explicite și protecție împotriva procesării aceluiași eveniment de două ori.
Simulare interactivă, localăDate și companii fictive. Fără conexiune ERP, emitere de facturi sau trimitere de date.
02 / CEREREPOST
application/jsonPOST /kepa/v1/requests
Autentificarea și semnătura sunt doar stări de test. Nu se cer chei reale și nu se execută verificări criptografice.
03 / RĂSPUNS
NEEXECUTATContractul răspunde explicit.
{
"state": "ready",
"mode": "local_demo",
"external_requests": 0
}Evenimente acceptate în memorie0
Stoc SKU în demonstrație8 buc.
REQUEST LOGultimele 6 cereri
- Nu există cereri. Nicio conexiune externă.
Execută exemplul valid de două ori pentru a observa răspunsul la un eveniment duplicat.
- 01EVENIMENTDate sursă demonstrative↓
- 02CONTRACT APIMapare și validare↓
- 03REZULTATConfirmare și jurnal✓
Intrări și răspunsuri previzibile.
Fiecare rută are tipuri, câmpuri acceptate și coduri de răspuns. În proiect, documentația și testele contractuale urmează aceste reguli.
Repetarea nu dublează efectul.
Aceeași cheie și același payload primesc confirmarea originală. Modificarea payload-ului sub aceeași cheie produce un conflict.
Cod construit în jurul procesului.
Un webhook de stoc, o comandă sau o rută de stare cer validări diferite. Contractul începe de la datele și responsabilitățile reale.
Datele se păstrează doar în memoria acestei pagini. Reîncărcarea sau resetarea readuce exemplul inițial. Interfața demonstrează un flux posibil; configurația livrată se stabilește în oferta proiectului.
02 / EXEMPLE VIZUALE
Un API proiectat pentru fluxul tău, cu rezultate pe care le poți urmări.
ROUTE este un client API fictiv, realizat pentru această ofertă. Cererea POST /kepa/v1/requests folosește referința WEB-1048, tipul request.created, clientul CLIENT-DEMO și un articol CAM-ALB-M cu cantitatea 2. Contractul propus păstrează legătura dintre cerere, rezultat și jurnal.
EXEMPLU 01
Endpoint, corp JSON și rezultatul salvat al aceleiași cereri
Exemplul arată structura explicită a cererii, un token demonstrativ, cheia de idempotency și rezultatul salvat la reluare. Trace-ul leagă validarea, procesarea, salvarea și returnarea rezultatului existent de aceeași operațiune fictivă.
Vezi imaginea la dimensiune completă
EXEMPLU 02
Prima cerere, reluare identică și conflict de conținut
Trei evenimente explică idempotency în contractul propus: prima cerere salvează rezultatul, reluarea cu aceeași cheie și același corp îl recuperează, iar schimbarea corpului sub aceeași cheie primește 409. Codul 409 este alegerea acestui contract, nu o regulă universală pentru toate API-urile.
Vezi imaginea la dimensiune completă
03 / PACHETE ȘI BUGET
Alegi punctul de pornire.
Definim împreună detaliile.
Alege după numărul de operații și nivelul de procesare și control. Contractul de date, volumul și accesul se aprobă înainte de implementare.
Un WordPress sau WooCommerce, un sistem extern și un flux de afaceri delimitat. Numărăm o operație ca pereche metodă HTTP și rută: GET și POST pe aceeași adresă reprezintă două operații. Limitele sunt 2, 4 sau 8 operații; datele, volumele și direcțiile se confirmă în specificație. Aplicațiile mobile, interfețele complete de produs, mai multe organizații, infrastructura dedicată și costurile furnizorilor se estimează separat.
PACHET 01
Esențial · un flux delimitat
1.900 RONpreț orientativ / proiect
Solicită ofertăCE INCLUDE
- Un website, un sistem extern și până la 2 operații API
- Un flux de afaceri, contract de date și exemple documentate
- Autentificare printr-un mecanism agreat și autorizare pe operație
- Validare, coduri de eroare și protecție la repetare pentru scrierile incluse
- Jurnal cu referință de diagnostic și credențiale mascate
- Teste de acces și date, ghid de configurare și cod propriu
PACHET 02Coadă și documentație
Operațional · coadă și control
4.900 RONpreț orientativ / proiect
Solicită ofertăCE INCLUDE
- Un website, un sistem extern și până la 4 operații API
- Contract versionat și specificație OpenAPI pentru scopul aprobat
- Coadă persistentă, limite, reluări și stări de procesare
- Panou cu excepții și o integrare webhook dacă sistemul o permite
- Verificarea semnăturii disponibile și controlul evenimentelor duplicate
- Colecție de cereri fără secrete, teste de recuperare și predare
PACHET 03
Avansat · protocol propriu
8.900 RONpreț orientativ / proiect
Solicită ofertăCE INCLUDE
- Un website, un sistem extern și până la 8 operații API
- Tot scopul Operațional și matrice de drepturi pe resurse
- Semnare și protecție replay pentru interfața proprie, dacă sunt potrivite
- Rotația cheilor, versiuni și reconciliere pe scenariile aprobate
- Istoric de operații și alertare printr-un canal convenit
- Teste de volum agreat, documentație de operare și cod propriu
Compară pachetele, funcție cu funcție
| Funcționalitate | Esențial · un flux delimitat | Operațional · coadă și control | Avansat · protocol propriu |
|---|---|---|---|
| Website și sistem extern | 1 site · 1 sistem | 1 site · 1 sistem | 1 site · 1 sistem |
| Operații metodă + rută | Până la 2 | Până la 4 | Până la 8 |
| Flux de afaceri | 1 flux delimitat | 1 flux cu procesare în fundal | 1 flux cu protocol propriu aprobat |
| Autentificare și acces | Mecanism agreat și autorizare | Plus roluri pentru operare | Plus matrice pe resurse și rotație |
| Coadă și reluări | Scenariile sincrone aprobate | Coadă persistentă și excepții | Plus reconciliere și alertă |
| Evenimente | Separat, dacă sunt necesare | 1 webhook dacă este disponibil | Plus semnare și replay pentru protocol propriu |
| Documentație | Contract, exemple și ghid | Plus OpenAPI și colecție de cereri | Plus operare și versiuni convenite |
| Predarea codului propriu | Inclusă conform contractului | Inclusă conform contractului | Inclusă conform contractului |
| Calendar orientativ după acces | 7–10 zile lucrătoare | 15–22 zile lucrătoare | 25–35 zile lucrătoare |
Prețuri orientative în RON, per proiect. Oferta finală, regimul fiscal, costurile externe și condițiile colaborării se confirmă după analiza cerințelor. Un WordPress sau WooCommerce, un sistem extern și un flux de afaceri delimitat. Numărăm o operație ca pereche metodă HTTP și rută: GET și POST pe aceeași adresă reprezintă două operații. Limitele sunt 2, 4 sau 8 operații; datele, volumele și direcțiile se confirmă în specificație. Aplicațiile mobile, interfețele complete de produs, mai multe organizații, infrastructura dedicată și costurile furnizorilor se estimează separat.
Ai un scenariu diferit?Ai mai multe aplicații, clienți independenți sau un produs API public? Definim arhitectura și estimarea pentru acel context.
UN PROIECT CARE POATE FI VERIFICAT
Știi ce construim.
Vezi ce primești.
Confirmăm componentele și criteriile de acceptare înainte de dezvoltare. Fiecare etapă produce un livrabil pe care îl poți analiza.
- 01
Definim contractul
Stabilim actorii, datele, rutele și rezultatul concret al fiecărei operații.
LIVRABILContract versionat și scenarii de recepție - 02
Implementăm accesul
Construim autorizarea, validarea și legătura cu sistemul extern.
LIVRABILOperații disponibile în mediul de test - 03
Testăm incidentele
Verificăm cereri repetate, drepturi insuficiente, limite și recuperare.
LIVRABILRezultate de test și reguli de reluare documentate - 04
Predăm interfața
Livrăm documentația, codul și configurarea și coordonăm activarea.
LIVRABILIntegrare predată cu ghid de operare
PREGĂTIM ÎMPREUNĂ
De ce avem nevoie
pentru un început clar
- Descrierea fluxului și exemple anonimizate de date de intrare și ieșire
- Documentația și accesul autorizat la sistemul extern
- Identitățile apelante, resursele accesibile și drepturile aprobate
- Volume orientative, limitele furnizorilor și infrastructură de test
- Responsabil tehnic și utilizator care validează rezultatul operațional
VERIFICĂM LA PREDARE
Exemple de criterii
de acceptare
- Operațiile și răspunsurile corespund contractului aprobat
- Cererile neautorizate și accesul la resurse nepermise sunt respinse
- Datele invalide și conflictele produc erori explicite fără efecte neaprobate
- Repetarea și recuperarea operațiilor respectă scenariile documentate
- Jurnalul, documentația și configurarea pot fi folosite de echipa desemnată
Lista finală urmărește pachetul și scenariile aprobate. Rezultatele testelor din proiect se consemnează la predare.
04 / DATE, REGULI ȘI OPERARE
Din regula afacerii
într-un contract pe care te poți baza.
Pentru echipe care trebuie să conecteze WordPress sau WooCommerce cu o aplicație internă ori externă și au nevoie de reguli proprii, acces controlat și documentație.
CE PRIMEȘTI ÎN INTEGRARE
- Specificație a fluxului, operațiilor și regulilor de acces
- API sau integrare custom cu validare și contract versionat
- Control al erorilor, repetării și procesării potrivit pachetului
- Exemple și documentație, inclusiv OpenAPI în nivelurile superioare
- Raport de recepție, ghid de operare și codul dezvoltării proprii
01Pornim de la o operație reală, nu de la o listă de tehnologii
Alegem un flux delimitat, precum trimiterea unei cereri de aprovizionare către un sistem intern și citirea stării ei. Descriem actorul, datele necesare, rezultatul și ce se întâmplă când operația nu poate continua. Alegem integrarea unei interfețe existente când aceasta acoperă cerința; construim un endpoint propriu când avem nevoie de reguli și drepturi distincte. Pachetele privesc un site și un sistem extern. Un API public cu mai mulți clienți independenți, facturare după utilizare sau administrare multi-organizație are o arhitectură și estimare separate.
02Contractul spune ce primește fiecare parte și cât timp rămâne compatibil
Definim rutele, metodele, câmpurile obligatorii, tipurile, enumerările și limitele de dimensiune. Identificatorii externi rămân distincți de ID-urile locale. Pentru liste convenim paginarea și filtrele, iar pentru date folosim un format și un fus orar explicite. O versiune precum /kepa/v1/ marchează contractul livrat; o schimbare incompatibilă nu este strecurată sub aceeași promisiune. Predăm exemple de cerere și răspuns, erori și condițiile de acces. Operațional și Avansat includ și o specificație OpenAPI pentru operațiile proiectului, împreună cu o colecție de cereri de test fără secrete.
03Autentificarea identifică aplicația; permisiunile limitează ce poate face
Folosim HTTPS și un mecanism compatibil cu sistemele alese: chei dedicate, Application Passwords cu utilizator și drepturi potrivite sau alt mecanism documentat. Verificăm autorizarea pe fiecare operație și resursă; validarea autentificării nu acordă implicit acces la toate comenzile. Când mecanismul permite, separăm scopurile de citire și scriere și documentăm revocarea și rotația cheilor. O cheie tehnică rămâne pe server sau într-un mediu de execuție protejat; nu o introducem în JavaScript public. Accesul administrativ pentru configurare este separat de identitatea aplicației care apelează API-ul.
04Exemplu construit: aceeași cerere nu creează două lucrări
În exemplul demonstrativ, POST /kepa/v1/requests primește externalRef WEB-1048 și o cheie de idempotență. Prima cerere validă creează o singură lucrare și returnează referința ei; procesarea poate continua în fundal. Repetarea în fereastra de retenție agreată, cu aceeași cheie, identitate și același conținut, returnează rezultatul cunoscut. Dacă reutilizarea cheii schimbă datele, contractul răspunde cu un conflict 409 și nu creează altă lucrare. Starea finală se citește separat. Identificatorii și adresele din această demonstrație explică un proiect posibil, fără a reprezenta un API public activ.
05Evenimentele și răspunsurile au protecții potrivite transportului
Dacă primim webhooks, verificăm mecanismul de semnare al furnizorului și conținutul efectiv al cererii, nu doar un câmp declarat în JSON. Pentru protocolul propriu din Avansat putem defini semnături, interval de validitate și nonce, cu evidență a reutilizării în fereastra convenită. O semnătură validă nu oprește singură redarea unui mesaj capturat; identitatea evenimentului și protecția de replay au verificări distincte. Alegerea se face după capabilitățile ambelor părți. Nu adăugăm o semnătură inventată peste un furnizor care nu o poate genera și nu prezentăm IP allowlist ca autentificare suficientă.
06Erorile, limitele și reluările fac parte din experiența integrării
Distingem solicitările invalide, accesul insuficient, conflictul, limita de rată și indisponibilitatea temporară. Răspunsul conține un cod stabil și o referință de diagnostic, fără secrete sau stack trace public. Reluările au pauze, plafon și respectă instrucțiunile furnizorului când sunt disponibile. Operațiile cu efecte nu se repetă automat doar fiindcă prima conexiune s-a întrerupt; folosim identificatorul operației și verificarea rezultatului. Din Operațional, coada persistentă salvează progresul, limitează concurența și trimite erorile definitive în excepții. Volumele și țintele de răspuns sunt testate pe infrastructura convenită.
07Predăm un sistem pe care echipa îl poate întreține
Documentăm configurarea, dependențele, versiunile suportate, cheile necesare și pașii de oprire sau revocare. Jurnalul urmărește o cerere prin ID de corelare, etapă, durată și rezultat; mascăm credențialele și limităm datele personale la necesarul aprobat. Retenția și drepturile de acces se stabilesc în proiect. Codul dezvoltării proprii este predat clientului în condițiile contractului; bibliotecile și platformele își păstrează licențele. La recepție verificăm autentificarea, validarea, repetarea cererii și recuperarea din erorile incluse. Monitorizarea permanentă și adaptările viitoare pot continua într-un acord de mentenanță.
Calendar orientativ după documentație și accesOrientativ, după specificație și acces complete: 7–10 zile lucrătoare pentru Esențial, 15–22 pentru Operațional și 25–35 pentru Avansat. Calendarul se confirmă după contractul de date, mecanismul de acces și limitele sistemului extern.
05 / DOCUMENTE DE REFERINȚĂ
Surse oficiale
și reguli de referință.
Consultă documentele de referință pentru cerințele și limitele funcțiilor prezentate.
Public · WordPress
WordPress — endpoint-uri REST proprii
Rute, validarea argumentelor și verificarea permisiunilor pentru operațiile proprii.
Consultă sursa oficială (se deschide într-o filă nouă)Public · WordPress
WordPress — autentificarea REST API
Application Passwords și diferența dintre autentificarea interfeței locale și accesul aplicațiilor externe.
Consultă sursa oficială (se deschide într-o filă nouă)Public · RFC 9421
IETF — HTTP Message Signatures
Semnături de mesaj, intervale de validitate și nonce pentru verificări explicite împotriva replay-ului.
Consultă sursa oficială (se deschide într-o filă nouă)Public · RFC 9110
IETF — HTTP Semantics
Metode, erori, idempotență și condiții de reluare a cererilor HTTP.
Consultă sursa oficială (se deschide într-o filă nouă)DIN PROIECTELE REALIZATE
Exemple de implementări.
Explorează funcțiile și interfețele realizate în proiecte. Fiecare exemplu prezintă contextul și soluția folosită.
DAGMAR
Integrare API eMAG cu WooCommerce
Maparea catalogului, actualizarea stocurilor și prețurilor și importul comenzilor în fluxul DAGMAR.
Vezi implementareaDAGMAR
Integrare custom WooCommerce–ERP
Clienți, comenzi și referințe de document corelate cu confirmările ERP Supplier/VFP.
Vezi implementareaCHARMÉE
Marketplace Hub și adaptoare dedicate
Un Hub comun cu adaptoare eMAG, Trendyol și ABOUT YOU, fiecare cu mapări și validări proprii.
Vezi implementareaFuncțiile incluse în proiectul tău se stabilesc prin pachetul și oferta confirmate.
RĂSPUNSURI UTILE ÎNAINTE DE A ALEGE
Ai întrebări?
Începem de aici.
Detalii despre funcționare, limite și implementare. Pentru cerințele site-ului tău, discutăm direct.
Solicită ofertăCe diferență este între integrarea unui API și crearea unuia propriu?
Integrarea consumă operațiile unui sistem existent și adaptează datele la procesul tău. Un API propriu expune operații și un contract pe care le definim pentru aplicațiile autorizate. Același proiect le poate combina; nominalizăm separat rutele, direcțiile și regulile livrate.
Cum numărați operațiile incluse în pachete?
O operație este o pereche metodă și rută, cu un scop și o schemă aprobate. GET /requests și POST /requests înseamnă două operații. Un endpoint care ar executa arbitrar zeci de funcții nu ocolește limitele proiectului. Pachetele includ până la 2, 4 sau 8 operații pentru un singur flux de afaceri delimitat.
Puteți integra o aplicație care nu are API public?
Verificăm dacă există un API privat autorizat, export, import sau altă interfață susținută de furnizor. Fără o cale stabilă și permisă, nu putem promite integrarea directă. Accesul la baza de date, modificările aplicației sau dezvoltarea unei interfețe din partea furnizorului au analiză și scop separate.
API-ul poate fi folosit dintr-o aplicație Android sau un portal?
Da, dacă definim operațiile și identitatea potrivite acelui client. Pentru o aplicație distribuită utilizatorilor nu presupunem că o cheie secretă fixă din aplicație rămâne secretă; autentificarea utilizatorilor și drepturile cer un flux adecvat. Construcția aplicației Android sau a portalului este un proiect distinct de aceste pachete API.
Cum protejați accesul și credențialele?
Alegem mecanismul suportat, folosim HTTPS, verificăm permisiunile per operație și limităm accesul la resursele aprobate. Cheile se păstrează în mediul de server potrivit, cu revocare documentată și jurnal fără secrete. Pentru interfața proprie putem include semnare și verificări de replay. Detaliile depind de arhitectură și sunt specificate înainte de dezvoltare.
Ce se întâmplă dacă aceeași cerere ajunge de două ori?
Pentru scrierile incluse definim identitatea operației, durata de retenție și regula de deduplicare. Același identificator cu aceleași date poate întoarce rezultatul existent; același identificator cu date diferite este un conflict. Sistemul extern trebuie verificat la rândul său: o blocare locală nu garantează singură un efect unic după un timeout la furnizor.
Primesc documentația și codul? Cine poate continua dezvoltarea?
Predăm codul dezvoltării proprii conform contractului, exemplele și instrucțiunile de configurare. Operațional și Avansat includ specificație OpenAPI și colecție de cereri fără secrete. O altă echipă poate continua pe baza contractului și dependențelor documentate; platformele și bibliotecile utilizate păstrează propriile licențe.
Sunt incluse hostingul, monitorizarea și schimbările ulterioare?
Tariful acoperă implementarea și verificările scopului convenit. Găzduirea, abonamentele externe, operarea permanentă și mentenanța sunt separate. Stabilim versiunile suportate și volumul de test. Un nou flux, mai multe sisteme sau o schimbare incompatibilă a API-ului se estimează după impact.
SOLUȚII PENTRU URMĂTORUL PAS
Ce mai poți
simplifica?
Același SKU. O regulă clară. Un stoc explicabil.
Stocuri și prețuri ERP → WooCommerce
Legăm ERP-ul de WooCommerce prin SKU-uri, reguli de disponibilitate și actualizări urmărite. Vezi concret cum se calculează stocul vandabil și cum sunt tratate diferențele.
- Mapare verificată între SKU ERP, produs și variație WooCommerce
- Stoc vandabil, rezervări și buffer definite înainte de actualizare
Buget orientativ / proiect1.900–6.900 RON
Comandă, document, înregistrare ERP. Același traseu urmărit.
Facturare și ERP extern
Un flux complet între WooCommerce, emitent și ERP extern: mapare, emitere controlată, referințe și reconciliere. Vezi ce se întâmplă când răspunsul se pierde sau ERP-ul nu este disponibil.
- Rol explicit pentru WooCommerce, emitentul facturii și ERP
- Maparea clienților, liniilor, reducerilor și taxelor aprobate
Buget orientativ / proiect2.900–9.900 RON