I was able to use square's webhook API based on descriptions here, https://docs.connect.squareup.com/api/connect/v1#webhooks-overview
and payment webhook was working fine.
Recently, I noticed that after completing a cash payment my webhook event handler
is not receiving any PAYMENT_UPDATED notifications.
I'm able to get the Test Webhook Notification trigger with my event handler service and I did register the PAYMENT_UPDATED webhook for my location.
This service was working before, is there any new changes for square-connect api?
There is no guarantee that the webhooks notification will successfully go through. If it fails for any reason, Square will not attempt to resend it. You should definitely use alternate methods (such as the ListTransactions endpoint) to fully verify the data.
Related
I set up a glitch service as described in the Meta doc to receive notifications of WhatsApp received messages via a webhook. However, messages notifications are not received at all, not even pressing the test button of the webhook. Please, note that it's not a general configuration problem, since other notifications (e.g., account_alerts) are properly received.
(I'm using the test phone number provided by Meta)
Any hints about this issue?
Turned out it was a bug: https://developers.facebook.com/support/bugs/856675538926230/
(Now it seems fixed)
I use Twilio's WhatsApp API.
Incoming messages, status updates, are sent to my server via callbacks - standard stuff.
I also use several services which ride on the same callbacks - e.g., Frontapp, Missive, and the like.
What is the best way to 'fan out' callbacks to the other services? Is making a separate HTTP post call to each of the other service, mimicking the format of Twilio's callback the best way?
Intuitively, I shouldn't be able to use HTTP redirect, because it'd only allow me to forward, and not fan out the call. Am I right?
I’d go with a simple function (e.g. Lambda, Zapier, etc.) that will:
receive the webhook from Twilio
respond ‘200’ (otherwise Twilio will try the fallback Url)
replay the payload to other listeners
Your stretch goals could include:
async delivery/retries (write the payload to a DB, listeners pickup on that write and deliver/retry their respective services, independently)
Twilio signature checks (duh)
Happy dev
We have an existing set of applications that use Urban Airship for notifications. We want to automate the testing of the server component.
We use automated testing as far as possible. Specifically, I want to be able to validate that when I make a /api/post call for a specific tag, then Urban Airship generates a notification for that tag.
In an ideal world, I'd make a web REST call along the lines of 'return when notification received for tag=XXX or timeout', and validate that the response was what I expected.
Does such a call exist, or can anyone suggest another approach other than including phone hardware?
Charles
There's no end to end callback for any push service since it goes through a variety of other services (APNS, GCM). In other words, you can't do an HTTP request to Urban Airship, then have a call back when the notification is received on the device. The best that you could do, is use Urban Airship's API to do a post call to send the message, then check that the response is a 2XX response. The 2XX response doesn't indicate that the push was received on the device, but it at least validates that UA has received the request to try and send that notification.
Another option that you could look into is using a service such as appthwack: https://appthwack.com/ I'm not sure if they are able to test push notifications, as it looks like they use emulators, but it's worth looking into imo.
The documentation for IronMQ push queues describes how endpoints should handle/respond to push messages. However, I get the impression this is for normal webhooks and I can't find any documentation or examples of what to do when the endpoint for a push queue is an IronWorker.
Does the IronWorker framework take care of responding to the IronMQ service when it starts a new IronWorker task for the message pushed onto the queue, or does my IronWorker code need to handle the response? If I need to handle it in my code, are there any variables automatically provided to me that represent the webhook request and/or response?
As I mentioned above, I've looked for example code but all I've found are IronWorker webhook examples that receive POSTs from something like GitHub, not from IronMQ. If there are examples out there for what I'm trying to do please point me to it!
There's actually a special subscriber format just for IronWorker as specified in the Push Queue documentation here: http://dev.iron.io/mq/reference/push_queues/#subscribers . Eg:
ironworker:///my_worker
That will kick off a worker task whenever something hits your queue. Or you can use the worker's webhook URL. And you don't need to deal with the response, as #thousandsofthem said, IronWorker will return a 200 which acknowledges the pushed message.
IronWorker API will respond immediately for a post request with "HTTP 200 OK" status and queue a task after that, it's too late to respond something from running task.
You could find exact webhook value on "Code" page (https://hud.iron.io).
Screenshot: http://i.imgur.com/aza7g0h.png
Just use it "as is"
I have a few Android phones. I'm pushing messages to them via Amazon SNS to GCM, using boto in Python. One phone always receives the messages. The other one does not.
The first time I send a message to the problem phone, it appears to succeed but nothing goes through. When I go to the AWS console and look at the list of endpoints registered to my app, it now shows "false" under the Enabled column.
The second time I send a message, boto raises an exception with a message in it: "Endpoint is Disabled"
What are some reasons why an android phone would not receive GCM messages? Are there user settings that can disable this?
Probably you figured it out, however, I post the answer for future use. This is a good article around this topic and addresses some possibilities about the problem.
Based on your explanation I think the Token for the android phone is expired and it needs to get re-registered with the GCM, then the SNS endpoint should be updated.
Token may have expired, or it may have been cleared from the app's storage. On your Android app, create a class that extends FirebaseInstanceIdService and override this function:
#Override
public void onTokenRefresh() {
// Get updated InstanceID token.
String refreshedToken = FirebaseInstanceId.getInstance().getToken();
Log.d(TAG, "Refreshed token: " + refreshedToken);
// If you want to send messages to this application instance or
// manage this apps subscriptions on the server side, send the
// Instance ID token to your app server.
sendRegistrationToServer(refreshedToken);
}
Also create your own sendRegistrationToServer. On your backend, implement a function that receives the token and assigns it to that endpoint's ARN. This way, your backend will always know where to send the notification.