Webhooks randomly being marked Inactive

We run an integration between our app and Keap for our customers and in the last week or so our integration webhooks have started randomly being marked Inactive. There are no errors that we can see, no 410s returned, etc and we’ve never had this issue before.

What is the best way to track down the cause? It’s resulting in lost data and unhappy customers.

Good morning Leon!

Per our documentation, if we fail to successfully deliver a payload to the subscription endpoint four times within a thirty-minute window we will register that subscription as inactive to prevent additional overhead. I would ensure that your resources are not suffering from availability concerns (such as thread exhaustion, cold lambda spin-up times, etc) first, then if the problem persists to contact our Advanced Support team.

Note that you can also programmatically poll the resthook endpoint on a schedule to determine if any have been marked Inactive, and call for a validation on them if so. If the receiver endpoint is responsive, the resthook can be re-enabled immediately.


  • Tom Scott
    Keap API Engineer

this is happening to my endpoints also, frequently the webhook endpoints are marked as inactive! everything on ym side is good

@pagedesigner : I would encourage you to take the same preventative steps; our team just looked into one of these kinds of requests and found exactly as we expected, that the receiving server was non-responsive to the call, specifically when dealing with a payload that contained a large number of record identifiers. If, as an example, your receiver endpoint follows this pattern:

a) Receive a resthook payload
b) Perform an operation on each object of the resthook payload in the same thread (get, update, etc)
c) Return a response

Then you are likely running into an issue where the number of objects is causing step b to exceed thirty seconds, the allowable response time for the outgoing connection on our end. I would then determine if operations could be queued to perform asynchronously, while the main thread returns the positive response immediately.

a) Receive a resthook payload
b) Write the list of object ids to a “dirty record” table
c) Return a response
d) Schedule a thread to iterate the “dirty record” table in batches and perform some operation on them

If this is not the case, as I said you should contact our Advanced Support team through our ticketing system.