Currently, we have integration with Clio USA API. We want to support also Europe and Canada regions. To get data we add X-Bulk header with value true. It works fine for USA API but returns 403 for EU and CA APIs. Is X-Bulk header supported for Europe and Canada regions?
Without X-Bulk header we receive response from EU and CA API. So, token is correct.
Clio is in the process of deprecating the X-Bulk/Bulk request header.
Clio turned off this feature for any new App Keys/Secrets created after January 2022.
Bulk requests will be ultimately removed entirely at some time in the future
Clio is encouraging all developers to adjust the functionality to not use Bulk Requests.
Related
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
I'm testing uberpool in Sydney but uber API does not return any 'pool' products. The same query through uber app got 'pool' results.
It's important to mention that I can get pool results in other cities like San Francisco.
Is this behavior expected in Sydney or am I missing something?
We're working on a new web application using the Uber API and had a couple questions concerning the use of 'fare_id'
Is “fare_id” is a required parameter for POST /requests Api call? Can we pass empty value for fare_id and book a request?
What should be passed for “fare_id” in the ride request api for product that involves Surge Pricing?
Thanks
The Fare ID was introduced with the concept of Upfront Fares (as part of the announcement of v1.2 endpoints of the Uber API). Upfront fares replace the concept of surge pricing to follow a dynamic pricing concept. You have to pass such an ID if you use v1.2 endpoints. However, if you are still using v1.0 of the Uber API, the Fare ID is optional and mostly useful for UberPOOL.
To obtain a Fare ID, you have to follow the best practices of Upfront Pricing.
We successfully tested in the sandbox with setting fare_id to null in the cases described (using the java sdk).
As I remember, Google Directions API allows 2,500 directions requests
per 24 hour period from a single IP address per free user. Does anyone know the limits for Bing Maps and the Routes Rest API (http://msdn.microsoft.com/en-us/library/ff701705.aspx) for free users? I tried to look through the documentation but could not find such details.
Since, nobody has answered, I will answer my own question. You can get a free 90-day Trial Key allows you to evaluate Bing Maps for development of any type of application, including enterprise applications. The Trial Key may be used for up to 10,000 billable transactions within any 30-day span during the evaluation period.
http://www.microsoft.com/maps/create-a-bing-maps-key.asp
Any time a Routes API URL request is made to find a route, one transaction is counted.
http://msdn.microsoft.com/en-us/library/ff859477.aspx
That means, you can access the Routes API for a total of 10,000 times with a free Trial key.
I just wanted to know if I can use the REST API with an Italian account. I couldn't find any information about.
Thanks.
You can use REST api with an italian account, the link posted by KevinG does not state that you cannot.
I used it last year to implement Expresscheckout and it was working. Be sure to check if you need to be PCI or PCI-DSS compliant.
For more information you care read this faq https://developer.paypal.com/docs/faq/#non-US-dev
You can use REST API from Italy and you have a full access to all features in your sandbox account. In live account you have some limitations (no Direct credit cards processing!).
more info here (login in your developer account first): https://developer.paypal.com/developer/accountStatus
Currently the REST API is not available in Italy. This link will take you the the most current information regarding the REST API and supported countries:
https://developer.paypal.com/docs/integration/direct/rest_api_payment_country_currency_support/#direct-credit-card-payments