as an integrator you typically start to connect to the Developer APIs with a specific setting. Every once in a while parties oversee some details in this and that lack could cause more trouble than necessary. Especially if the issues occur in production.
- Rate Limits (generics) : To protect the services from overload we defined so-called rate limits. Short term limited number of transactions per token.
With a small starting project you might not run into this. But be prepared for a growing number of transactions with every client you add to your undelying token.
As the rate limits apply per token this should be considered from scratch. Otherwise all users with a highly frequented token will experience GENERAL_RATE_LIMIT_EXCEEDED errors. - Dynamic IPs: The services are hosted in Microsoft Azure and you should approach them via names, not via IP addresses. This is because the IPs are redispatched by Azure every once in a while. If you use IPs and Azure redispatches the domain names you will no longer reach the services (check Developer Support)
- Request limits (plan-wise) : We also defined request limits based on a token's underlying plan. This means that some tokens can compute more complex transactions than others: With a developer kit plan power you can compute big optimization scenarios. But if you user then has a productive "basic" license he might face errors where your own integrator experience was "successful".
- TOKENs : In very rare but also very important cases we may have to evaluate to disable a token (e.g. a specific token violates the agreed handling of a service). In a partner business this means: if you use the same token for all your customers and we don't know which one causes the trouble we may have to consider to block your complete customer base to protect other users. Neither you nor we want that. Therefore prepare a proper strategy!
Bernd
PS: Nice to know but not ultra hard:
- Choose the proper method: Position Matching and Reverse Geocoding seem to be quite equal. Bu they are not.
- Nobody's perfect: sometimes the map data does not reflect the users desired reality due to missing data or special conditions that apply. In many cases you can benefit from the Custom Road Attributes mechanism to close the gap.
- You don't need to create client classes by yourself - we offer client classes via GIT Hub for JavaScript, .NET and Java
- Evaluate the additional data such ast TruckAttributes, historical SpeedPatterns, RestrictionZones via our vector map showcase
