Getting timeouts when sending to a BIKA webhook

Hi

I am getting timeouts when sending webhook data to an automation which is stopping data from coming into BIKA.

This is not bulk sending data just 1 to 15 every minute or so.

Can you take a look, or let me know if there is currently and issue? This is causing us major issues!

A small update - it is taking roughly 60 seconds to get a response back on a webhook, this normally takes <1 second. Also this is a POST sent from AITable which is normally very fast. Although the issue is there when sent from anywhere including Postman and other tools

Many Thanks
Ben

Hi

Is anyone able to look into this from BIKA please?

Thanks

Is there anyone from BIKA support able to help? This is affecting my business operations.

@Kelvin @pengjin

Thanks

Hi @Ben_M
Request timeouts are usually caused by backend services that the API depends on taking too long to respond, or due to network connection issues.

  1. When the timeout occurs, is it that only part of the data fails to be written to Bika, or is none of the data written at all?
  2. Are you sending only one record at a time, or multiple records in a single request?
  3. Could you please share a full screenshot of your request parameters or record a short video to help us understand the situation better?

Hi @pengjin

Thanks for the reply.

  1. I don’t really know, I am sending some JSON data from AITable to BIKA to transform the data and then send back to AITable. The delay seems to be in the response from BIKA to receiving the webhook request. It has always been milliseconds and now it seems to be 60 seconds in which case most other systems would timeout.
  2. this is one record at a time
  3. AITable sends this

BIKA then just runs a script to update a record back in AITable. The issue is not the updating, but when you use a button in AITable to send an HTTP request is spins until it receives a response, this is taking 60 seconds. Updating the actual record still only takes a second and I can wait for that to happen in the background.

I have attached a video that hopefully shows what is happening

Just to add, this delay is not just AITable, but activepieces and HubSpot. Actually HubSpot times out after 20 seconds. At least AITable tries for longer

Thanks

Ben

hi @Ben_M
Are you saying that previously you could successfully send webhook data to Bika through AITable automation without timeouts? Could you please check the run history of your automation to see if there are any error messages?

Hi @pengjin

Yes have been able to do this fine for a couple of weeks, just from yesterday it is now taking 60 seconds to get a response from BIKA.

There are no errors from AITable or BIKA as it does successfully happen, just a long delay.

If I send a request from HubSpot it errors when sending into BIKA due to timeout.

Hi @Ben_M
Do you mean that the API request is successfully sent, but due to the response timeout, the data fails to be written into Bika? Is that understanding correct?

Hi @pengjin

not quite.

I send an HTTP POST from AITable to BIKA, BIKA should respond to that webhook with a 200 almost immediately (but it is taking 60 seconds), then BIKA should update a BIKA record, then update the original AITable record with some data.

If you send a webhook from postman into BIKA, the 200 response is taking 60 seconds (ish) when it was always instant before.

It’s almost like BIKA is overloaded with webhook requests which is why it is taking so long to respond.

Hi @Ben_M
I just used Postman to create a new record in BIKA, and the response time was only 3.06 seconds — it was successful.

May I ask if your local network is functioning normally?

Hi @pengjin

In the past hour or so, I have also been getting responses in that sort of time. There have been some slower but whatever the issue was it seems to have sorted now.

Believe me, I have been testing this every hour for the past 48 hours and only now is it starting to act like it used to.

Just to clarify, I tested this on multiple machines, browsers, networks and locations.

Thanks
Ben