We’re finishing up our integration with Hubspot and a major part of it is them sending a GET request to pull in customer details.
Here is the format of their request;
/api/1.1/obj/user?userId={{hubspot user id}}&userEmail={{user email}}&associatedObjectId={{hubspot user id}}&associatedObjectType=CONTACT&portalId={{private key}}&email={{user email}}
Would it be possible to sort to a user with these parameters?
We’d like to do that then return with data. Thanks!
I really think that you should use oAuth2. You are trying to access specific user information and this should be the way to go.
Can you send a screenshot of your setting for this request?
In bubble, to be able to dynamically fill parameters, you need to use [fieldname]
(portalId=[private key])
I think I started to understand your setting. This is using Bubble DataAPI
First, you need to use the constraint to filter
But I think that you cannot use the email. You need to create another email field and store the email to be able to search it in constraint.
The results of a GET request to your Bubble app’s API will only ever be what is supported (see the documentation).
If you have a situation where you have some external system that doesn’t support POST calls (where you have much more control over what you return [via a publicly-exposed Bubble API Workflow]), but only can send a GET, you have to do some really bogus shenanigans.
The closest thing I’ve found to a solution is to use something like Amazon API Gateway to transform the incoming GET request into a POST back to your Bubble app, which can then returns data in the format the external system is requesting.
This is why I’ve had the longstanding request here:
+1 on this solution. Bubble’s API features sort of ‘are what they are’ and, while there are sometimes workarounds, if you find that it doesn’t meet your needs and must have this portion of the API integration you’ll likely have to employ something like this.
Shot in the dark: would zapier or blockspring let you do this easily?
Hey, there ya go! (I guess I didn’t understand what @chriscardone needed to return. Though my meta comment above still stands – Workflow API calls that don’t require body contents should support a GET method. And it doesn’t seem like it would be all that difficult to add.)
It seems that @Jici understood the use case here and it looks like their answer is the correct one. (This is one of those times that the Bubble Data API is sufficient.) There’s just lots of times when it would be extremely useful to be able to build one’s own GET calls.
(Having that capability still wouldn’t fully solve the issue I talk about in the other thread I refer to as oEmbed support would also require control over returned status codes, but ya know, I’ll take what I can “get”. <-- See what I did there? )
)