In this setup, [recordid] should be a dynamic value sourced from user input or a workflow. Despite following the standard procedures, the API call doesn’t seem to recognize the dynamic parameter correctly, leading to unexpected results.
Steps I’ve Taken:
API Connector Setup:
Configured the API endpoint with the parameter recordId.
Unchecked the “Private” option for recordId to allow dynamic input.
Workflow Configuration:
In the workflow, I set the recordId parameter using dynamic data from an input field.
Ensured the input data is correctly formatted as text.
Debugging Attempts:
Used Bubble’s debug mode to trace the workflow execution.
Checked browser developer tools to inspect the outgoing HTTP request.
Despite these efforts, the API call doesn’t function as expected when using dynamic parameters. However, when I hardcode the recordId value directly in the API Connector, the call works perfectly.
Request for Assistance:
Has anyone faced a similar issue with dynamic parameters in the API Connector? Are there additional settings or steps I might be overlooking to ensure the dynamic parameter is correctly recognized and passed in the API call?
Any insights or suggestions would be greatly appreciated.
Not sure if there is confusion on how this works, but you do need to initialize the call first in API connector with the dynamic [id] value filled in via the input in the API connector. Once that is done, you should have no issues with the way you expressed things are setup so long as the [id] is not private and your input value is passed in properly to the API call action.
As always, sharing screen shots can be helpful in getting assistance. I often overlook something obvious to others that my screen shots are the only way for them to spot for me.
for sure I will post some screenshots heres waht i’ve confirmed through testing
btw usually a .Net architect but a new project and having oh so much fun! lol
I did initiallize the call
it works in postman
I have trimmed the record id parameter being passed into and it is 4 characters, so the param is good
I have tried to url encode it and no luck
this is using the API Connector and MEthod CRM
I have hard coded the value
the biggest issue i’m running into is not being able to see the HTTP get call being made at the time of action, maybe missing a header or something?
I doubt it because other HTTP gets work
I’m not even getting raw text or an error back and so i can onky conclude that something must be aloof in the HTTP Get call
for sure I will post some screenshots heres waht i’ve confirmed through testing
btw usually a .Net architect but a new project and having oh so much fun! lol
I did initiallize the call
it works in postman
I have trimmed the record id parameter being passed into and it is 4 characters, so the param is good
I have tried to url encode it and no luck
this is using the API Connector and MEthod CRM
I have hard coded the value
the biggest issue i’m running into is not being able to see the HTTP get call being made at the time of action, maybe missing a header or something?
I doubt it because other HTTP gets work
I’m not even getting raw text or an error back and so i can onky conclude that something must be aloof in the HTTP Get call
@onecallonly
I have EXACTLY the same issue than you. Actually, when I take a look about my API logs, I see that it always sends the default value instead of the dynamic one.
Did you find how to solve it?
Thanks.
I see on the API server’s side that the number that is sent is not the one that is expected.
Some tests:
if I keep admin’s last_category_created value, it sends 1 (the default value). In the debugger when I pause on this workflow step, I see the right value should be taken
if I use ‘Arbitrary text:converted to number’ with admin’s last_category_created inside the arbitrary text => same, the right value is put on the debugger, but it still sends 1 to the API
if I use admin’s last_category_created + 5, the debugger says it will send the expected value (last_category_created + 5). In reality, it send 5!
I I use admin’s last_category_created:floor, the debugger says it will send the expected value. In reality, it sends 0