I would like to know Freemium versions' SLA, because we have detected that the servers do not return any response and we way within the use free limit the following APIs: Places API, Geocoder API and Reverse Geocoder API.
In addition we are using the production server, as described in the following url: https://developer.here.com/documentation/places/dev_guide/common/request-cit-environment-rest.html, and we haven't exceeded 250k Freemium plan transactions.
Thank you in advance for your help.
The SLA for non-paying Freemium plan is unknown but often when service is healthy then SLA is almost the same for non-paying and paying plans.
Regarding with https://developer.here.com/faqs:
Our SLA is 99.9% monthly availability for these APIs in production:
Maps
Routing
Geocoding
Traffic
Positioning
Weather
Fleet Telematics
Search
Transit
HERE SDK (server components)
This SLA comes with all our paid plans. This includes the Freemium plan when paying for use over 250,000 Transactions per month, the Pro plan and some Enterprise plans.
We do not offer an SLA (Service Level Agreement) for Batch Geocoder, HERE Studio or Live Sense SDK Beta.
You can check the status of the HERE services on https://status.here.com/status
Please not forgot double check an internet connectivity of course on your side too.
Related
I'm working with Firebase and quite enjoying it so far.
I'm working with DEV, PREPROD and PROD environments for each of my projects. For each env I've had to create a distinct firebase project.
Since my app is using Algolia and Cloud vision API, I apparently have to be on the Blaze plan because Spark plan doesn't allow outbound requests and Cloud vision API calls (if I'm correct).
The thing is we're limited with the numbers of Blaze projects we can have at the same time. Above a certain amount (6 or 7, I think) we have to request a "billing quota increase" and explain why we need more (sounds odd but ok).
So I did, but now Firebase is asking for a $50 transaction to increase the number of Blaze projects I can have.
So I have several questions:
- Am I right to think that in Spark plan I can't call the Algolia API in my cloud functions or call Cloud vision API ?
- Are these $50 a payment to unlock new projects slots or just credits that will be available if needed ?
- If I need even more projects in the future will I have to pay even more credits ?
- How am I supposed to handle separate environments on Firebase without creating a different project each time ?
Thanks a lot
On the Spark plan, with Cloud Functions, you can only make outgoing connections to services that Google fully controls. Algolia will not work.
Please read the FAQ regarding the number of projects you may have and the payment being asked to create a new project:
Why am I being asked to make a payment for more projects?
You may be asked to make a payment if your request for more projects
indicates that you need projects that will use paid cloud services.
The payment can be applied to any charges you incur in the future and
will be visible as a credit in your account.
This payment is required to ensure paid services will be available for
the projects you requested in the quota increase request form. This is
a common requirement, because Google Cloud Platform services are paid
(e.g., Compute Engine, Cloud SQL, and BigQuery).
The payment required varies depending on your billing history, the use
cases described in your request form, the number of projects you
request, and other factors.
So, the $50 you are being asked to pay will apply as credit to your project billing.
You should definitely create new projects for each environment.
Wanting to validate my ARM template was deployed ok and to get an understanding of the telemetry options...
Under what circumstances do the following get logged to Log Analytics?
DataPlaneRequests
MongoRequests
QueryRuntimeStatistics
Metrics
From what I can tell arduously in the last few days connecting in different ways.
DataPlaneRequests are logged for:
SQL API calls
Table API calls even when the account was setup for SQL API
Graph API calls against an account setup for Graph API
Table API calls against an account setup for Table API
MongoRequests are logged for:
Mongo requests even when the account was setup for SQL API
However I haven't been able to see anything for QueryRuntimeStastics (even when turning on PopulateQueryMetrics) nor have I seen any AzureMetrics appear?
Thanks Alex for spending time and trying out different options of logging for Azure Cosmos DB.
There are primarily two types of monitoring paths for Azure Cosmos DB.
Metrics: These are low latency (<5 min) and aggregated metrics which are exposed on Azure Monitor API for consumption. THese metrics are primarily used for diagnosis of the app for any live site issues.
Logs: These are raw request logs coming at 2hours+ latency and are used for customer for primarily audit scenarios to understand who accessed the data.
Depending on your need you can choose either of the approaches.
DataPlaneRequests by default shows all the requests across all the API's and Mongo Requests only show Mongo specific calls. Please note Mongo requests would also be seen in Data Plane requests.
Metrics would not be see in Log Analytics due to a knowwn which our partner team is fixing.
Let me know if you have any further questions here.
I'm not sure about this, i think i can use it for a app that needs hipaa compliance, because the nginx container is running on GKE or GCE and this services are hipaa compliance. Or is it not compliant?
Product Manager here.
Endpoints is not yet on Google's official list of HIPAA compliant products (available here).
We not believe it is non-compliant, but it has not yet gone through the certification process (and we have a few products ahead of it in the queue). I'd love to bump it up in the queue; feel free to email me (ciruli at google dot com) and I will let the certification team know about the request. I can't promise a schedule or timeframe, but customer input certainly helps.
I was just wondering whether it is possible to set limit on number calls in Cognitive Services - this is in context with - keeping API keys in the app
There currently is not a way to set limits or caps for your quota at this time. If you are subscribed to a paid subscription through Azure you are able to monitor your monthly usage.
This information appears when you are viewing the resource item (your subscription) in Azure.
Recently I was developing an application using Linkedin people-search API. Documentation says that a developer registration has 1 lac API calls per day, but when I have registered this API, and ran a python script, after some 300 calls it says throttle limit exceeds.
Did anyone face such kind of issue using Linkedin API, comments are appreciated.
Thanks in advance.
It's been a while but the stats suggest people still look at this and I'm experimenting with the LinkedIn API and can provide some more detail.
The typical throttles are stated as both a max (e.g. 100K) and a per-user-token number (e.g. 500). Those numbers together mean you can get up to a maximum of 100,000 calls per day to the API but even as a developer a single user token means a maximum of 500 per day.
I ran into this, and after setting up a barebones app and getting some users I can confirm a daily throttle of several thousands of API calls. [Deleted discussion of what was probably, upon further consideration, an accidental back door in the LinkedIn API.]
As per the Throttle Limits published by LinkedIn:
LinkedIn API keys are throttled by default. The throttles are designed
to ensure maximum performance for all developers and to protect the
user experience of all users on LinkedIn.
There are three types of throttles applied to all API keys:
Application throttles: These throttles limit the number of each API call your application can make using its API key.
User throttles: These throttles limit the number of calls for any individual user of your application. User-level throttles serve
several purposes, but in general are implemented where there is a
significant potential impact to the user experience for LinkedIn
users.
Developer throttles: For people listed as developers on their API keys, they will see user throttles that are approximately four times
higher than the user throttles for most calls. This gives you extra
capacity to build and test your application. Be aware that the
developer throttles give you higher throttle limits as a developer of
your application. But your users will experience the User throttle
limits, which are lower. Take care to make sure that your application
functions correctly with the User throttle limits, not just for the
throttle limits for your usage as a developer.
Note: To view current API usage of your application and to ensure you haven't hit any throttle limits, visit
https://www.linkedin.com/developer/apps and click on "Usage & Limits".
The throttle limit for individual users of People Search is 100, with 400 being the limit for the person that is associated with the Application as the developer:
https://developer.linkedin.com/documents/throttle-limits
When you run into a limit, view the api usage for the application on the application page to see which throttle you are hitting.