This document covers the current quotas and limits for HERE Workspace and Marketplace services and the resources available within them.
HERE places limits and quotas on HERE Services to protect the system from receiving more data than it can handle, and to ensure an equitable distribution of system resources.
HERE reserves the right to change these quotas, and this document will be updated to reflect any changes. You can request increases for some quotas, while other quotas cannot be changed. Some limits can be controlled by layer configuration.
Limits are fixed constraints which cannot be increased. Many resources and fields have count, size, duration, or length limitations, which are fixed constraints for the HERE Services implementation.
The following tables list commonly encountered limits. Service specific documentation and API reference documentation may contain additional constraints.
Setting Time-To-Live (TTL) for layers enables you to automate your data management practices, so that you can more easily maintain your data retention and cost.
|Minimum stream layer TTL||10 minutes|
|Maximum stream layer TTL||72 hours|
|Minimum volatile layer TTL||1 minute|
|Maximum volatile layer TTL||7 days|
|Minimum index layer TTL||7 days|
|Maximum partition size for index and versioned layers||50 GB|
|Maximum single object size for object store layers||500 GB|
|Maximum partition size for volatile layers||2 MB|
|Maximum partition size for stream layers||1 MB †|
|Maximum SDII message size send via Ingest API||20 MB|
|Maximum single log line size delivered to Splunk||900 KB|
† For more details, see Stream Layer Maximum Message Size Limit.
|Maximum members in a Group||500|
|Maximum Groups an entity can be a part of||50|
|Maximum number of permissions for Users, Apps, Groups||2000|
|Maximum number of Apps that a User can have access to||100|
|Maximum number of Users/Apps that a Project can have||500|
|Maximum number of Groups that a Project can have||100|
|Maximum number of Projects a Group can have direct access to||50|
|Maximum number of Projects a User/App can have direct access to||50|
|Maximum number of resources a Project can have||100|
|Maximum number of Apps that a Realm can have||5000|
|Maximum number of layers in a catalog||250|
|Minimum number of indexes of an index layer||1|
|Maximum number of indexes of an index layer||4|
|Minimum catalog identifier length||3 characters|
|Maximum catalog identifier length||63 characters|
|Maximum catalog name length||200 characters|
|Maximum catalog summary length||1000 characters|
|Maximum catalog description length||10000 characters|
|Maximum layer identifier length||50 characters|
|Minimum layer name length||120 characters|
|Maximum layer summary length||1000 characters|
|Maximum catalog description length||10000 characters|
|Minimum billing tag length||4 characters|
|Maximum billing tag length||16 characters|
|Maximum data handle length||1024 characters|
|Maximum key length in object store layer||450 characters|
|Maximum index layer index name length||64 characters|
When dealing with batch and streaming workloads, it is hard to anticipate a “traffic spike” of a sudden surge in demand, which typically more than doubles existing traffic levels in a very short period of time. To continue functioning and to meet the existing Service Level Agreement (SLA), any of the HERE Services can return HTTP 429/503 status codes for short periods of time (usually up to 10 minutes) and throttle requests from one or more users (even if the user's quotas were not reached), while it adapts to new request rates.
The HERE Account API used to request access tokens is protected with a fixed limit to protect service health. The limit per client appId is set to a default of 25,000 requests per 15 minutes.
Additionally, every request to HERE Services is verified against the HERE Account API for validation and the result of the decision check is cached. Only decision cache misses will hit the HERE Account and count towards the quota.
The maximum throughput for a stream layer is set up during layer creation. You can specify the maximum throughput of 32800 KBps (Kilobytes per second) for data written to the layer, and separately, the maximum throughput of 65500 KBps (Kilobytes per second)for data consumed from the layer.
The service starts throttling inbound messages when the inbound rate exceeds the inbound throughput. The service starts throttling outbound messages when the total outbound rate to all consumers exceeds the outbound throughput. When throttling occurs, the service response is delayed, but no messages are dropped.
Additionally, there is a per client appId quota for total stream layer throughput quotas. Quotas are byte-rate thresholds defined per client appId. A single client appId can span multiple producer and consumer instances, and the quota will apply for all of them as a single entity, such as if the client appId ”test-client” has a produce quota of 10200 KBps (Kilobytes per second), this is shared across all instances with that same ID. The default quota per Kafka topic partition is:
Catalogs in the HERE Marketplace have a maximum outbound throughput of 2000 KBps (Kilobytes per second).
The maximum message size for a stream layer is 1 MB. For messages larger than 1 MB, it is recommended you upload the data to the Blob API first and pass a message in stream by reference (data handle).
The maximum amount of data that can be concurrently stored in a stream layer can be calculated as follows:
(inbound throughput) x (retention time)
The N=number of subscriptions in a consumer group in a stream layer can be calculated as follows:
max (input throughput, ceil (output throughput /2))
Index API has a quota per client appId of 10 requests/sec for retrieval of the data and up to 100 requests/sec for publish requests.
Publish API has a quota per client appId of 5000 requests/min.
Usually if a quota is exceeded when making requests to a HERE Service API, the API returns a HTTP 429/503 status code and a message that the account has exceeded the quota. See the Terms of Service for more information.