HTTP 302 response to webhook - accepted?

[dsandberg]

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.

[dsandberg]

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?

[Renaissance]

@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.

[dsandberg]

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?

[Renaissance]

@dsandberg 

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

[dsandberg]

---

@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.

[Renaissance]

@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.

[dsandberg]

---

@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.

[Renaissance]

@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.

[dsandberg]

---

@Renaissance wrote:
@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.

---

In any event, it doesn't matter at this point. I know the 302 response was coming from our side, but my original question is what Authorize.net does if they receive that code in response to a webhook.  As I said, from the documentation the suggestion is that only an HTTP 200 would be accepted as a successful webhook reception and therefore not be repeated, but I'm not sure that's what we were seeing in our testing, so I was hoping to get an official statement on that behavior (a statement I still haven't gotten, so I am unable to accept anything in this thread as the solution even though our webhooks code has already been completed and sent along for testing).

Thanks much for the input, nonetheless!