The functionality to generate an email verification similar to password reset does not exist as a "off the shelf" feature. You will need to implement it yourself. However, it's not as difficult as you might think. Of course, it does take a little work, so I will go over the main/highlevel points. Please note, you are unclear on exactly the outcome of this process, you state "request database element". I will assume that simply means getting some data, however many of the below points still apply regardless.
1) User triggers the feature that sends an email to anyone. Most likely this is (or should be) in a Kinvey endpoint. Therefore you call the endpoint with relevant data necessary to generate the email.
2) The endpoint generates a token. The exact method/algorithm for generating the token needs to be implemented yourself. You can find many methods of doing this online.
3) You save the token against a data collection. You also save a timestamp here, or make use of the generated timestamps.
4) You trigger an email (using the Kinvey BL module for emailing) with a URL to the user. This URL has the token added to it.
5) Email is received by the user, and user clicks the link. They are now brought to a page that you need to create, and on that page, your code grabs the token.
6) You must now perform a request to Kinvey to validate the token. Additional validation can be performed based on your specific use case, but the most simple case requires hitting a Kinvey BL endpoint. Of course, you need to generate a temporary/generic user to authenticate against Kinvey. So in this step, signup and register a "auto-generated" user.
7) Call the Kinvey endpoint, using your temporary user, and pass it the token. In the Kinvey endpoint, perform a lookup against your token collection (from step #3) - along with any other custom verification. If the token exists, grab your necessary data and return it to the user.
Important: At this point, any self-registered, temporary user could perform all the above steps and access whatever they want. The key is to set your token and protected data collections with private permissions. That way, in Step #7, the user won't be able to verify the token or access the collection. However, in Step #7, you should perform the lookup as a master user - using your master secret - to verify the token. If successful, you grab the data and return it to the user.
In the end (and in a nutshell) - this means that any user can generate a token, that token being associated with other data (the collection/field/record, email address, etc). Then only someone that knows the token, can access only the data the token refers to. Since the data is private, only the master secret - operating on the backend, and therefore protected - can verify it and issue the response back to the user. I know this seems overwhelming at first, but it's actually rather straightforward if you break it down into logical steps.
