Skip to main content

Experiencing intermittent issues doing a Fuel Transaction Import

JHyat-2091
Original Poster

Hello,

 

We have been experiencing intermittent issues doing Fuel Transaction Imports since Tuesday Oct 7, 2025.

 

What's unusual about these is that we are authenticating fine, however, when we try to send the Fuel Transaction, we are getting a InvalidUserException after we have authenticated. I would have expected a InvalidPermissionsException, but not a InvalidUserException. 

 

We can read Devices and Users with no authentication issues.

 

Some of our partners have been seeing the same issue.

Any ideas?

 

Thanks,

Jon

 

Join the conversation

You need to be logged in to reply to this post and participate in the Geotab Community discussions.

6 Replies

Hey @JHyat-2091​,

 

You say it's intermittent, so does that mean it's working some of the time and failing others? I wouldn't expect a permissions issue if that's the case, but if it's been failing consistently since a certain datetime, it might be easier to track down the issue. Also, how long was the fuel import working for you before you started getting these issues? And are you using a self-built importer or are you using one of the marketplace solutions?

 

Thanks,

Tucker

InvalidUserException is thrown during login with invalid user/password or when the credentials being used become invalid. It seems most likely that the session is being invalidated at some point during the import process. Does the included InvalidUserType include any information about what's going on?

JHyat-2091
Original Poster

Hi Daren and Tucker,

 

We are a fuel card provider and offer API connections to Geotab for several of our customers and we use it ourselves for our own fleet. We have had this integration for about a year and it has been working perfectly so far. Our solution is a custom solution using the Geotab SDK directly.

 

When a new fuel transaction happens on our card, we upload the fueling data to Geotab initially when we have volume estimates and then we re-upload it when we have actuals. This work is done by a queued job.

 

The queued job, when it runs 

  1. Calls Geotab authenticate to authenticate (this always succeeds)
  2. Calls Geotab addFuelTransaction (which sometimes fails and returns an InvalidUserException)

This all happens in less than 1000ms

 

We have recently added some additional logging to better define what “sometimes fails” actually means above. I'll have that data in a few days. 

The exact error message is: “Incorrect login credentials”

 

I'll hopefully have some more info in the next few days. I know this isn't very informative yet. I thought this to be something other API consumers would have also experienced due to some configuration change at Geotab or something. Hoping it would magically solve itself!

 

Thanks for the questions.

 

Hey @JHyat-2091​,

 

Which fuel card provider? Our team is the one behind BlueArrow Fuel, so I'm assuming we've already integrated with you guys but if not, we'd want to get you guys included in our integration as well.

 

And I would say at a minimum, you shouldn't be calling authenticate each time the queued job runs. Best practice is to store a session ID for the service account and then only authenticate if an API request fails for an invalid session. I don't think that will fix your issue, but worth updating anyways.

 

Let me know when you have more information. We have dozens of integrations running and we haven't seen this issue yet, so I don't think it's an API issue, but it could be a change but specific to what you guys are doing so hopefully your logs will explain more what's going on.

 

Thanks,

Tucker

I'd be interested in seeing the code that is sending fuel transactions to Geotab. As @TuckerBA-1087​ mentioned, it's very odd that an Authenticate seems to be running for every transaction. If you're using a Geotab SDK (e.g., the Geotab SDK NuGet package in .NET), the client should automatically use the original acquired session ID instead of re-authenticating every time.

 

This is a bit of a stretch, but is there any chance that the user credentials you're connecting with are being updated by some other process? I ask because if InvalidUserException is actually descriptive of the problem (we've had instances where the API returns exceptions that don't match the actual underlying issue), the user credentials being updated would explain both possibilities. If a user's password is changed, all existing sessions are invalidated. And obviously if it is changed and you try to login without updating their credentials mid-process, logins would begin to fail.

JHyat-2091
Original Poster

Hi @TuckerBA-1087​ and @DarenPorter-1148​ 

 

Thanks for all your help and questions!

 

Ok, so the new logging we have in the system has highlighted the issue for us and we have a solution for our clients. It turns out that all of the transactions upload properly for most of our customers. There are just three customers that have failures and we have managed to mitigate them by creating a new service account and authenticating with the new service account. I can't say why that makes a difference though. As far as we know, the permissions are the same. 

 

Lesson learned (uh, again!): proper logging saves the day

 

Tucker, we are a small digital fuel card provider in Canada called Fillip Fleet and currently operate only in Canada. There is a high penetration of tap-at-the-pump (and tap-in-store) available in Canada, which allows us to be digital-only for most of our customers. We do provide physical cards for customers that need them, but that is only about 1% of our transactions. Our system operates on the VISA rails, so it's not a fuel retailer brand specific card, although we do have partnerships with some fuel providers to provide rebates, special offers and the like. We plan to expand to the US in 2026 and are currently building out multi-country functionality in our system / app / webapp.

 

Again, thanks for your help!

 

 

Still have questions?