Sometimes HMRC API authorisation ends early

Sometimes HMRC API authorisation ends early it should normally last 18 months.

Didn't find your answer?

Developers have just been told why this happens from time to time.

This is what we have been told (I thought you might like to know):

---------------------------------------------------------------

We are aware that the authorisation can expire before the 18 month period has elapsed if the refresh token becomes invalid.

The common reasons that this can occur are detailed below:

 

  • User Credentials Reset: The end-user has reset their Government Gateway password or changed the Multifactor Authentication device associated with their account. This causes existing grants to be invalidated. This is far more common than we were expecting and could well be down to credential sharing/resets on shared accounts.
  • Multiple Requests with Same Token: This is mainly occurring when more than one request to refresh the same token is received within a few milliseconds of each other. One refresh will succeed, but the other will fail.
  • Not Storing the latest Refresh Token: A new refresh token is provided each time a refresh token is used. Please ensure that you are accurately recording the latest refresh token. This coupled with multiple requests with the same refresh token can mean that one refresh gets through and succeeds, while the other fails and your software ends up persisting a now expired refresh token.

Replies (17)

Please login or register to join the discussion.

avatar
By snickersinatwix
09th Nov 2021 13:22

all just a total pain in the blooming neck

Thanks (0)
By kenny achampong
09th Nov 2021 13:31

What on earth is the point of making it 18 months anyway ? The poor member of staff whose number we've put down gets bombarded with texts, and if he's away from a signal, we can't file a VAT return. Why did they think it was a good idea ?

Thanks (0)
Replying to kenny achampong:
avatar
By johnhemming
09th Nov 2021 14:06

That should not happen. There should be a text every 18 months.

Thanks (0)
Replying to johnhemming:
By kenny achampong
09th Nov 2021 18:16

Thats what I said/meant. It's two texts per client though, every 18 months. So for one quarter, every year and a half, say if you have 4 staff members filing 120 returns a quarter thats 240 texts, with a text from the staff member to the nominated phone number, then the text back. I make that the person with the nominated phone receiving and sending 420 texts. Or can you assign a phone number to individual clients maybe ?

Thanks (0)
Replying to kenny achampong:
avatar
By johnhemming
09th Nov 2021 19:03

If, however, you have the clients on your ASA credentials rather than using an individual gateway for each client then it is one authorisation every 18 months.

Thanks (0)
Replying to johnhemming:
By kenny achampong
09th Nov 2021 19:31

Oh. Is that easy to do ? I did manage to get through to the VAT helpline recently and they said the ASA account will only have the first client you set it up for and it isn’t meant to have any other information/purpose. He was as perplexed as me about what the point of it is. Thanks btw.

Thanks (0)
Replying to kenny achampong:
avatar
By johnhemming
10th Nov 2021 10:45

That all sounds a bit confused.

The ASA can have any number of clients, but it is a bit of a waste of time if you don't actually have any clients on it.

If you use ASA credentials then this problem will probably disappear.

Thanks (0)
avatar
By rmillaree
09th Nov 2021 14:00

Cheers johnhemming

"User Credentials Reset: The end-user has reset their Government Gateway password or changed the Multifactor Authentication device associated with their account. This causes existing grants to be invalidated. This is far more common than we were expecting and could well be down to credential sharing/resets on shared accounts.2

whats the implications of this practicably speaking

Eg surely the system should refresh when user credentials are updated and bring through all existing data as would have been the case had the change not been made?

are you saying it can simply go up in a puff of smoke ? so that data can no longer be retrieved? hopefully not

head scratching going on at present - this whole solution must be robust enough to pull through all live data for all clients to be fit for purpose - if you accept stupid stuff like newly appointed clients not having hisorical API data being made available the whole kit and kaboodle is simply not fit for purpose.

Makes one wander if soneone sits downto do the necessary logic before any programming has been started. Anecdotally the API data whilst mostly being ok is so unreliable its clear that the whole system at present is not fit for purpose.

One further question our software BTC does not being through negative tax deducted at source amounts for payroll ? do you know if thats an HMRC known issue or simply a BTC one ? - its very dangerous to take refund amount and change that to Nil on API data for obvious reasons.

Thanks (0)
Replying to rmillaree:
avatar
By johnhemming
09th Nov 2021 14:09

Sorry I don't really follow your question at the end.

The idea of invalidating the authorisation when the password or TFA device is changed is to give a mechanism to ensure that everything that is authorised is properly authorised.

Thanks (0)
Morph
By kevinringer
11th Nov 2021 15:46

Why is any refresh/time limit needed?

We have a HMRC user ID and password which enables us to log into SA, see how much state pension Mr Smith earned, see his name, his date of birth, how much tax his paid last year, access submitted Tax Returns etc. All that is accessible via a user ID and password.

But to get the SA API to work I have to input my passport number, and my NINO, tell GOV.UK when I last took out a mobile phone contract, and a whole pile of other personal info that is nothing to do with the practice. And I have to go through this nonsense every 18 months. And that's to retrieve pay and tax details etc, but using the same user ID and password as I use to log into SA etc.

So why do I just need user ID and password for SA, but need SO much more for SA API?

It's a real pain because at busy times we have to re-authorise our SA API regularly: more than once a day sometimes. If only it were just once 18 months.

And every 18 months we have the same palaver for each MTD VAT client: we handle several hundred VATs. Just image the situation with MTD ITSA. We have about 10x the number of clients in ITSA that we have in VAT. We already have problems where multiple codes are coming through to the phone at the same time because several staff are trying to submit VATs when the 18-month renewal is up, and HMRC texts don't say which client each text is for. We waste so many hours with this. And some bright spark in HMRC reckons this is progress.

Thanks (0)
Replying to kevinringer:
avatar
By johnhemming
12th Nov 2021 11:07

>And every 18 months we have the same palaver for each MTD VAT client
If you are using the ASA credentials then it should only be once.

Thanks (0)
Replying to johnhemming:
Morph
By kevinringer
12th Nov 2021 11:47

John, we use Absolute VAT Filer for most clients, Sage desktop for a smaller number of clients and QuickBooks Online for an even smaller number. We use our ASA credentials for all clients for all software. We only need to do the 18-month authorisation once for QBO and then it works for all QBO clients, but for Absolute VAT Filer and Sage we have to do it for every client separately.

Thanks (0)
Replying to kevinringer:
Morph
By kevinringer
12th Nov 2021 12:51

I had a senior moment and forgot this thread is about SA API and not MTD VAT, thus my previous post. We use PTP for the SA API and have to re-authorise regularly (sometimes several times a day during January when loads of staff are using the system). PTP are aware of this and have been investigating for some years.

Thanks (0)
Replying to kevinringer:
avatar
By rmillaree
12th Nov 2021 13:04

PTP are aware of this and have been investigating for some years.
Hmmm sounds like they are telling you porkies if they say they are still investigating and have not got to the bottom of it after several years - i doubt the process that btc uses and works is a trade secret - i am guessing they simply follow the advise or have asked how to ensure it works if there were issues.
hmmmm who own PTP - that will be IRIS i think - that says it all.

Thanks (1)
Replying to kevinringer:
avatar
By johnhemming
12th Nov 2021 16:06

That looks like an implementation question which is not HMRC's fault. It probably relates to having separate tokens rather than a single token that is shared.

Thanks (0)
Replying to johnhemming:
Morph
By kevinringer
12th Nov 2021 16:32

It's a single token that is shared. PTP have told me that the reason they can't get to the bottom of it is the HMRC Development Team will only discuss test cases, and there are no test case problems, so PTP have to speak to HMRC Live Team but they will only discuss if PTP have 64-8 in place!

Thanks (0)
Replying to kevinringer:
avatar
By rmillaree
12th Nov 2021 11:57

"It's a real pain because at busy times we have to re-authorise our SA API regularly: more than once a day sometimes. If only it were just once 18 months."

We use BTC and only need to re-authorise the SA API once every 18 months - other than that it works without hassle (when info is available) could it be something your software provider is not doing in the most efficient manner that is causing your issue here ? are you with IRIS by any chance?

Thanks (0)