# Kontrakt endpointów zamówień `miceyproductconnector`

Aplikacja Symfony korzysta z dwóch endpointów modułu:

- `GET /module/miceyproductconnector/orders?updated_since=...&cursor=...&limit=...`
- `GET /module/miceyproductconnector/order?id_order=123`

Endpointy używają tej samej autoryzacji HMAC, która działa już dla `ping`, słowników i publikacji:

- `X-WW-App-Id`,
- `X-WW-Timestamp`,
- `X-WW-Signature`,
- opcjonalny fallback tych danych w query stringu.

Nie wprowadzono równolegle drugiego systemu autoryzacji. Jeżeli cały connector zostanie później przełączony na HMAC v2, wtedy obie strony muszą wspólnie podpisywać metodę, ścieżkę, canonical query string, timestamp, nonce i SHA-256 body.

Lista zwraca `orders`, nieprzezroczysty `next_cursor` oraz `has_more`. Każdy rekord jest pełnym snapshotem i zawiera `is_full_snapshot=true`.

## Punkt odbioru InPost

Kod punktu pochodzi z rekordu powiązanego z rzeczywistym `id_cart` zamówienia:

```text
{_DB_PREFIX_}inpost_cart_choice.point
```

Pełne dane punktu są pobierane z:

```text
{_DB_PREFIX_}inpost_point.id_point
{_DB_PREFIX_}inpost_point.data
```

W aktualnej bazie z prefiksem `wwps_` są to odpowiednio:

```text
wwps_inpost_cart_choice
wwps_inpost_point
```

Connector nie odtwarza kodu z nazwy przewoźnika i nie wyszukuje podobnego punktu.

Przy odczycie przez:

```php
Db::getInstance()->getRow($sql)
```

zapytanie przekazane do `getRow()` nie zawiera ręcznego `LIMIT 1`, ponieważ PrestaShop dopisuje limit samodzielnie. Dzięki temu nie powstaje błędne `LIMIT 1 LIMIT 1`.

## Minimalna odpowiedź listy

```json
{
  "success": true,
  "data": {
    "orders": [],
    "next_cursor": null,
    "has_more": false
  },
  "warnings": []
}
```

## Cursor

Cursor jest generowany przez connector jako nieprzezroczysta wartość. Wewnętrznie wskazuje ostatnią parę `date_upd + id_order`, ale aplikacja Symfony nie analizuje jego struktury i jedynie przekazuje go przy następnym wywołaniu.