meta {
  name: 03 In-app pending
  type: http
  seq: 3
}

get {
  url: {{baseUrl}}/api/v1/checkin/inapp/pending
  body: none
  auth: bearer
}

auth:bearer {
  token: {{token}}
}

tests {
  test("200 OK", function () {
    expect(res.getStatus()).to.equal(200);
  });
  test("data est un array", function () {
    expect(res.getBody().data).to.be.an("array");
  });
}

docs {
  GET /api/v1/checkin/inapp/pending — auth requise

  Liste les factures de l'org en `awaiting_user_confirmation` (= ayant
  reçu l'email check-in mais pas encore eu de réponse). C'est la queue
  que la modale du SPA affiche au login pour rappeler à l'user qu'il a
  des décisions à prendre.

  Tri : `due_date` ASC (les plus anciennes échéances d'abord).

  Réponse :
  ```json
  {
    "data": [
      {
        "id": "uuid",
        "numero": "F2026-0007",
        "amountTtcCents": 12345,
        "issueDate": "2026-04-07T...",
        "dueDate": "2026-05-07T...",
        "status": "awaiting_user_confirmation",
        "clientName": "Boulangerie Martin",
        "planName": "Standard B2B"
      }
    ]
  }
  ```

  ## Note V1

  En prod actuelle, le statut DB de l'invoice reste `pending` jusqu'à ce
  que l'user réponde au check-in (le `send_checkin_job` ne change pas
  le statut). C'est le seed démo qui force `awaiting_user_confirmation`
  pour pré-peupler des cas. À aligner V1.5.
}