Why?
Looks like Pinterest is expecting the POST request to get the token to look like this (Pinterest Developers) and not pass the client_id and client_secret in the request body
curl -X POST https://api.pinterest.com/v5/oauth/token
--header 'Authorization: Basic {base64 encoded string made of client_id:client_secret}'
--header 'Content-Type: application/x-www-form-urlencoded'
--data-urlencode 'grant_type=refresh_token'
--data-urlencode 'refresh_token={YOUR_REFRESH_TOKEN}'
--data-urlencode 'scope=boards:read'
Question:
What would be the right way to set this up? Is there a way to configure the OAuth2 flow for this?
I tried to do custom auth but wasn't sure how to retrieve the code that is sent to the callback after step 1.
Hi @spiritualsystems! This has been trickier to implement than I originally thought, given how close the built-in OAuth2 pattern is to meeting your needs.
I've spent some time trying to rebuild it using a custom pattern but, as you've noticed, there doesn't seem to be a great way to handle the redirect and expose the code to the second step. You could technically build out your own endpoint for handling the redirect but it would be a super hacky implementation and not very tenable.
I think the best path forward is to talk to our dev team about adding some flexibility to the built-in OAuth2 pattern. I'll start that conversation internally and provide an update here as soon as possible. Thanks for your patience!
My pleasure - it's been a fun exercise but I'm hoping we can build a more integrated solution before too long.
I spent some time putting together a proof of concept based on the workaround that we discussed yesterday, which I'll share below. Don't judge me - it's been a while since I did true app development outside of Retool! Here's a recording of it in action. Note that I'm using Google as an example because Pinterest denied my API request.
Right now the actual custom auth as defined in Retool simply redirects to the OAuth2 authorization page. Everything from there is handled by the lightweight server that I put together. It's currently just running on my local machine, so the redirect_uri is a localhost address. You can check out the server code here.
The end result is that the user's access_token gets stored in RetoolDB for later use. I initially wasn't sure how to best associate the token with a particular user, but Google returns an id_token if you ask for the appropriate scope - email, in this case - which sufficed. I would double check Pinterest's documentation to see if they support something similar. They might also allow you to extend the lifetime of the token so that you don't need to re-auth as often.
Last but not least, I put together a quick outline of what it might look like to "schedule" pins and actually post to Pinterest.
This is very much a quick-and-dirty implementation, but you can see that the workflow runs every day at 3pm. I grab all the pins that are scheduled for today from the database, along with necessary user information. Then I just loop through them and hit Pinterest's Create Pin endpoint.
There's obviously a ton you can do to improve this, especially when it comes to error handling. But hopefully it's proof of concept enough to give you a starting point!
Just discovered a feature in Retool Beta that is the exact solution here! @Darren
Toggling this on allowed me to connect Pinterest as a normal Retool OAuth 2 resource.
