Thanks all for the responses! As for the feature request brought up by @J805, I’ve logged it internally for the Product team to further explore.
1 Like
If I’m imagining what everyone else is here, this would be a data type & structure mapping - exactly as you already do for responses from calls made via the API Connector… but based on the endpoint fields.
I.e your existing solution works really well for everything but endpoints.
1 Like
@grace.hong What about the period(.) limitation? please just remove the “string replace” from the JS on the UI. 
1 Like
Will give it a shot; will reply with outcome. Thx!
Hi @einieini, the reason why this would require some discussion is that including parameters with periods would stem from URL’s using dots, and it’d be difficult to differentiate whether the dots are being used for parameters or for extensions. Regardless, I have noted this down as a feature request for the Product team to explore.
5 Likes
Hi @einieini where you able to workaround the (.) limitation? I’m trying to subscribe to Strava webhook and the GET response keys also have (.) in their names.
@grace.hong this would be amazing if it could be added as a feature.
4 Likes
@grace.hong: First of all, great relief to have the ability to take GET calls! Thanks!
Your comment on periods is somewhat fair (somewhat because the consideration stems from a legacy and there is a pattern of people moving away from it). See @aestela 's comment.
Regardless, could we quickly get this to a place where periods are automatically parsed into underscores? This is the pattern that Meta seems to be expecting ( Note: PHP converts periods (.) to underscores (_) in parameter names.). This feels like a quick fix and would unblock many users (this is quite time-sensitive).
At the moment, completely blocked from using whatsapp webhooks thanks to this constraint (and that’s a BIG problem that more and more of your users are going to face now that whatsapp API has been opened to small developers).
3 Likes
@grace.hong - Filed a bug report for this. Got told this is a “new feature”. I respectfully but strongly disagree. This is definitely a “bug” and you should prioritize fixing this accordingly. The bubble API connector is already parsing the parameters of the incoming webhook or API request. Getting this to turn periods into underscores is simply trivial - 2 mins to code, 10 mins to test, 5 mins to deploy. I sincerely hope you’re not looking at this as something that goes into a quarterly roadmap. This is far too time-sensitive a request for that. Thanks for your support!
2 Likes
@aestela Had to set up a Node script on my server to handle the requests to then initiate a new request with UNDERSCORE sent to Bubble’s servers. Far from ideal. There is precedent for (.) uses in other requests within Bubble’s REST tools, so I really don’t understand the dev’s choice in this regard. 
2 Likes
@grace.hong and @emmanuel - What I find not-a-little-triggering is what seems to be ideological resistance to doing something simple that is also established practice (PHP already does this). Do you see that this is resulting in your users having to do something really complicated and time-consuming (besides risky for noobs like me) like what @einieini is describing? I can’t stress enough that this is not a “new feature request”. This is definitely a bug in API Connector. Could you please prioritize this accordingly and get us unblocked today?
Hi there - definitely appreciate everyone chiming in on this feature and providing more context on the problems they’re facing. We are aiming to prioritize adding this capability sometime in our next sprint. Just to explain a bit further, we can’t immediately act on every new feature request due to different competing priorities and the time required for thorough testing.
Nonetheless, we always appreciate when users share why implementing a particular feature may be important for their use case, so thank you for advocating for this addition!
1 Like
Thank you for the response. When could we know whether this is being included in your next sprint?
Assuming you have a 2-week sprint schedule and that we are in the middle of your current sprint, am I right in thinking you’re targeting 8 Jul?
For more context as you may not be aware of this - Whatsapp API takes over the support number and we have no way of seeing incoming messages without using webhooks. So, effectively, without this feature, we are flying blind to incoming messages to our support number. Hence the alarm bells. Would be good to know whether we need to figure out a 3-week solution or a 5-week solution or something longer.
Thanks for pushing this, @grace.hong ! I know it must come across as me being unreasonable but I’m a PM myself and get how hard it is to get stuff prioritized. Your effort is appreciated!
Of course, we currently have this ticket tagged onto our current sprint which ends at the end of June, but it’s also dependent on other priorities that may appear and take precedence over this feature. Nonetheless, I will definitely send out an update on this forum thread once it is launched!
1 Like
any update?
Hi all - just released an experimental feature allowing you to enter periods in your API workflow keys!
3 Likes
@grace.hong Is it possible to add the ability for backend APIs to return a hook secret (ex X-Hook-Secret) in the response header?
Use case, Asana Webhook creation
Concept:
1 Like
Hi @salama - Thanks for the suggestion, I’ve added this as a feature request we can consider for our future roadmap! I’d also recommend that you add this idea to the Ideaboard for more visibility.
2 Likes
Hi,
I am trying to find the Trigger Workflow with option to switch a new API workflow I created to GET but I don’t seem to have it. I only see what you have shared as the legacy screenshot. Am i missing something here?
Hi @nishantsingh2291 - this is currently an experimental feature. You can find it in your Settings > Versions tab. Learn more here!
Hi all, this feature was just released from the experimental features panel and is now active in all of your apps!
3 Likes