Creating an app key (API Bundles)

[Alexanderdorow]

Hello, in our organization we are planning to use Wicked because it proves to be a great api manager application, but we come across the following problem:
I'm signed in 3 apis on wicked, each api has a different api key, me as a developer needs to add 3 api-keys to my project. If it were just an app key (like ApiGee or IBM Connect), it would be possible for the developer to keep only one api key for the entire application and subscribe to the APIs that interest to use.

Would there be any way of doing this or has implementation been considered?

Thanks and congratulations for the excellent open source solution.

[DonMartin76]

Hey there, and thank you.

This is indeed something which has been considered, and even implemented, albeit a little experimental; it's called API Bundles. It is not (yet) documented, as we're not 100% happy with how it works. If you want to take it for a spin, please go ahead and do so, and please give us feedback on how it works for you.

The feature is not (yet) surfaced in the kickstarter, but it's pretty easy to use (but has some caveats). Go into the apis.json file of your static configuration, and on the top level of each API to be bundled, add a new property called "bundle". It takes a string as a value, and each API with the same bundle string will then work with the same credentials:

{
  "apis": [
    {
      "id": "someapi",
      "name": "Some API",
      "desc": "Some API implementation",
      "auth": "key-auth",
      "bundle": "somebundle", // <-- THIS
      "tags": [],
      "plans": [
        "unlimited",
        "basic"
      ],
      "authMethods": [
        "default:google",
        "default:local"
      ],
      "settings": {}
    },
    // ...
  ]
}

Some installations use this in production, but currently only for oauth2 type APIs; in principle it should also work for key-auth based APIs, but there is nobody (I know of) doing this right now. We are of course happy to get feedback on this!

Important: All APIs being bundled must share the same plans. This is currently not checked, but probably things will be strange, wrong, weird, if they do not.

[Alexanderdorow]

HI @DonMartin76, the solution works and as you said it is not flawless. The plan that is considered is from the first API subscribed.

Unfortunately, we need to have different plans from the same bundle. We find out that plans are plungins linked to consumers on kong, and that's why this happens.

[DonMartin76]

Yes, this is why I wrote that the APIs need to share the plan for this to render a consistent experience for the "customer" of the API portal. The alternative, if you just need different rate limiting settings per API, you can also leave out the rate limiting from the plan, and pick the one from the API. But, then there is just a single plan, in the end.

A very ugly workaround is to define multiple versions of the APIs and bundle those, respectively, as API bundles and by that "emulate" the plan.