How to Connect Jobber to Your Own Dashboard Without Breaking the Office's Login

Jobber hands out a new refresh token every time the current one is used, and cancels the old one. A second copy of the connection that refreshes on its own leaves the first copy holding a dead token.

When an office connects an app to Jobber, the app receives two tokens. The access token opens the door for about an hour. The refresh token is how the app gets a new access token without asking a person to sign in again.

Jobber rotates the refresh token. Each time the app uses it, Jobber answers with a new one, and for apps created after January 2, 2024 the old one stops working immediately. That is a good security design, and the OAuth standard allows it: when the server issues a new refresh token, the client must throw the old one away.

The trap is a second copy. My test script would have loaded the stored refresh token, used it, received a new one and kept that to itself. The dashboard would still be holding the old token, now cancelled, and its next refresh would fail.

Every part of the system reads the tokens from one place and writes the new pair back there before making any other call. A script with its own saved token is a second owner, and two owners break the chain.

Jobber's own guidance comes down to one habit: every time a refresh token is used, save both new tokens to your token store before making any other call. Then reload from that store; never trust a copy sitting in a variable from earlier.

In practice that means one owner. The dashboard, a nightly sync and any admin tool all read the tokens from the same database row and write the new pair back to it. A script on a laptop with its own saved token is a second owner, and two owners break the chain the first time both run.

If a refresh fails, the dashboard should say so on the screen and name who signs in again. Numbers that silently stop updating are worse than a clear message that the connection needs a person.

Even with one owner, a connection will eventually need a person: someone changes a password, an admin removes the app, or a token expires while the dashboard is switched off. The question is what the office sees when that happens.

The wrong answer is yesterday's numbers with no warning. The right one is a plain message at the top of the screen that the Jobber connection needs to be signed in again, when it last worked, and who in the office does it. A dashboard that is quietly stale is worse than one that says it is stale.

Proofs that read the code, stored records and saved sample responses, and no live call from a separate script. The office's connection is production and gets treated like it.

The office's Jobber connection is production, the same as a live website. So the proofs read the code that stores and reloads tokens, the stored records the dashboard already fetched, and sample responses saved to a file. None of them refreshes a token.

If a live call is truly needed, it goes through the dashboard's own token store, at a time the office knows about, with someone ready to sign in again if it goes wrong. What stays human is the sign-in itself: the office decides who connects the account, and nobody else signs in on its behalf.

When is this the wrong move? If the office only needs a weekly export, Jobber's own reports may be enough, and a live connection is one more thing to keep healthy. Build the connection when the dashboard needs data every day.