Yodlee get_accounts sometimes returns zero result / empty response - yodlee

Here is the scenario:
User logins to the bank successfully (via Fastlink)
Right after user logs in, I get user's provider_accounts (via /providerAccounts API)
Then when I call to get the accounts, (via /accounts) I sometimes get empty response (zero accounts found?)
When I try later (seconds or minutes after) I get some accounts information back.
Is this because Yodlee is still trying to gather account information when I'm making /accounts api call?

This is because the accounts are still being added/linked.
Using the requestId and providerAccountId provided by FastLink callback, you need to poll continuously to know the refresh status of the account linking process and once it's done, you can call the get accounts.
Read more about the refresh status in the "Add/Update Account Process Status" section.
Yodlee makes things easier now with webhooks. Read more here:
Using Webhooks with the Yodlee Core API
TL/DR: You need to wait for the add/link completion before retrieving the accounts.

Related

How can I recognize when user has added account in Yodlee Fast Link?

How can I recognize when user has added account in Yodlee Fast Link (for example an investment account) by going to the link.
What I want:
I am creating a link to "Fast Link";
User are following by this link;
He is adding a their account;
And in this point I wanna know that he has added something (for example by callback url). How?
Thanks!
Yes, this can be done. You can have a page hosted that can count the hits and use that page as callback URL in extra params for FastLink.
You can get more information on this at
https://developer.yodlee.com/Fastlink_2.0/FastLink_Integration_Guide_for_Web
The extra parameters that needs to be passed for achieving this is as below
callback=http://google.co.in where here google.co.in is your callback page
Regards,
Vijay
Yodlee have introduced a new event subscription service using webhooks. It is part of their YSL (Yodlee Service Language) product.
It can trigger events for following –
the MFA information is requested by the provider site to log in for
aggregating data
the Yodlee system has performed the login on the provider site
successfully
the Yodlee system has retrieved the account summary information from
the provider site successfully
the final status of account addition or update account APIs
Details -
https://developer.yodlee.com/apidocs/index.php#!/cobrand/eventSubscription
Please NOTE that Webhook event notifications will work only when you try to add the account using YSL APIs (manually).It doesn't work with FastLink. I have been informed by Yodlee Support. They also informed me that till date they don't have any client using webhook service, which was bit scary to know.

Yammer API - rest api rate limits

Apologies if this question has already been asked.
I have followed this guide to create a script that will bulk delete members from a specified Yammer group and I have this working perfectly.
The process used at the minute is obtaining a token for a user, then using that token to remove the user from the group, which takes two API calls.
My question is about "sleeping" to avoid tripping the rate limiter. On the documentation for the Yammer API rate limits (link) it states that "rate limits are per user per app".
In another stackoverflow question (link) it's mentioned that in this context, the user refers to the user token.
Since in my script, I'm only using a single API call per user token (to remove the user from the group), is it necessary implement a sleep to avoid tripping the limit?
I'm also wondering whether the API call to retrieve the token for a user may possibly trip the limiter since it's called using the admin token?
I've run a few tests removing 52 users from a group using a script without any "sleeps" and it completed successfully in around 27 seconds, just trying to understand why this didn't break the limiter.
Thanks in advance!
is it necessary implement a sleep to avoid tripping the limit?
Yes, the admin user (or token if you like) could trip the limit in this case. To be on the safe side, that is, to avoid your app from being (manually or automatically) blocked, you shouldn't make more than request per second to Yammer endpoints that are categorised under "Other Resources". That's the Official guideline.

Ebay API: Get All Transactions By Seller

I am trying to use the Ebay API to get completed transactions for a seller(s) that is using a different account from my developer account. I've looked into GetSellerTransactions and GetOrders. Unfortunately, I am not sure if it's possible to specify a User ID different from mine. Could you point me to working example of how to do this?
To get transactions for a user you should be first authorized by that user.
You will need a developer account for that.
This links will guide you
http://developer.ebay.com/DevZone/XML/docs/WebHelp/wwhelp/wwhimpl/common/html/wwhelp.htm?context=eBay_XML_API&file=GettingTokens-Getting_Tokens_for_Applications_with_Multiple_Users.html
http://developer.ebay.com/DevZone/XML/docs/WebHelp/wwhelp/wwhimpl/common/html/wwhelp.htm?context=eBay_XML_API&file=DevAndTestApplications-Testing_Applications.html
Once you get the user token for a user you need to send them along with your developer credentials to make the getOrders API call for that particular user.

Is the Twitter Search API affected by the recent Twitter API changes?

I've been building an app which allows the user to search through recent (i.e. 6-9 days worth) public tweets on Twitter using the Twitter Search API.
Currently, the site is entirely public - that is, users do not need to sign in to Twitter (or even be Twitter users at all) to use my app.
However, the upcoming changes to the Twitter API have left me confused, particularly the fact it would appear that every request to Twitter's API will need to be authenticated.
My limited understanding of how Twitter's API works is that I need to authenticate my app using OAUTH, which in turn means that, if I want to continue accessing the Twitter Search API, users will need to sign in to my site before they can use the functionality related to the Search API - hence, only Twitter users will be able to use that section of my app.
Am I understanding this correctly, or is the Twitter Search API exempt from the changes? If I authenticate my app, does this mean the rate at which users can search Twitter status updates through my app is increased (or any other advantages over having non-authenticated apps)? Note that I am currently implementing a caching feature to cache related searches.
Thanks!
The changes to the Twitter API would affect your application depending on how your application works. These are the changes that you should be aware of:
All requests used to be anonymous. Now, all requests must be authenticated via OAuth.
With the old rate limits, according to my tests, you where able to make about one request per second per IP address. Now you can make 180 requests per 15 minute block per authenticated user (1 request every 5 seconds on average).
Not related, but still worth mentioning, the data that the new API returns is more similar to the data that the Streaming API returns. It's much more complete.
So, according to these changes, if your application uses some kind of a bot which polls the Search API, stores the results into a database, and then your users search within these stored results; you will have to implement OAuth with your own access token, which you can get by creating an application at dev.twitter.com.
But, if your application connects to the Search API every time that your users interact with it, and you think that you will have to make more than one request every 5 seconds on average, then you will have to ask your users to authenticate in order to get their access tokens for your requests.

Is this processus to pay a user, reliable and safe?

I'm working on a project that require my application to pay the user to his paypal account when he asks it.
Here's how I did it so far:
The (logged) user goes to the Pay page that will list all his Payments (received or not)
He enters his Paypal email and his application (mine) password (for security)
The POST page get a list of all the Payments that have status="UNPAID" for that user and update the status to "WORKING" (to avoid the user to refresh the page before the whole process is done and resend the same amount of money)
We count the total amount to pay in that list (a simple for)
The amount is sent to Paypal via Paypal Adaptive Payment API (request: PAY)
The response is checked, if completed, the list status is set to "COMPLETED", if not, the list is reverted to "UNPAID" (the SQL update is made via a WHERE id IN(x, y, z) in case a second Payment request has been made during that time.
A message is then displayed to the user
But I need your help, I'm in front of one risky problem I'd like to avoid, and I would know how you would do:
If the user hit refresh on the process page, I don't want to send him twice (or more) the amount (The "WORKING" lock is here for that, but what happens if the user hit refresh before I set the lock ?)
Rare possible: what happens if the user hit f5 after the lock "WORKING" is made, but before the request to paypal, and a new payment is received. By following what I did, just one item (the new) would be get and set to WORKING, but all others previous payment would be losts
How would you do? What is the best way to make it to be 100% reliable?
Thanks for your help
Note:
The steps between 4 to 6 is made via a PlayFramework jobs, called with now() and awaiting() the result
you can:
prevent double post via JQuery
use the checkAuthenticity() method to validate the request
do a GET redirect after processing the POST (so they can't submit the same 2 times even by mistake)
do the payment processing asynchronous (see below)
For the payment, instead of calling the job, set the id's of payments in a queue (or table in the database) and a job that runs once per minute that processes that table if it has some data. When the user does the POST you redirect to a page that says that you are processing the payments and will notify if there is some issue. You can notify the user later via a UI warning using comet or via mail.
That way you don't link the request to the processing, and you won't have threading/racing issues, as well as being able to detect stale requests (payments already done) if you do a sequential processing.