Noobish question: Are you supposed to respond to realtime updates (RTUs) somehow? Keep getting RTUs on the same dispute which FB has already refunded. So, should one echo something in the RTU callback? Just been through all the documentation I can find (again) and can't seem to find anything on response.
Yes, you need to return a 200. The content type or response body do not matter. Anything else results in Facebook retrying the callback until a 200 is received, so you'll get lots of spam
Related
We have POST API that gives particular user's contact details in response. But as this is confidential data, to access this detail, anyone accessing it needs to put verified mobile number.
The request looks like:
POST /api/userdetails
{
"userid": 123,
"mobile": "+1394839843"
}
What should be status code if "mobile" number is not a verified number in our database?
What should be status code if "mobile" number is not a verified number in our database?
From a very high level: think about what you would expect a plain old web site to do if a user submitted a form with a "not verified number" and do that.
The charts in Michael Kropat's Stop Making It Hard breaks the process down into more specific questions.
Is there a problem with the request? That's clearly a yes, here, so we know immediately that you'll want to use some code from the 4xx class.
From there, it's just a matter of looking through the semantics of each code and seeing which one best fits.
400 Bad Request is the generic client error, so you use that if you can't find a better match.
403 Forbidden is roughly "I understand your request, but decline to act upon it." This is most commonly associated with authentication and ACLs, but the standard doesn't actually require that. Given your description, it's not a bad match.
422 Unprocessable Entity from WebDav, is another possibility. I'd reject it, on the grounds that the schema of the message body is perfectly correct, the problem is that the specified value isn't aligned with the current state of the server. You might want to review a previous discussion about 400 vs 422
I am learning to work with Facebook Messenger API. I have successfully setup a webhook, I have subscribe to the application. But when I send message to my Page I receive multiple instances of the same message like a burst.
I am storing messages which I send from my application when it is receive at the Webhook.
A view of my database look like in the screenshot below.
http://prntscr.com/au3emz
I am guessing it may be because the message is still unread? Just a wild guess may be someone else know for sure. I tried exact example of the Facebook Office (Node) and it is happening there as well.
Thanks.
When someone send a message to your Facebook Page, Facebook transfer that message to your Webhook address and waits for a http response like OK. And it keeps sending the same message to your webhook until the response arrives.
From Facebook webhook docs (Webhook docs;
Required 200 OK Response
When you receive a webhook event, you must always return a 200 OK HTTP response. The Messenger Platform will resend the webhook event every 20 seconds, until a 200 OK response is received. Failing to return a 200 OK may cause your webhook to be unsubscribed by the Messenger Platform.
A delivery receipt will automatically be sent to the user after your webhook has acknowledged the message. You can also use Sender Actions to notify that the message has been seen.
You can see that all of those messages have the same timestamp.
As a solution; you can define a message queue to store those messages, and you add message to the queue if there is no such message in queue with the message sender id and timestamp.
Hope this helps,
This is often caused if you subscribe to the echo message callback event.
From the documentation;
This callback will occur when a message has been sent by your page.
What this implies is that you will get back a copy of any message your bot sends. From your code, this will cause a form of infinite loop; you would keep receiving Response 1.
You can easily confirm this by inspecting the value of text; you'll find it's also Response 1 and on inspecting the entire payload it will have the field "is_echo":true.
Solution:
Edit your page subscription to exclude message_echoes
I had the same issue with my test application. I am still new to Messenger API and my solution may be naive.
Initially, the code was like:
if (text) {
sendTextMessage(sender, 'Response 1');
} else {
queryDB(
sendTextMessage(sender, 'Response 2');
)
}
res.sendStatus(200);
Which kept sending Response 1 forever. The correct code is:
if (text) {
sendTextMessage(sender, 'Response 1');
res.sendStatus(200);
} else {
queryDB(
sendTextMessage(sender, 'Response 2');
res.sendStatus(200);
)
}
You have to sendStatus always after sending a message.
I detect that betwen facebook invocation and my response with 200 statuscode my code was waiting 2 seconds, my code is syncronous, thus , my total code responds with 200 code 2 seconds after..
Many probes results for me that if i dont send 200 status code to facebook in one second facebook resend message to webhook. For me the aolution was analyze the incoming message and obtain the timestamp key (A), then i get a timestamp.from a database (B). compare A==B.. if is true, i do nothig and ends.my webhook processing, if is false then write in the database the new timestamp (A) and continue with webhook proceasing.
Solution
I sent a subscription request again to my application to stop these messages.
So essentially what I experienced is that webhook re-subscribe app after having received message will stop any further receives until next message.
This is although the solution the core of "Why this happens?" is not known yet. Will be glad if someone can contribute.
Thanks.
Is there any possibility of "listening" to the state of GET SiteCatalyst image requests ?
I'd like to run a callback function only when the requests are over, to be more clear when they receive the 200 status code and I'm sure they're done.I'm confident no "built-in" method is available and maybe I should hack the core s.track.s.t() function...?Thanks a lot.
You are right, there is no global "built-in" callback method for when the Adobe Analytics request is complete.
A couple notes I should mention to you about attempting to hack the core code:
1) If you are using the AppMeasurement library version 1.4.1+, in some circumstances, a POST request may be made instead of an image request.
2) Responses that are not 200/OK or otherwise completed/successful does not necessarily mean the data failed to be sent to Adobe. Most common scenario is a NS_BINDING_ABORTED error returned.
The main bad effect I'm getting here is what I previously thought as a double XHR request.
It wasn't. In reality the first request gets redirected as it would be the first visit of a new visitor (302 status) and a new visitorID is brought down by Adobe server.
Then the redirected "200 status" request is made with this new visitorID within.This is bad because every XHR requests would result in a new visit of a new visitor even though a previously set "s_vi" cookie is there in browser, with the lack of previous collected data for that user.I know what XHR redirects couldn't be blocked so I'm wondering if there is a way to "tell" Adobe server it's not the first request ever made, in order to stop the redirect and do not use a new visitorID.
what should my server response to the facebook RealTtime Update post request to indicate that the RTU request is handled successfully, I have read the docs for couple times but I cannot find the answer. I am kind of frustrated, looking for your answer.
Duplicated question here
On GET request from facebook you should just echo $_GET['hub_challenge']
On POST request from Facebook:
If your page responded with Status Code:200 OK - facebook thinking that everything OK
If something went wrong and you've sent not 200/OK - facebook will try to resend it later
I am trying to add the iOS 5 Twitter API to my app, and Twitter is giving me crap about sending the same direct message a second time.
Twitter response, HTTP response: 403
Response Data
{"error":"There was an error sending your message: Whoops! You already said that.","request":"\/1\/direct_messages\/new.json"}
Is there anyway to get around this so I can test my app?
Why don't you try sending a random message or the (stringified) time? It would be unique an each occasion, and it wouldn't require you to hack/work around/otherwise violate Twitter's this restirction.
You can tweet the same message multiple times if the text is never exactly the same.
For example, 1001tweets helps you to post multiples times some of your tweets. To do that, it keeps only the tweets containing a link and changes it using an URL shortener.