End to End Example
Last updated
Last updated
This will walk you through an entire end-to-end auto-completion flow for Pipedream. This will assume you need the whole stack of per-user authorizatioon and auto-completing claims. If you do not, you can remove some of these steps and adapt for your use case.
Note: This is not the only way to implement. It is just a guided tutorial.
With user authentication, you will need your users to go through the Pipedream Connect authorize flow somehow. Each user will be identified by an external_user_id
that you set, and once they authorize, you can specify to use that user's authorization details in the automation workflow. Their authorization details are stored under that user ID within your Connect app.
See docs here: https://pipedream.com/docs/connect. When creating a project, you can also get a step by step tutorial through the Connect tab.
We leave this step open ended up to you. For the sake of the tutorial, we are going to assume that the claim is to be auto-completed upon user authorization. We will also use the Pipedream SDK Connect Link feature to outsource the frontend code, but Pipedream also is flexible for more custom flows.
You will need to create a token (short-lived) which can be used to create a Connect Link (see https://pipedream.com/docs/connect/connect-link). Note the external_user_id
you use for this user. This is done server-side.
This is also open-ended. For this tutorial, we are going to use a proxy handler endpoint to generate the Connect Link to not need frontend code at all.
If you want to have a headless no frontend plugin, you can consider adding the Custom Instructions plugin in a claim with a link to a proxy handler endpoint. Because tokens are short-lived and generated dynamically, this should be a proxy one that generates the Connect URL and redirects users there (User -> Proxy Handler -> Generate Connect Link -> Redirect to Connect Link).
Let's say our proxy handler endpoint is hosted on https://my-proxy-handler.com/generate-connect-link
. You will redirect your users to this endpoint to initiate the Connect Link flow. Consider adding this in the claim description or custom instructions plugin or however you want to expose it to your users.
The proxy handler endpoint is as follows:
The final Pipedream Connect URL the user will be redirected to is:
Once the user has completed the authorization, you can now use that external_user_id
to perform authenticated requests. If you want to do this in a headless way, you can use the success callback URL to automatically do it upon completion.
For this tutorial, we will auto-complete a claim with their no-code workflow interface (https://pipedream.com/docs/connect/workflows). Follow along here for implementation details. Alternatively, you can directly execute code too without a workflow using their SDK or also fetch the user's authorization credentials and use them in your own code. We recommend the interface for ease of use and testing.
Below, we will explain at a high level and will skip over some lower level details.
Create a workflow in the Pipedream site with a HTTP POST webhook trigger.
Configure authorization for the webhook. This can be done in a couple ways.
Use Pipedream OAuth
Check for a secret hardcoded value (add a step after) to make sure you are the origin of the request
No authentication - if you do not add authentication, the only thing saving the endpoint from unwanted requests is the knowledge of the endpoint itself. It is important to not leak it if this is your approach
When adding your custom actions, select to use the end user's authentication. See the Pipedream docs for testing this. You will probably need to generate a test account and specify the external user ID in the headers.
Ex: For adding a Slack action with the user's authentication, add another step with Slack and select the little switch icon to use user authentication.
We recommend using the API request w/ code (NodeJS) feature. You customize your criteria checks here. You may setup custom parameters parsed from the trigger per claim or static hardcoded props. We leave this open-ended up to you. The only requirement is that if a user that does not meet the criteria, this step should throw an error / fail.
Lastly, set up the BitBadges action step as the final action in the workflow. We refer you to the workflow actions for the options here. Typically, you will auto-complete claims if you have the user's crypto address. If not, it may involve setting up and adding a dynamic store. Make sure to test or simulate before actually claiming for real. Also, ensure you are dynamically adding the user info from prior steps and not hardcoding it.
The workflow setup is now complete. The workflow will be triggered upon the HTTP request. It will then use the provided external_user_id
and execute the claim criteria checks from your configured apps and finally, it will complete a BitBadges claim or add to a dynamic store as the final action properly gating the claim.
You can then invoke the workflow per unique external_user_id
as shown here with the SDK. Or, you can also trigger via HTTP.