Detta inlägg är gammalt och kan innehålla inaktuell information.

API keys usage best practice

I am doing an arduino-based project that displays the next departure times for a bus stop on a small led screen, refreshing the display every 30s. I am using one API key, with silver level (as it needs 30d*24h*60m*2=86400 requests). Now I want to add devices that will show departure times for other destinations. What is the recommended way of doing this? Do I need to create an API key for every device and request a silver level for it? Is there a way to request "DisplayTime" for several "siteid"s with one request?



  • Hi Slava,

    This is a bit up to You.

    If You feel that adding a new devices/destination is a separate project then is my recommendation to use a separate key.

    But, if You are using the same logic in the application, You might want to use the same key for all the projects.

    One thing to keep in mind, in case You need to upgrade the key to gold level is that You need to develop an applications that is intended to public use (is it?) and not for private display- to get the upgrade approved. One way to get around this - is of course a separate key on silver level for each device/destination.

    Best regards, Åke

    Team Trafiklab
  • Thanks Åke. It is one the same application on different devices, so it is desirable to have one key. How does a project qualify as public? Do I have to publish the code and assembly instructions?

  • Hi Slava!

    A public project is a project which in the end is used by the public, an example a Stationboard situated in a public place.

    When requesting a gold level key are You required to describe the use of Your application. SL which APIs You are using, will then decide if You will be upgraded to Gold level or not.

    You will be refused, if You are implementing an application on a device that is to be displayed at Your home.

    Best regards, Åke

    Team Trafiklab

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.