Incode API Keys API
Following endpoints facilitate API key rotation, for security reasons - current key gets stolen, user access needs to be revoked, organization expires, etc. It is good practice to rotate them every once in a while, regardless (e.g. every three months). **Migration** There used to be only one API key per organization, created and registered on API Gateway at the time of organization creation. Each organization has a user defined `name`, on which 3 random digits are added to generate `clientId`, on which sha1 was applied to generate `apiKey`. Field `clientId` was also used as organization identifier, while `apiKey` also served as organization reference. With the rotatable approach, API key management is delegated to a separate collection, which would contain `clientId` and `value` for each record. This also enables having multiple API keys per organization. Fields `clientId`/`apiKey` on organization entity will keep their identifier/reference function, to maintain referential integrity between entities. In order to facilitate the new approach and ensure backwards compatibility, a migration process is established. Through it, API key related fields are copied from Organization to RotatableApiKey collection, so that in the end each organization would have a corresponding rotatable key created. Key validity is checked on API Gateway directly (if applicable, otherwise set to `true`). All subsequent API key management would affect new collection only.