Just recently a script that has been running flawlessly has begun to return a 410 response to the HTML get call to both the http://www.zillow.com/webservice/GetSearchResults.htm and the http://www.zillow.com/webservice/GetDeepSearchResults.htm
Pasting the url that the script is fetching into the browser gives the same 410 error, as though they have removed it entirely.
I see references to their new Bridge API, but no notifications that their old API was being discontinued that I can find. Any insight?
Zillow has shut down all of their data APIs as of the end of February. As was stated in another answer, it appears as though they shut it down as a result of abuse, but did so with no mention of it at all (as a matter of fact, the documentation and sign up remain active to this day, nearly 3 weeks after the API began throwing 410 response codes).
In 2016 Zillow purchased Bridge Interactive, which is a company that specializes in Broker and MLS back-office solutions and data management. see press release here
Bridge Interactive now has the Zestimates API (see documentation here) along with a new API that appears to offer API access to public data too (Public Data API docs)
I had applied for access to the Bridge API in February using their web form on the Bridge Interactive Website shortly after the demise of the Zillow APIs and after about 2 weeks and a bit of back-and forth via email I just got my invite to access the Bridge API.
It does appear to have the same restrictions as the Zillow API just on their new platform. Sign-up is a manual process so it takes some time but, knock on wood, I might be back up and running in a short period of time after integrating with the new API (which, of course, is completely different than the Zillow APIs).
Update 2021-03-28
It appears as though on or about March 26th, their API began to respond again -- I have tested the getSearchResults and the Zestimate API and both are responding as they previously had.
According to this tweet from Zillow in response to a customer question, it looks like their API has been turned off due to customer misuse.
https://twitter.com/zillow/status/1365418247949058048
Related
I've recently seen this message:
This product is deprecated and will no longer be supported on May 31st, 2018. If you are starting a new project you should use deep links to m.uber.com. See the migration guide on how to link to the latest Uber rider experience.
Here's a screenshot of this message
Keeping in mind that this widget offers these functionalities(as does the REST API):
Selecting a service (e.g., uberX, UberBlack, etc.)
Specifying pickup and dropoff locations
Viewing time and price estimates
Requesting a ride
Will the Rest API be somehow affected by this change?
Will I be able to further make requests like these ones?
GET /v1.2/estimates/price
GET /v1.2/history
GET /v1.2/places/{place_id}
I'm not an Uber representative, and I really kind of feel that asking support from a vendor is the way to go for a vendor specific thing. However, when I read that message and screenshot they are clearly talking about a widget, not a REST api.
I'm still trying to wrap my head around all this, so my apologies if I've made a mistake, but it seems like the old NVP apps that are now unable to be registered as of December 1st had some features available that can't be replicated in the new REST world order...
Here's what I want/need: I need to be able to translate buyer-side transaction IDs into my seller-side transaction IDs, and I want to be able to do this on a webserver that is secure but I don't want it to have full access to my account, so I'd like fine-grained authz for this server.
It seems like I am a couple days too late to actually get what I want/need. Basically, GetTransactionDetails does exactly what I want (convert buyer to seller transaction IDs, and returns the rest of the transaction information for good measure). And, although I haven't gotten it working, it looks like the Permissions SDK plus an NVP AppID would allow me to have just the TRANSACTION_DETAILS permission on this service which is exactly what I want.
However, as of Friday apparently I can't get an AppID for the classic NVP API? If so, my timing is impeccable.
Trying to figure out how to do this in the REST API has proven difficult. This thread talks about the sale record, which does indeed take a buyer-side transaction ID, but it does not actually translate it into a seller-side one. It does have the custom field, which helps me a little, but I really need the seller-side transaction ID. It looks like maybe the parent_payment URL in the return from the sale might help, but the API started returning PERMISSION_DENIED on me even on previously successful queries so I can't exactly test this right now. And, even if that did work, it seems like the permissions on the REST API are incredibly coarse compared to the Permissions SDK, for example the sale endpoint is under /v1/payments which seems to also include refunds and all kinds of other stuff I don't want exposed. It looks like there's a Transaction Search permission but it's marked beta and it didn't work for querying a sale for me. But maybe it means they're working on it?
What are my options here?
Thanks,
Chris
Okay, so I played around with this for a while, and it seems like the PayPal REST API is just not very good. So, I worked around the limitations here using AWS Lambda and its fine-grained IAM permissions. I created a Lambda function that took my PayPal NVP credentials as encrypted env vars, and an IAM account that could only call my Lambda function, and so now I've got a microservice that will translate transaction IDs and return some extra info (custom and email) from the transaction to boot.
I wish I didn't have to use AWS to work around PayPal's limitations (which seem to be getting worse with the REST API, the NVP api would have been fine if I could have gotten and AppID and used the Permissions SDK), but oh well.
Chris
Today I have been trying to implement the rest API into my application to look up transaction information from a transaction ID (GET /v1/payments/sale/)
I have implemented everything correctly on my end and set the mode to "live" and I can't seem to get details from a transaction.
Here is the full error code:
{"name":"REQUIRED_SCOPE_MISSING","message":"Access token does not have required scope","information_link":"https://developer.paypal.com/webapps/developer/docs/api/#REQUIRED_SCOPE_MISSING"}
And here is documentation on what I am trying to do: https://developer.paypal.com/docs/api/#look-up-a-sale
Any help would be appreciated.
Thanks.
There are few things you could do to make sure your configurations are set right.
If the mode is set to live, are you using the live credentials instead of sandbox. You can select the sandbox app and copy the live credentials from there. See bottom part of this image.
Make sure Payments are enabled on live. PayPal has a dashboard page, where you could see all the services that you have enabled to work with Live environment. This prevents accidents on unknowingly using an API on live. You can check the status here
Is the sale that you are looking for created by the same clientId that you are using for making a GET call ? Only the app who creates the sale, can view the sale.
In the mean time, PayPal has created SDKs for many languages to support REST APIs. They are actively developed, and maintained, and could help you mitigate issues in handling tokens, credentials, etc, and allows you to quickly use APIs faster and in a way that could be upgraded easily. Also, few SDKs come packaged with Sample codes, and wiki documentations. Few are still under development, but you can feel free to contribute back to these open source SDKs.
When I had this issue, the problem was that I was making REST requests using the Identity API token. Basically, I was logging users into my website with Paypal then using that token for REST requests when another token from the REST API service should have been used. "
Here is the support ticket from Paypal SDK deveoper Randy who helped answer my question even though I do not use the SDK. Thanks Randy:
https://github.com/paypal/PayPal-PHP-SDK/issues/785#issuecomment-282749095
I have tried raising this concern on Facebook/Support/Bugs but they said I should post implementation issues here. I have read it everywhere and it seems to be quiet open issue till now. I am not sure, If this will be solved or not.
So, what we are doing is, we have clients - Android and iOS.
Apps on Android/iOS allows users to login into the app and generate the token on the basis of permissions set we have, and we are passing this token to server for fetching further data as and when required for client. As our userbase is increasing we are getting Application request limit reached quiet often.
We are fetching photos of users and their friends using FQL. So, when parallely fetching photos for around 8-10 different users, we are reaching the Application request limit sometimes, which is quiet random and we are not aware of the actual scenario when it breaks up and how. According to facebook the limit, which is 1M calls per day, but we are hitting around 80K - 1 Lac API calls in a day, but as users are increasing it is stretching a bit further, Less than or equal to 200 approax calls/user. We tried doing batch calls as well and we hit the application request limit as well.
If anyone of you could help us understand the complete concept of API limit and how this can be handled, then we will really appreciate the help. We want to understand how API limit is decided and it's rate is calculated over which interval so that we will be able to configure on our side accordingly.
Earlier in the day, we ran into a unique API call issue. Our server started to break for API calls for user tokens that are with us, we (on our systems, other than server) tried fetching the data for those tokens (Simple calls - /me or /me/home), and it was working alright for us but not for server, then we tried setting up another server and redirected the requests to our new server then this server works well for the same set of users. Not sure, what went wrong in this case and how it breaks up. Please help.
Many Thanks,
Reno Jones
Did you look at the Insights -> Developer section of developer.facebook.com for your app?
This will show you a breakdown per api call, including warnings and ones that are currently being throttled and why.
Also, are you sure you're using User token authorization and not just your App token?
Beyond that, we take the information from Insights to find api calls to cache on our side rather than hitting Facebook every time. You will likely have to do something similar if you're not already. They have limits for calling too often, as well as for requesting too much data. For those, we had to reduce the limits of historical data we requested.
Is there a way to get the meta-data of statuses created through the new status update form that is being roll-out to every one since last week (the one where you can attach a location and a place to your post) ?
Right now the only info that gets through the APIs is the status message... which often does not make sense without the shared location :(
There isn't currently a way to access this metadata (location info attached to a post added via the www.facebook.com interface) but where a user checks in from the mobile site or iphone app, this is treated the way it always was on the /checkins connection.
I'm not sure if there are plans to add this metadata to the API, but if it's added it'll either be announced on the roadmap at https://developers.facebook.com/roadmap/ or on the blog at https://developers.facebook.com/blog/
I wonder, I wonder.
It could be that FB is rethinking their API strategy considering location data and privacy issues it might cause. Something that Google and others are facing currently. Otherwise it should be very easy addition to their existing API's.