So I know I need to send back the playground ID as a header. I just don’t know how to do it in this workflow step. Any ideas? I am not sure if I need to be doing this in the API Connector somehow or by adding something in the URL.
Even though that URL might be a GET, it won’t return a web page. It’s an API endpoint. It will return some sort of data (as would be documented in the docs for that API).
I got curious so I went and looked at the playground page. What that aggregator call is all about is the Oauth Authentication (which I demonstrate how to do below). Note that I do not believe that in the playground version of this stuff that the authentication call actually executes a redirect.
That is, it does not respond with a 302, but always just with text “OK”. It’s basically a simulation of a real user going to a login page and giving their credentials. You’d have to get accepted as a partner to get access to the “real” API.
But, if this were a functioning Oauth endpoint, it would be set up in Bubble like this:
And, as it notes at the bottom there, to authorize this API, you need to successfully authenticate to it once. You do this by executing a login workflow:
(The name of this action before you select the provider is “Log the user in with a social network” or some such.)
But, like I say, if you do this, nothing happens in this case, you just get a blue bar of death, cuz I don’t think this demo endpoint actually provides a redirect, it just returns the text “OK”. (I may be wrong on this, but I do not think this is a functional demo. It’s not like a real dev sandbox environment. You can only get access to the real endpoints via being accepted.)
Edit: I suppose my test might have hung because I didn’t bother to fill in the access token endpoint. It might work for you. But I already deleted my sample API calls and can’t easily go back to futz with it.
Yeah @keith, that makes sense. I will go through the process.
At the moment, I was thinking of doing the same thing. However, when done this way, it makes the user login through Chase which then makes them a new user in the database. I would want to prevent a new user being created but instead just save the values to the user’s database. That’s why I can’t use the OAuth2 User-Agent Flow. I set up the same for Quickbooks like this at first, but then it was the same issue. Signing up as a new User, not updating the current user’s data.
Does that make sense?
I sent an email to support, I hope they will provide a way to do what is needed using the API Connector or maybe add a way to send headers in that workflow step. Who knows.
Thanks for your time, I might play around with how you have it set up so I can get approved through Chase while I wait for Bubble to make it work the way I need it to.
At the moment, I was thinking of doing the same thing. However, when done this way, it makes the user login through Chase which then makes them a new user in the database.
This is not entirely correct. If the User is logged into your app via some other means and then you run this login workflow on them, that login method is added to the user as a way that they can log in. However, this is only true for Oauth providers that offer “log in with…” type functionality and will have a “profile” type endpoint (which it sort of looks like Chase has) that lets you get at their email (which basically serves as a unique identifier).
But the idea here is not to allow the user to “log in with Chase”. What you’re doing is authorizing and then you’ll get a user access token and a refresh token that allow you to call the endpoints in the Account and Customer Information API on that User’s behalf.
Anyway, even if it does result in your user gaining the technical ability to login to your app via their Chase credentials, you don’t have to expose that option.
Also: I kind of get the feeling that Bubble’s User-Agent Flow might not work for this particular API at all, but it’s worth a shot, I guess. Working with stuff like this is painfully fiddly in Bubble, unfortunately (as I was groaning earlier).
I should add: When an API is structured in such a way that the Bubble API connector’s User Agent Flow auth works with it, it works great and saves you from having to worry about key management and such. But I’ve implemented other APIs that used Oauth but did not have a user profile endpoint and you have to do all the Oauth redirect hokey-pokey yourself and also the key management and it results in PTSD.
That’s good to know. When I tested it before, maybe I did something wrong or maybe the api didn’t support it. Maybe I will try it again.
Yeah, I like that Bubble handles all the refresh token stuff for us when we do it that way. Makes it a lot simpler. I ended up having to do all that myself and, like you said, it was quiet a bit if work.
I guess I meant ‘log into Chase’. Not ‘log in with chase’. If that makes sense.
I used to do all of this with Plaid, but now Plaid has changed things and I need to go through their poor customer service to get it working again. Or connect to Chase directly and bi-pass Plaid all together.
Yeah.
Or connect to Chase directly and bi-pass Plaid all together.
The only way to connect that I can find is through Plaid.