WhatsAPI how to manually send my lastseen to the whatsapp server may be to a previous date?
I'm Using whats app api from https://github.com/shirioko/WhatsAPINet
You can't any more. That loophole has been fixed in the underlying API for years. Now you can only indicate to WhatsApp who should be able to see your LastSeen timestamp, but the calculation of the actual timestamp value to be displayed is handled entirely server-side.
Related
I'm new in using WhatsApp cloud API, I've set up one webhook with my WhatsApp cloud API.but the problem is that after some time it sends an inbound notification of an old message again to my webhook.
If a notification isn't delivered for any reason or if the webhook request returns a HTTP status code other than 200, we retry delivery. We continue retrying delivery with increasing delays up to a certain timeout (typically 24 hours, though this may vary), or until the delivery succeeds.
Whatsapp webhooks documentation
I will share my experience and maybe it can help some of you.
I was returning the status code 200 from my server. But Whatsapp Api Cloud still returned 15 notifications per message.
the problem was that in the past, maybe one month before. I had actived webhook messages notifications, but I didn't respond with the status 200. meanwhile I was building the sending messages backend logic. so , there were thousands of webhooks no responded with the Status code 200. So my facebook app went crazy, and when I decided to respond with the status code 200. it didn't work.
the solution was to create another facebook app. and the webhooks worked well.
Had the same problem, tried to delete the app but didn't work, I was still receiving old messages from the old app.
TLDR; don't use the same test number with more than one Facebook App.
Even creating a new app, Phone Number ID and Account ID were still the same, my speculation is that the webhooks payloads are tied more to the test phone number rather than the Facebook App.
For this reason, if you have another application with the same test number and a not working webhook, it keeps sending the same messages to both webhooks.
Within the POST defined in your Webhook, you should always return HTTP Status 200, check that this happens even within your Promises
Webhooks for WhatsApp Business Accounts
This is an authentication flow, which logs in the user with only the phone number provided (Whatsapp style). The Steps are:
User enters phone number and sent to server.
Server generated 4 digit random key, and save the pair (phone,key) in DB.
Server asks 3rd party SMS service to send key to phone.
SMS service sends message.
User enters the key from sms, and together with phone, sent to server.
Server checks the pair against the DB.
If pair exists, server sends back a token for further calls.
What I am trying to understand is where services like Twilio and Nexmo fit in (or replace parts of the flow).
From what I understand, looking at Nexmo for example,
I can replace steps 2 and 3 with an API call to:
https://api.nexmo.com/verify/
and save the request_id from the response in the DB as pair (phone,request_id).
And now, when the user enters a 4 digit code and sends it back,
I need to call:
https://api.nexmo.com/verify/check/json
providing it with request_id and code.
But where do I get the request_id?
Do the server needs to send it back to the client, the moment it gets it from Nexmo?
I can't see the benefits of using Nexmo here, what will it save me?
Answer to your first question: the request_id is part of the response to the first verify API call. See: https://docs.nexmo.com/index.php/verify/verify
As to what are the benefits of Nexmo here, I believe you have two options:
Generate your own code, use Nexmo to text it to your user, have the user submit the code back to your application, verify code against your own database.
Use Nexmo verify service to generate and send the code to the user, store the returned request_id in your db, have user submit code to your application, call Nexmo verify API to validate code.
In some ways the first option is easier as it is less API calls. However the benefit of the second option, using Nexmo Verify, is that they provide a whole lot more capabilities into the service to fall back to a voice call if SMS isn't working, filter out virtual phone numbers to prevent spam, you don't have to pay for failed SMS attempts, reporting/analytics, etc. etc.
Hopefully that helps a little.
I am working on an iPhone app and I want to implement the new model of auto-renewal for in-app purchases. I am able to successfully implement transactions and can even get subscribed to the app, but what if the user cancels the auto renewal subscription?
How will I be able to know that it has been cancelled, and so not continue to allow access (once expired)?
You can find the expiration date of a user's subscription by sending a receipt verification to Apple's servers. Check out figure 1-3 on the In-App Purchase Programming Guide.
Basically the steps are:
On the device, get a transaction receipt for an in-app-purchase. Either one you've saved during a transaction or by calling [SKPaymentQueue restoreCompletedTransactions].
Send that receipt to your server. (This is preferred over trying to do a receipt verification with Apple's servers directly from the app, since that would require you to store your shared secret on the device.)
Send the receipt to Apple's servers from your server, and in the response look for a key named expires_date (expressed in milli seconds since Jan 1, 1970 GMT).
I used this guide to help me on the server side: Verifying Apple App Store Receipts For In App Purchases With PHP and cURL.
There is no way to determine if the user has auto-renewal turned on or off. Apple doesn't give you access to this information. The only way is to wait until the expiration date passes without a renewal.
if the receipt status is 21006 and there is a key named cancellation_date, then it's a cancellation, you can find the new expiration date in that key but it's a formatted date, if you need a better value to parse check for receipt['latest_expired_receipt_info']['cancellation_date_ms'] same as expires_date
I'd like to develop a tracking system using an API of course (like the famous Orange API).
the idea is simple:
I send a SMS (from my Web interface) to the person i want to track
The person's mobile terminal (GPS like this) send me back automatically
the coordinates by SMS.
The sent information are displayed on the user's web interface.
The questions are simple:
How the terminal can send automatically the response?
How to indicate in the message that the information is for "user4655"?
How to make connection between the information and the database?
Thanks,
Regards.
* How the terminal can send automatically the response?
Ans: You set the gateway and the time intervals you want the device to send the sms to on the device itself.
* How to indicate in the message that the information is for "user4655"?
Ans: The gateway you use will have the API to determine that the number it is sent from. The device will use a registered phone number from either a sim or enabled by one of those cell providers.
* How to make connection between the information and the database?
Ans: I dont understand this. But I'm guessing you will have a database to keep track of the user data. You'll just probably need another table that is a child of the user, which has a list of the data and the time they came in.
I am developing an application in which I want to use push notification service. I have a server, now I want to know that
How do I handle multiple devices?
Is there a unique device id/name for every iphone?
Suppose I want to delete request for a specific device token, so how do I handle multiple users?
Is there a way I can generate unique name for every device through application?
You should really read the APNS documentation, this is all explained in depth there.
The short answer is that when you launch an app on the phone it requests a push notification key from the OS. You then take that key and send it back to your server. Your server uses that key when it sends a push via Apple's servers to indicate the devices to send the push out to.
The service just gives you a token. If you want accounts or device names you need to come up with them and store them with the credentials on your server.
You handle multiple users by same way you handle single users, you send message with the appropriate key to the service.
As for deleting a request, you can't. It is like a text message, there may be some latency before hits the device, but the moment you commit the push it could be delivered instantly.