Going Live
This page is for the developer whose integration works against a test tenant and is about to run unattended against a customer’s books. It is a checklist in the order the work is done. Each line is one check and a link to the page that explains it, so the reasons live in one place.
In the running example, GadgetSphere Online’s storefront has pushed test orders into a test tenant
for a week. Before it points at the live gso tenant, someone works down this list.
Before the switch
- Build and test against a test tenant, not the customer’s live data. BigLedger runs no sandbox, so ask for a test tenant by name (Asking BigLedger for a hand-off).
- Run the integration as its own user, with one labelled key that has an end date. Write down who holds that user’s sign-in and how the key is rotated (Handling credentials).
- Read one row of every resource the integration will use, with the live key. A key that reads
one resource and gets
CLIENT_AUTH_USER_NOT_AUTHORIZEDon another is missing a permission, not broken; any other refusal code names a different cause (Testing a credential). - Check the company’s default GL codes before the first Finalise. A missing code stops the
journal after Finalise has already answered
200(What must exist first). - Settle the duplicate key scheme and write it down: a stored header
guidper record, plusclient_sourceandclient_key. Changing the scheme later breaks the duplicate check for everything already sent (What the API leaves to you). - Have the owner of the books decide whether documents post on arrival or wait as drafts. A document sent to Finalise starts posting at once; a draft is cheap to correct (What the API leaves to you).
- Add the reconciliation pull before you rely on a webhook. A topic subscription makes one unsigned attempt per event and nothing tells you when one is lost (What it does not do).
After the switch
- Name the person who runs the daily check, and start it on day one. For most feeds nothing in BigLedger tells you one has stopped (Checks that prove it worked).
What success looks like
On the first morning after the switch, the daily check passes: the count and the total of
yesterday’s FINAL documents equal your own system’s, and no row has a blank posting_journal. If they do not, read
When it goes wrong before you
send anything else.
Common mistakes
| Mistake | What you see | Owner page |
|---|---|---|
| Going live on a key issued under a person’s own sign-in | The key is refused once that person’s permissions are removed, and nobody else can see or rotate it | Who looks after the keys |
Reading a 200 from Finalise as “posted” | Documents read FINAL and the ledger is short; posting_journal is blank | What must exist first |
| Relying on the webhook alone | Records missing on your side with no error anywhere | What it does not do |
| Nobody owns the daily check | A stopped feed is found at month-end | Checks that prove it worked |
Related documentation
- Getting Started: the first key, read and write this list assumes you have done.
- The Integration Surface: what every integration page assumes.
- Data API: Writing Documents: draft, Finalise and the chain.
Last updated on