I am facing an interesting issue, where I have cloned a Workflow, to use a different trigger. Original was a Scheduled Trigger, clone is a Form Submitted trigger. Workflow is equal, there is no input to the workflow. The form is just there to have a manual way to trigger it. The Workflow essentially only consits with 2 WebService calls, with a wait inbetween. The only difference i see from test executions for both of them, is that the Secret ID is different, but thats expected. However, the cloned call returns a 400 code, even though everything is exactly the same, i have checked the executions with JSON diff.
Did anybody else run into that problem? Seems really weird to me.
Like if you look at the JSON of the steps executed, the ID of the secret is different, as they have been entered in both workflows. The authentication is not the issue, as we were missing the secret before and the authentication failed. That rules out the secret as an issue.
The 400 Bad Request error in the cloned workflow (Form Submitted trigger) is likely caused by an invalid or misconfigured OAuth client secret. The secret used in the cloned workflow is likely invalid, expired, or not authorized for the OAuth token endpoint.
Can you verify the secret used is valid and also test the request using POSTMAN or CURL and see if it is successful
Based on the WF that you have shared I see that in "HTTP Request 2 operation oAuthClientSecret is different. Wanted to check if you have generated a new access token from child workflow. Also instead of passing client secret from one step to another user the client secret directly in that step.
Based on my understanding, it seems you didn’t directly use the Clone option on the original workflow, but instead created a new one by modifying the existing workflow.
I wasn’t able to pinpoint the exact reason for the 400 error. If it were a 401, I’d be inclined to agree with the suggestions from @nithyamn13 and @udayputta — but now I’m wondering: does that API ever return a 400 in cases where authentication fails, or is it strictly a 401? If there’s even a small chance it returns 400, the issue might be related to authentication — perhaps due to the client secret, which, as we know, cannot be cloned.
Additionally, here are some differences I noticed between the two definitions:
Step
Key
JSON 1
JSON 2
Define Variable
actionId
"sp:define-variable"
Missing
Define Variable 1
actionId
"sp:define-variable"
Missing
Define Variable 1
baseUrl.description
"base Url"
"base Url for abacus API"
ScheduleReport
oAuthClientSecret
936b22cf...
f9672775...
HTTP Request 2
oAuthClientSecret
b3605330...
9fb37f24...
End Step — Success
actionId
"sp:operator-success"
Missing
Since the data is masked, I’m not fully certain whether both workflows are calling the exact same API. While we can ignore the clientSecret values, there’s still a possibility that some attributes may have been missed during the creation of the new workflow as you said you did it manually.
Ok, after some more testing I have found out that my colleague provided me with the wrong secret, as he assumed it was the same as for the second call. The error message from the API is strange, thats why I didn’t figure it out. So you guys were right, thanks for all the help
— but now I’m wondering: does that API ever return a 400 in cases where authentication fails, or is it strictly a 401? If there’s even a small chance it returns 400, the issue might be related to authentication — perhaps due to the client secret, which, as we know, cannot be cloned.