Hi @quickjeff
You can hardcode it in the headers of Webhook action steps: https://zapier.com/apps/webhook/integrations
You can put into Storage then retrieve: https://zapier.com/apps/storage/help
Really depends on how dynamic you want to make the Zaps and how many Zaps are using the API.
@Troy Tessalone This is great. Was thinking of doing the hardcode method since the token doesn't really change. Any cons to this method?
In regards to the storage, any solid benefits to doing this if the token doesn't change unless we need to change it?
Appreciate the support.
Really depends on how dynamic you want to make the Zaps and how many Zaps are using the API.
If you use Storage you’ll have to use a Step/Task in the Zap to retrieve the Bearer Token each time.
If you are hardcoding and using the API in many different Zap steps, then you’ll have to update each Zap step.
What is the “hardcore” method? I’m trying to build an app to support RemarkableCloud integration.
Hi @gabefair
In terms of hard coding a bearer token into a webhook step, this would simply be using a 'webhook by zapier' step to make any kind of request, and hard coding the token into the 'header'
For example using a bearer token, this would be the following 'Header' pairing of 'Authorization' and 'Bearer xxxxxxxx' with the generated token simply hard code into the header so it won't change for each API request.
If your API token is regenerated at any time, this would cause the request to fail, however entering an API in this manner is useful when you anticipate the token won't change in future.
Regards, Michael
Hi,
All of the suggested approaches work correctly, but neither are ideal from a security perspective.
In a shared Zaps context, everyone with access to that workflow can see it in plain sight. What alternatives do we have to this?
Hello, I-m trying to add “Authorization” (key) and “Bearer xxxx” (value) in the headers section of a “custom request in webhooks by zapier” action but it doesn’t seem to work. Do you have any suggestion?