Ce que voit un client sandbox
- Les lectures renvoient des fixtures statiques : documents, relations, journaux, comptes bancaires et adresses de livraison de démonstration. Aucune donnée réelle d’entreprise n’entre en jeu.
- Les écritures (
POST,PATCH,DELETE) appliquent exactement les mêmes validations et renvoient les mêmes codes d’erreur qu’en live, mais vos données ne seront pas modifiées.
Conséquences à prévoir dans votre code
- L’
idrenvoyé par une création sandbox est généré à la volée et non résolvable : unGETultérieur renvoie404. - Un
PATCHsandbox renvoie l’objet modifié, mais les fixtures sont partagées et figées : leGETsuivant renvoie l’objet intact.
Le sandbox sert à valider vos appels et ne stocke pas vos modifications.
Création et modification de documents en sandbox
La création ou la modification de documents va plus loin qu’une simple validation : les montants, la TVA, le numéro (tiré de la séquence du journal de fixtures) et la communication structurée sont réellement calculés. Le journal est contrôlé comme en live : le document doit être réservé dans un journal dont la catégorie correspond à son type, résolu parmi les journaux de fixtures.issue_date est bornée comme en
live : dans la fenêtre de numérotation, jamais dans le futur, jamais avant le
dernier document de la séquence de fixtures.
Les sociétés de fixtures portent leurs propres conditions de paiement, héritées
comme en live quand le corps n’en donne pas (un contact n’en a jamais).
Un écart assumé par rapport au live : l’auto-facturation est considérée comme
activée — purchase_invoice et purchase_credit_note sont créables en sandbox
alors que le live exige le paramètre de la société.
L’exemption du paiement vaut aussi en sandbox : un PATCH ne portant que
paid_amount passe sur une fixture déjà envoyée ou exportée, comme en live.