It seems like the API may have gone down in the last few days? just returns a "Internal Server Error".

10replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  •  Thanks for reaching out!

    We are aware of an issue at the root level and are working to address it.

    You can access the site on the /login level at

  • Hi, just curious, what are you using Dev API for? 

  • Thanks for responding to this Matthew - I think when it started working again I forgot to come back here and check on the thread.


    Unknown - I use it for a home-brew integration with Home Assistant.


    Matthew - the reason I came back to the forum here is I've written a few emails over the 'contact us form' in the last month or so and no one has responded and it seem that the 'chat' functionality has been removed from the website (the button is there but it never actually opens anything for me)... so hopefully you're still here and might be able to help. On the dev platform, my webhook has been randomly becoming disabled every few days. I have to keep logging into the dev site to manually re-enable it. I see no errors anywhere so I don't understand why it keeps getting disabled. Any ideas?

  • Is Bouncie a dead product?

    My device is still working, but no one responds to contact emails, the chat function has been removed from the website, and no one answers any questions on these forums. If the service is winding down, it would be helpful to let the community know.

  • Matthew,


    Thanks for reaching back out.

    First, Bouncie is not dead.  Quite the contrary. Our user base is growing each month significantly.

    Not sure what issue you are experiencing with our Chat.  It's up and running, and we handle several hundred each day.  Try this link [] Depending upon a few factors, the chat tool may lazy-load after the full website has been rendered.

    You can also chat directly in the mobile app.

    Is there a specific question I can help with here??

  • Hi Matthew,

    Thanks for responding. First off - apologies for thinking that chat isn't working - after you said that you are receiving many every day I looked at the site again and got it to work. The chat window was being blocked by a chrome extension (Disconnect) that blocks advertising / analytics/ etc... I haven't had that problem with chat popups before so you may want to take a look at why Disconnect doesn't like yours - it might be affecting other people as well.

    However, I stand by my frustration with the contact form team. They haven't responded in months to several inquiries I have sent that way. Anyway, the question I've been trying to get to you guys is above in the thread in my post from 12 days ago - on the dev platform, my webhook has been randomly been disabled every few days. I have to keep logging into the dev site to manually re-enable it. I see no errors anywhere so I don't understand why it keeps getting disabled. Any ideas?



  • I apologize for the dropped communication.

    I was able to find your inquiry, and it seems that after our engineering responded internally to your question, no one messaged you back.

    Here is the reply from our team as to the only known cause for the behavior you are describing.

    webhooks get disabled when we get lots of timeouts or errors from the endpoint, which receives webkook.

    Hopefully this helps your troubleshooting.

  • Thanks - do you happen to have any metrics on this? The system can spit out a ton of messages in a short time during a trip, so if I happen to have taken my server offline for a few minutes for one reason or another and it coincides with someone driving the car, will this happen? Put another way, does this get triggered by just a simple count of timeouts/errors... or does it take into account this happening over a significant amount of time?

  • Matthew, the ratio is 0.95 analyzing at least 100 messages in 4 hours. So if 950 webhooks out of 1000 failed in 4 hours then the webhook will get disabled.  

    I suggest using queues like RMQ, SQS or MQTT to persist incoming webhook data if you can't process it immediately or the rate is too high. Your code can process data from the queue when it can.

    Webhooks have a retry with an exponential delay of up to 11 hours. That should cover cases when your API gets restarted, deployed, or stopped for a short time.

  • Thanks - this is very helpful.

Like Follow
  • 1 yr agoLast active
  • 10Replies
  • 160Views
  • 4 Following