API Usage Sample Clauses
The API Usage clause defines the terms and conditions under which parties may access and interact with an application programming interface (API). Typically, this clause outlines permitted and prohibited uses, such as restrictions on reverse engineering, data scraping, or exceeding rate limits, and may specify requirements for authentication or security. Its core function is to set clear boundaries for API interactions, protecting the provider’s intellectual property and ensuring the API is used in a manner consistent with the provider’s expectations and technical limitations.
POPULAR SAMPLE Copied 1 times
API Usage. If you interact with the CARTO Platform API, you must include an API key with each request to the API. In addition to any other limitations set forth in this Agreement, the Services are subject to the usage limits set forth at ▇▇▇▇▇://▇▇▇▇▇.▇▇▇/help/getting-started/limits/. If we notify you that you have exceeded your usage limits, you shall promptly pay any invoice for such excess usage.
API Usage. When Services provided by Above the Fold utilize APIs, the Company agrees to continually utilize most current versions of the APIs. Company understands that utilizing most current APIs is critical to the integrity of the partnerships and Services of Above the Fold.
API Usage. The Service Provider grants limited, revocable, non-exclusive and non-transferable license to Customer or its integration partner to develop solutions using the Service. Customer is responsible for - controlling access to the API (user access rights) - applying fair use practises and not abusing the API system (e.g. by overloading the system) - all actions performed by integration partner under Customers Account Service Provider may limit access to API or throttle number of requests handled by the API should it threaten stability and accessibility of the Service.
API Usage. You can use up to the “fair use” API request count allocated by user without being charged. For allocation amounts, see ▇▇▇▇▇://▇▇▇▇.▇▇▇▇▇▇▇▇▇▇▇.▇▇▇/articles/api-on-demand- charge/.
API Usage. B.2.1. Developer The API calls for creating a game, and for creating a game version, are available in ▇▇▇▇://▇- ▇▇▇.▇▇▇▇▇▇.▇▇/▇▇▇▇-▇▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇/#▇▇▇-▇▇▇▇▇-▇▇▇▇▇▇▇▇▇ and in ▇▇▇▇://▇- ▇▇▇.▇▇▇▇▇▇.▇▇/▇▇▇▇-▇▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇/#▇▇▇-▇▇▇▇▇-▇▇▇▇▇▇▇▇▇▇▇▇. Here there are two possibilities:
1. You can create only 1 game, and send all the traces to this game. The problem with this is that you have to make sure you tag every trace with an extension of, for example, which minigame has sent this trace. This way the Kibana dashboard will be hard to read unless you filter the traces.
2. On the other hand, you can register a game for each actual game, and for each minigame. This way every dashboard will be useful by itself, with no need to filter: • If you decide to do this, you have to provide tracking codes to each minigame (this is easy to automate). • Remember also you have to create an activity for each minigame and class.
B.2.2. Teacher After creating a game, log in as teacher, and create a class. • To create a class, you have to make a POST to ▇▇▇▇▇://▇▇▇▇▇▇▇▇▇.▇▇▇▇▇▇▇▇▇.▇▇/api/proxy/gleaner/classes/ with the class name as body: { “name”: “class name” } • To add and remove students from a class, use a PUT request to ▇▇▇▇▇://▇▇▇▇▇▇▇▇▇.▇▇▇▇▇▇▇▇▇.▇▇/api/proxy/gleaner/classes/:classid. More documentation can be found at ▇▇▇▇://▇-▇▇▇.▇▇▇▇▇▇.▇▇/rage-analytics- backend/#api-Classes-PutClasses. Then, when you have a class and a game, you create an activity. • To create an activity you have to make a POST request to ▇▇▇▇▇://▇▇▇▇▇▇▇▇▇.▇▇▇▇▇▇▇▇▇.▇▇/api/proxy/gleaner/activities/ with the following body:
API Usage