Cum funcționează

Drumul unei comenzi

  Client                Platforma            Middleware-ul nostru              POS-ul tău
    │                   de comenzi
    │  plasează              │                        │                            │
    ├──── comanda ──────────►│                        │                            │
    │                        │   webhook cu comanda   │                            │
    │                        ├───────────────────────►│                            │
    │                        │                        │ ① înregistrăm comanda      │
    │                        │                        │   (receivedTime)           │
    │                        │                        │                            │
    │                        │                        │ ② transformăm în formatul  │
    │                        │                        │   din documentația aceasta │
    │                        │                        │                            │
    │                        │                        │ ③ POST către endpointul tău│
    │                        │                        ├───────────────────────────►│
    │                        │                        │                            │
    │                        │                        │◄──── răspunsul tău ────────┤
    │                        │                        │   (executedTime)           │
    │                        │                        │                            │
    │                        │                        │ ④ salvăm cererea, răspunsul│
    │                        │                        │   și eventualele erori     │

Pașii ① – ④ durează în mod normal sub două secunde. Tot ce se salvează la pasul ④ este ce vezi mai târziu în căutarea de comandă.

Ce se întâmplă când endpointul tău nu răspunde

Comportamentul implicit este o singură încercare: dacă apelul eșuează, comanda nu ajunge la tine și rămâne înregistrată la noi ca nelivrată.

Dacă îți activezi reîncercarea, încercăm de mai multe ori, cu pauze crescătoare. Fiecare încercare — reușită sau nu — este vizibilă în trasabilitatea comenzii.

Drumul unei actualizări de meniu

Actualizarea completă a meniului merge în sens invers și este asincronă, în două etape:

  POS-ul tău                       Middleware-ul nostru
      │                                     │
      │  ① POST /api/v3/menu/upload         │
      ├────────────────────────────────────►│
      │                                     │
      │◄──── transaction_id ────────────────┤   „am primit, urmează să procesez"
      │                                     │
      │  ② GET /api/v3/menu/checkstatus/... │
      ├────────────────────────────────────►│
      │◄──── status final ──────────────────┤   SUCCESS / ERROR

Un răspuns de succes la pasul ① înseamnă doar că payload-ul a fost primit, nu că meniul e actualizat. Rezultatul real se citește la pasul ②, sau ajunge singur la tine dacă ai definit un endpoint de tip notificare rezultat menu update.

Detalii: actualizare completă.

Cine ce identifică

Identificator	Cine îl alege	Unde apare
`partner_name`	îți este alocat la înregistrarea în portal	în payload-ul de meniu, ca prefix în `store_id`
`store_id` (LID)	tu, la crearea locației	în fiecare comandă și în fiecare operație pe magazin
`order_code`	sistemul, la plasarea comenzii	în comandă; este cheia după care cauți mai târziu

Formatul complet al identificatorului de magazin este partner_name__store_id — vezi terminologie.