REST Hook Delayed Confirmation Flow: Does it work? outlines two confirmation flows. “Instant Confirmation” and “Delayed Confirmation”

Due to my server-less, ecosystem, I an unable to use the “Instant Confirmation” (Option 1 in the doc)

Hence I am trying to get get “Delayed Confirmation” to work.

The “Delayed Confirmation” (Option 2 in doc) is returning 404’s

Original question was posted as a reply to a different thread and thought it might be buried and /or warrants a dedicated thread related to “Delayed Confirmation” flow, so re-asking here.

My Original Post is here:

The gist is:

How can we use the “Delayed Confirmation” flow (aka Option 2 in with InfusionSoft ?

or has anyone got “Delayed Confirmation” to actually work ?

I call the /hooks/{id}/activate endpoint with the Id, returned in the original Create Subscription POST, and I dig out the Hook-Secret from PostBin. So it seems like I am following the documentation (which InfusionSoft pointed me to.)

Thanks in advance.

@Tyler_McMaster, just to be sure, are you using the /verify endpoint as described in the REST documentation, or are you trying to hit an /activate endpoint as described in your post?

The documentation on /verify endpoint, states that it will post a request to the URL in the original request, which then puts me back in the situation, where I cannot respond to HTTP Request, because I am in a server-less environment. (Unless I am reading the InfusionSoft documentation wrong, but for verify it says " Infusionsoft will make a POST request with a temporary secret to the hookUrl you provided during creation"

The way I interpret that, is that it is only for the “Instant Confirmation” flows as documented, and not to be used in the “Delayed Confirmation” flows.

FWIW, I did try calling the ‘/verify’ endpoint directly as part of my “Delayed Confirmation” flow, but I get HTTP Status 500, General Error.

There is no /activate endpoint based on the Subscription Id, as specified by the, so I was hoping for non-documented functionality, since InfusionSoft cites the documentation deliberately.

So the problem you’re going to come across isn’t so much real time or delayed validation. The issue is that in order for you to get data from IS the webhook must be validated. Delayed would be fine but you are wanting to then change the url to an unvalidated url. IS validations can’t just be modified to change the url location, otherwise, what’s the point of validation?


In fact that is all I am trying to do, is confirm the subscription, and the difference according to the document for Instant vs Delayed Confirmation is that:

Instant Confirmation, provides the Secret as part of the RESPONSE (Which I cannot do) and Delayed Confirmation (according to the spec), you can pass the secret as part of the POST Header to /activate in the spec … or /validate based on your comment.

So the whole read is not about real-time or not, its that I have no control over Response Headers.

So according to the patterns: “Instant Confirmation” passes the X-Hook-Secret in the Response Header and “Delayed Confirmation” passes the X-Hook-Secret in the Request Header.

I’ve tried the Posting the X-Hook-Secret in the Request header to the /Verify end point at get 500’s

For either the Subscription ID (e.g. 10) or the Code (e.g. '/hooks/order.add/verify' )

in which case I normally get HTTP Response 500 with “General Error” message.

I cannot find any combination of HTTP POST with X-Hook-Secret in the Header that is successful. Hence, my fundamental question if the anyone has this (the “Delayed Confirmation” pattern implemented.)

Hi @Tyler_McMaster . The Infusionsoft REST API supports immediate confirmation of REST Hook subscriptions with subsequent ad hoc verification requests. Delayed confirmation is not available at this time.

Immediate confirmation happens automatically during Create a Hook Subscription. If verification fails, you can request another verification attempt with Verify a Hook Subscription.

In either case, the hookUrl you provided during the initial Create step must respond to us with a status code of 200 and return the same secret.

I’m pretty sure that delayed isn’t an option…not at the moment anyway. You’re “server less” environment doesn’t keep you from using a relay. It costs $15/mo for a simple basic server that can house the webhook and relay the results to your IronIO exactly as you please it to. This would be what I would do anyway.

@John_Borelli … then its no longer server-less :wink:

@mike.christianson Does InfusionSoft have a feature request list open to the community ? (for up votes and such) It would be a better match for our current state to use the “Delayed Confirmation” pattern outlined by Just didn’t know if there were a way to get this on development roadmap.

Ok, so I’m not sure why that would be a “requirement” in any project but if that’s what you need then you probably can’t do what you want.

@Tyler_McMaster We will soon support Delayed Confirmation. Stay tuned. :grin:



The Infusionsoft REST API now supports’s “delayed confirmation” of subscriptions.

See also API Additions and Changes 2017-08-08 - #2.

1 Like