Skip to main content
Each API client is either live or sandbox. A sandbox client has no access to production data: it lets you integrate your software in an isolated environment. Ask for a sandbox client in the Fidly interface to develop and test.

​
What a sandbox client sees

  • Reads return static fixtures: demo documents, relations, journals, bank accounts and delivery locations. No real company data is ever involved.
  • Writes (POST, PATCH, DELETE) run exactly the same validations and return the same error codes as live, but your data will not be modified.

​
Consequences to code against

  • The id returned by a sandbox creation is generated on the fly and not resolvable: a later GET on it returns 404.
  • A sandbox PATCH returns the modified object, but fixtures are shared and frozen: the next GET returns the object unchanged.
The sandbox is for validating your calls and does not store your changes.

​
Document creation and update in sandbox

Creating or updating a document goes further than plain validation: amounts, VAT, the document number (drawn from the fixture journal’s sequence) and the structured payment reference are really computed. The journal is checked as in live: the document must be booked in a journal whose category matches its type, resolved among the fixture journals. issue_date is bounded exactly as in live: within the numbering window, never in the future, never before the last document of the fixture sequence. Fixture companies carry payment terms of their own, inherited as in live when the body gives none (a contact never has any). One deliberate difference with live: self-billing is considered enabled — purchase_invoice and purchase_credit_note are creatable in sandbox even though live requires the company setting. The payment exemption also holds in sandbox: a PATCH carrying only paid_amount passes on a fixture that is already sent or exported, as it would in live.