Hi,
Trying to use Linkedin API for Batch GET of some entity.
Their Rest-li 2 API format requests an array input be sent in URL parameter in the format ids=List(id1,id2…)
When I use it in Postman it works well.
When I try to initialize via API Plugin as a new call, I get 400 Bad request from the API over the parameter having invalid value type.
I haven’t figured out where to see the raw request bubble sends, but I strongly suspect the issue is that Bubble API connector is escaping the ‘(’ and ‘)’ characters. It makes no difference if I put it straight in the URL or using for param value - either way I get the bad response. when I manually escape them in Postman I get the same error.
Any way to tell the plugin API call editor to NOT escape a character? Or any other way to bypass this issue?
I think this might be an issue with Bubble in general, I can’t get API’s to work either
Check status.bubble.io
Nope. It’s been like that last week as well when there were no issues with the APIs.
Easy fix: encode it
(=%28 and )=%29
In most case, it work
The issue is the opposite. Linkedin API does NOT accept the value when the () are encoded, yet bubble API connector encodes them no matter where I place it. According to URL encoding standard these characters do not require encoding and yes, Linkedin should have just decoded it anyway but they do not.
I am looking for a workaround to prevent Bubble from encoding these characters in the request.
Is it possible to do a POST request instead?
This is not related
I’ve already created too much overhead for my developers by manually authenticating to LI API because Bubble provides no access to the authentication token on their own LI plugin so it cannot be used for any user-actions. So every call via the API connector already requires to manually enter the authentication header in the call from the UI. Adding another layer would mean also losing the “shared headers” feature, and passing a ton more of manual parameters on every call which means every change would become a huge hustle as we use a lot of different LI API calls.
Unless I didn’t fully understand your suggestion.
According to doc, using v1 protocol could help solving this. Instead of doing a list(v2) like ids=(1,2,3), you do a list using the same key multiple time like ids=1&ids=2&ids=3
However… you may need to check if this is deprecated or an alternative way to do the request
What I understand is that both protocol are active actually and can be used
Thanks. To the best of my understand only the old APIs support both and the new APIs we’re using, (available under /rest rather than the old /v2 /v1 etc) require rest-li version 2. I don’t want to revert to deprecated APIs for this.
Yes. Actually I think it’s not deprecated… but this may come soon.
Didn’t read all documentation, but found it was an option.
Try to do a request to Bubble support and add the request to ideaboard too. We should have an option to url encode or not (or maybe have different encoding method)
btw, I fully acknowledge Linkedin are the culprit here as they should have decoded this and in general their API using parentheses in query parameter is a mess that will break people’s regex usage. But since having MS/LI change is a stretch I’m hoping there’s a workaround on Bubble side somehow to bypass this defensive escaping no matter where I place the value. (e.g. I’d expect if I put it directly in the URL they wouldn’t go and encode it, vs if I put it in parameter value box as assigned value).
Totally agree. However, bubble could have an option for different encoding url. I don’t think it’s a bit thing to add
@Jici Thank you so much for being my sounding board.
I’ve been breaking my head against this for a week. Somehow now the workaround appeared to me after you helped me clear my thoughts 
Restli-2 protocol has a more secure way for sending parameters in request body with “use post as get” header, which I forgot I already used when implementing o-auth2 steps to send the client secret.
Since it uses “raw” format for Bubble, it bypasses their encoding.
Thank you!!!
(adding screenshot for future generations and marking as solved)
Yes. This is why I asked id the API service accept post request too 
There’s not a lot of service that accept bypass header but Im happy to know that linkedin do it 
Missed that one! Thanks again