Reply
Contributor
Posts: 44
Registered: ‎02-12-2018

HTTP 302 response to webhook - accepted?

In our testing with an AWS ELB forwarding webhook messages to the correct test server, we are finding that the webhooks appear to not be retried after we have processed one, which is good.  However, the ELB appears to be returning an HTTP 302 message to Authorize.net rather than the HTTP 200 that the Authorize.net webhooks documentation says needs to be received for webhooks to not be retried.  And I found exactly one thread about webhooks and HTTP 302 in this forum, in which it was seemingly stated that webhooks would NOT recognize 302 as a succesful webhook response.  But that thread was over two years old, so perhaps it has changed since then?

 

We'd like to be sure so that we don't get an unpleasant surprise later when this code goes into production.

Contributor
Posts: 44
Registered: ‎02-12-2018

Re: HTTP 302 response to webhook - accepted?

I have some more detail on this.  The 302 response is actually coming from an error page in our app, so we'd actually want the webhook to be retried if it receives a 302.  This appears to be consistent with what the documentation says will happen, but in our testing we have not seen webhooks retried after we've replied with a 302.  Can anyone confirm the actual intended behavior here?

All Star
Posts: 707
Registered: ‎11-05-2018

Re: HTTP 302 response to webhook - accepted?

@dsandberg

Not sure about this, but the way to find out is to trigger one of these 302 responses and then make a call for webhooks history. Find the Webhook in question and see if the status is delivered.
Contributor
Posts: 44
Registered: ‎02-12-2018

Re: HTTP 302 response to webhook - accepted?

Interesting - I didn't know there was an API call for webhooks history.  (We aren't doing webhooks configuration via the API.)  I didn't see any reporting facilities on Authorize.net's site for webhook history - or is it there somewhere and I missed it?

Member
Posts: 1
Registered: ‎12-13-2019

Re: HTTP 302 response to webhook - accepted?

302 Found message is an HTTP response status code indicating that the requested resource has been temporarily moved to a different URI. Since the location or current redirection directive might be changed in the future, a client that receives a 302 Found response code should continue to use the original URI for future requests. Thanks for sharing..

 

Appvalley app is the best app. This app design for games in iso devices. I love this app, I really enjoy it. Click more information AppValley

All Star
Posts: 707
Registered: ‎11-05-2018

Re: HTTP 302 response to webhook - accepted?

@dsandberg 

 

You can find it on the webhooks documentation. You execute GET and POST requests and append the parameters to the uri. 

Contributor
Posts: 44
Registered: ‎02-12-2018

Re: HTTP 302 response to webhook - accepted?


@Renaissance wrote:

@dsandberg 

 

You can find it on the webhooks documentation. You execute GET and POST requests and append the parameters to the uri. 



Sorry, I'm afraid that's not what I was asking.  I know where the API documentation is, but I don't have sufficient reason to spend company time writing a piece of software to use that API, just to answer an API question that should be easily answered by Authorize.net support.  I was hoping that perhaps Authorize.net had implemented something on their website (the one you see after you login to a sandbox, with the "Home / Tools / Reports / Transaction Search / Account" toolbar) for doing a similar search of webhook history, as such a thing could be used to evaluate the webhook behavior from Authorize.net's side, and without needing to invest time into writing additional client software solely for that purpose.  But unfortunately I don't see any such facility on the website.

All Star
Posts: 707
Registered: ‎11-05-2018

Re: HTTP 302 response to webhook - accepted?

@dsandberg

You said you didn’t know there was an API for webhooks so I pointed you to it. You are correct. Auth.net interface has nothing for webhook tracking, only the screen to set up your endpoints, activate, etc. if you have a server side log then you can just check for auth.net IP address hitting more than once. They use only one or two ips to deliver the webhook.

Can you advise why you have a 302 on your webhooks endpoint? I agree that this creates more work than may be necessary, but issuing a 302 on your endpoint isn’t making sense to me.
Contributor
Posts: 44
Registered: ‎02-12-2018

Re: HTTP 302 response to webhook - accepted?


@Renaissance wrote:
@dsandberg
Can you advise why you have a 302 on your webhooks endpoint? I agree that this creates more work than may be necessary, but issuing a 302 on your endpoint isn’t making sense to me.

That response code doesn't seem to be entirely under our control ... we certainly don't have any code that is generating it deliberately.  If something on the webhook processing on our side fails, the result is a redirect to an error screen, and that seems to make .NET want to issue a 302 response code.  Preventing that error screen in the case of webhooks would be a major undertaking and a significant structural change to our application.

 

The hope is that, now that the bugs that produced 302 responses during testing have been fixed, it won't happen in production ... but unfortunately no software is ever perfect and it would be foolish to assume it won't ever happen again.

All Star
Posts: 707
Registered: ‎11-05-2018

Re: HTTP 302 response to webhook - accepted?

@dsandberg

That 302 has to be somewhere in your code. 302 is for resources moved to a new uri. I am not familiar with .net so it may be in the framework and not in any code you have manually written. The webserver will not issue a 302 on its own. It is either in the server side code or in a server configuration file. I would
say that would have to be the case.

That’s why I thought that was odd. You want your webhooks endpoint tied to a uri that never changes. I use Apache and PHP for everything I do, and with that it is either a header coded in or a mod rewrite directive.

You could type in your webhooks url directly in the browser and see where you get redirected to.