Workday Studio - request with HTTP out to vendor API receiving error with: No bean named 'http-token-auth' is...
I have a Workday studio integration to send a GET request to a vendor's API using an HTTP component, but I'm receiving the error below. The vendor doesn't have a username/password to connect. I have to connect using a token. Does anyone know how to make this work from Studio to GET data?
Reason: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'http-token-auth' is defined
I have sent the request in many different ways: hard coding the URL with the token, setting headers with the token. Below are my different attempts.
I’m not sure what Http authorization this is supposed to use. There is no username/password, just a token and a URL to post using CURL. Below is what studio looks like with the HTTP properties.
Below is what is set on the Header.
Also, I'm able to GET data using SoapUI. Below is a snip of the request in SoapUI.
Below is the JSON raw request in SoapUI that is successful in getting data from the API.
Any help is much appreciated!!
Thank you, -Remo
eclipse http workday
add a comment |
I have a Workday studio integration to send a GET request to a vendor's API using an HTTP component, but I'm receiving the error below. The vendor doesn't have a username/password to connect. I have to connect using a token. Does anyone know how to make this work from Studio to GET data?
Reason: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'http-token-auth' is defined
I have sent the request in many different ways: hard coding the URL with the token, setting headers with the token. Below are my different attempts.
I’m not sure what Http authorization this is supposed to use. There is no username/password, just a token and a URL to post using CURL. Below is what studio looks like with the HTTP properties.
Below is what is set on the Header.
Also, I'm able to GET data using SoapUI. Below is a snip of the request in SoapUI.
Below is the JSON raw request in SoapUI that is successful in getting data from the API.
Any help is much appreciated!!
Thank you, -Remo
eclipse http workday
This seems the error is coming from your vendor api. asked them to provide sample request payload with header set. They try the same in studio.
– Hikmat
Mar 26 '18 at 11:12
add a comment |
I have a Workday studio integration to send a GET request to a vendor's API using an HTTP component, but I'm receiving the error below. The vendor doesn't have a username/password to connect. I have to connect using a token. Does anyone know how to make this work from Studio to GET data?
Reason: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'http-token-auth' is defined
I have sent the request in many different ways: hard coding the URL with the token, setting headers with the token. Below are my different attempts.
I’m not sure what Http authorization this is supposed to use. There is no username/password, just a token and a URL to post using CURL. Below is what studio looks like with the HTTP properties.
Below is what is set on the Header.
Also, I'm able to GET data using SoapUI. Below is a snip of the request in SoapUI.
Below is the JSON raw request in SoapUI that is successful in getting data from the API.
Any help is much appreciated!!
Thank you, -Remo
eclipse http workday
I have a Workday studio integration to send a GET request to a vendor's API using an HTTP component, but I'm receiving the error below. The vendor doesn't have a username/password to connect. I have to connect using a token. Does anyone know how to make this work from Studio to GET data?
Reason: org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'http-token-auth' is defined
I have sent the request in many different ways: hard coding the URL with the token, setting headers with the token. Below are my different attempts.
I’m not sure what Http authorization this is supposed to use. There is no username/password, just a token and a URL to post using CURL. Below is what studio looks like with the HTTP properties.
Below is what is set on the Header.
Also, I'm able to GET data using SoapUI. Below is a snip of the request in SoapUI.
Below is the JSON raw request in SoapUI that is successful in getting data from the API.
Any help is much appreciated!!
Thank you, -Remo
eclipse http workday
eclipse http workday
edited Mar 14 '18 at 15:00
Remo Hernandez
asked Mar 14 '18 at 14:27
Remo HernandezRemo Hernandez
407
407
This seems the error is coming from your vendor api. asked them to provide sample request payload with header set. They try the same in studio.
– Hikmat
Mar 26 '18 at 11:12
add a comment |
This seems the error is coming from your vendor api. asked them to provide sample request payload with header set. They try the same in studio.
– Hikmat
Mar 26 '18 at 11:12
This seems the error is coming from your vendor api. asked them to provide sample request payload with header set. They try the same in studio.
– Hikmat
Mar 26 '18 at 11:12
This seems the error is coming from your vendor api. asked them to provide sample request payload with header set. They try the same in studio.
– Hikmat
Mar 26 '18 at 11:12
add a comment |
2 Answers
2
active
oldest
votes
To preface; I'm not familiar with Workday Studio, and there don't seem to be any public docs, so there may be some nuance here that this answer misses.
Summary
Workday, your code, or possibly some library being used is referencing a bean (see Spring docs: Core Technologies) that does not exist or can not be found.
If you're not writing any Java code whatsoever here, it's almost certainly either a configuration issue or bug in Workday Studio. Below are some observations based on the information you've provided. But first, a wild guess.
Wild Guess
It seems likely that Workday is handling this a little differently than cURL or SoapUI. cURL and SoapUI are doing something like the following:
- Send GET request to URL with params, and include API key in header
- Server sends desired response
However, it sounds like Workday is doing something more like:
- Send GET request assuming a pre-auth scenario, using challenge-type: 'token'
- Server responds with the correct auth-type that its framework (presumably Rails) uses for tokens; 'http-token-auth'
- Workday (wrongly) assumes that the server is using the Spring framework, and tries to load the correct auth-type bean based on that response
- Spring framework barfs because there's no such bean
I imagine there's some way to get Workday to play nicely with a standard REST API, and just supply the API key to the vendor's server as it expects, rather than trying to do a challenge/response.
If this isn't it, there are some more weedy possibilities below.
Odd Bean Name
The bean name specified in the error is http-token-auth
, which is in kebab-case. The convention for naming beans is (lower-) camelCase, so wherever that's specified may have just used the wrong casing.
This could be in the Workday Studio configuration, the XML config file, or some custom code you've written, if any.
Configuration
If the bean name is correct, then there's likely some other configuration issue. Spring can implicitly detect candidate components by scanning the classpath (see Spring docs: Classpath scanning and managed components) or loading it from the project XML. The issue could be:
- The build path is wrong (see this answer by esaj if you're unfamiliar)
- The classpath is wrong, so Spring just doesn't see it. This seems like a Workday-specific config in this case.
- The bean is in the project XML, but nested. In that case, it'd only be accessible to the enclosing bean. One solution to this is to activate the corresponding profile.
- A packaging issue; if the bean isn't being included in the resulting deployed jar, then there will be issues. This solution by dawrutowicz should apply in a number of cases.
- Project configuration; all the settings in your screenshots look exactly correct and should work fine, so there might be something hidden in your project settings
Bug in Workday Studio
This seems somewhat less likely, but is always a possibility. If you haven't written any Java code whatsoever, then there's something either in the Workday code that's serving up this unexpected 'http-token-auth' or inappropriately accepting it from somewhere else and trying to load up a bean using it.
Final Thoughts
Since you're trying to work with a vendor's API, I'd strongly recommend you try to collaborate with one of the engineers there. Guaranteed, they have at least one engineer who has dealt with complicated integration issues before. They'll have more details about their API, and might be able to give you more direct input on any configuration/code you'd be able to share.
Thanks Rob for the detailed explanation. Turns out it was a bug in Workday. -Remo
– Remo Hernandez
Apr 14 '18 at 12:13
add a comment |
I had an identical error message reported when sending a Rest POST request to a 3rd party web service from Workday Studio using Bearer authentication.
The resolution was to set the header output type to "message" instead of a "rootpart". It is not a bug in Workday Studio.
Workday Studio set header output type setting
Regards,
Shiraz
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f49280295%2fworkday-studio-request-with-http-out-to-vendor-api-receiving-error-with-no-be%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
To preface; I'm not familiar with Workday Studio, and there don't seem to be any public docs, so there may be some nuance here that this answer misses.
Summary
Workday, your code, or possibly some library being used is referencing a bean (see Spring docs: Core Technologies) that does not exist or can not be found.
If you're not writing any Java code whatsoever here, it's almost certainly either a configuration issue or bug in Workday Studio. Below are some observations based on the information you've provided. But first, a wild guess.
Wild Guess
It seems likely that Workday is handling this a little differently than cURL or SoapUI. cURL and SoapUI are doing something like the following:
- Send GET request to URL with params, and include API key in header
- Server sends desired response
However, it sounds like Workday is doing something more like:
- Send GET request assuming a pre-auth scenario, using challenge-type: 'token'
- Server responds with the correct auth-type that its framework (presumably Rails) uses for tokens; 'http-token-auth'
- Workday (wrongly) assumes that the server is using the Spring framework, and tries to load the correct auth-type bean based on that response
- Spring framework barfs because there's no such bean
I imagine there's some way to get Workday to play nicely with a standard REST API, and just supply the API key to the vendor's server as it expects, rather than trying to do a challenge/response.
If this isn't it, there are some more weedy possibilities below.
Odd Bean Name
The bean name specified in the error is http-token-auth
, which is in kebab-case. The convention for naming beans is (lower-) camelCase, so wherever that's specified may have just used the wrong casing.
This could be in the Workday Studio configuration, the XML config file, or some custom code you've written, if any.
Configuration
If the bean name is correct, then there's likely some other configuration issue. Spring can implicitly detect candidate components by scanning the classpath (see Spring docs: Classpath scanning and managed components) or loading it from the project XML. The issue could be:
- The build path is wrong (see this answer by esaj if you're unfamiliar)
- The classpath is wrong, so Spring just doesn't see it. This seems like a Workday-specific config in this case.
- The bean is in the project XML, but nested. In that case, it'd only be accessible to the enclosing bean. One solution to this is to activate the corresponding profile.
- A packaging issue; if the bean isn't being included in the resulting deployed jar, then there will be issues. This solution by dawrutowicz should apply in a number of cases.
- Project configuration; all the settings in your screenshots look exactly correct and should work fine, so there might be something hidden in your project settings
Bug in Workday Studio
This seems somewhat less likely, but is always a possibility. If you haven't written any Java code whatsoever, then there's something either in the Workday code that's serving up this unexpected 'http-token-auth' or inappropriately accepting it from somewhere else and trying to load up a bean using it.
Final Thoughts
Since you're trying to work with a vendor's API, I'd strongly recommend you try to collaborate with one of the engineers there. Guaranteed, they have at least one engineer who has dealt with complicated integration issues before. They'll have more details about their API, and might be able to give you more direct input on any configuration/code you'd be able to share.
Thanks Rob for the detailed explanation. Turns out it was a bug in Workday. -Remo
– Remo Hernandez
Apr 14 '18 at 12:13
add a comment |
To preface; I'm not familiar with Workday Studio, and there don't seem to be any public docs, so there may be some nuance here that this answer misses.
Summary
Workday, your code, or possibly some library being used is referencing a bean (see Spring docs: Core Technologies) that does not exist or can not be found.
If you're not writing any Java code whatsoever here, it's almost certainly either a configuration issue or bug in Workday Studio. Below are some observations based on the information you've provided. But first, a wild guess.
Wild Guess
It seems likely that Workday is handling this a little differently than cURL or SoapUI. cURL and SoapUI are doing something like the following:
- Send GET request to URL with params, and include API key in header
- Server sends desired response
However, it sounds like Workday is doing something more like:
- Send GET request assuming a pre-auth scenario, using challenge-type: 'token'
- Server responds with the correct auth-type that its framework (presumably Rails) uses for tokens; 'http-token-auth'
- Workday (wrongly) assumes that the server is using the Spring framework, and tries to load the correct auth-type bean based on that response
- Spring framework barfs because there's no such bean
I imagine there's some way to get Workday to play nicely with a standard REST API, and just supply the API key to the vendor's server as it expects, rather than trying to do a challenge/response.
If this isn't it, there are some more weedy possibilities below.
Odd Bean Name
The bean name specified in the error is http-token-auth
, which is in kebab-case. The convention for naming beans is (lower-) camelCase, so wherever that's specified may have just used the wrong casing.
This could be in the Workday Studio configuration, the XML config file, or some custom code you've written, if any.
Configuration
If the bean name is correct, then there's likely some other configuration issue. Spring can implicitly detect candidate components by scanning the classpath (see Spring docs: Classpath scanning and managed components) or loading it from the project XML. The issue could be:
- The build path is wrong (see this answer by esaj if you're unfamiliar)
- The classpath is wrong, so Spring just doesn't see it. This seems like a Workday-specific config in this case.
- The bean is in the project XML, but nested. In that case, it'd only be accessible to the enclosing bean. One solution to this is to activate the corresponding profile.
- A packaging issue; if the bean isn't being included in the resulting deployed jar, then there will be issues. This solution by dawrutowicz should apply in a number of cases.
- Project configuration; all the settings in your screenshots look exactly correct and should work fine, so there might be something hidden in your project settings
Bug in Workday Studio
This seems somewhat less likely, but is always a possibility. If you haven't written any Java code whatsoever, then there's something either in the Workday code that's serving up this unexpected 'http-token-auth' or inappropriately accepting it from somewhere else and trying to load up a bean using it.
Final Thoughts
Since you're trying to work with a vendor's API, I'd strongly recommend you try to collaborate with one of the engineers there. Guaranteed, they have at least one engineer who has dealt with complicated integration issues before. They'll have more details about their API, and might be able to give you more direct input on any configuration/code you'd be able to share.
Thanks Rob for the detailed explanation. Turns out it was a bug in Workday. -Remo
– Remo Hernandez
Apr 14 '18 at 12:13
add a comment |
To preface; I'm not familiar with Workday Studio, and there don't seem to be any public docs, so there may be some nuance here that this answer misses.
Summary
Workday, your code, or possibly some library being used is referencing a bean (see Spring docs: Core Technologies) that does not exist or can not be found.
If you're not writing any Java code whatsoever here, it's almost certainly either a configuration issue or bug in Workday Studio. Below are some observations based on the information you've provided. But first, a wild guess.
Wild Guess
It seems likely that Workday is handling this a little differently than cURL or SoapUI. cURL and SoapUI are doing something like the following:
- Send GET request to URL with params, and include API key in header
- Server sends desired response
However, it sounds like Workday is doing something more like:
- Send GET request assuming a pre-auth scenario, using challenge-type: 'token'
- Server responds with the correct auth-type that its framework (presumably Rails) uses for tokens; 'http-token-auth'
- Workday (wrongly) assumes that the server is using the Spring framework, and tries to load the correct auth-type bean based on that response
- Spring framework barfs because there's no such bean
I imagine there's some way to get Workday to play nicely with a standard REST API, and just supply the API key to the vendor's server as it expects, rather than trying to do a challenge/response.
If this isn't it, there are some more weedy possibilities below.
Odd Bean Name
The bean name specified in the error is http-token-auth
, which is in kebab-case. The convention for naming beans is (lower-) camelCase, so wherever that's specified may have just used the wrong casing.
This could be in the Workday Studio configuration, the XML config file, or some custom code you've written, if any.
Configuration
If the bean name is correct, then there's likely some other configuration issue. Spring can implicitly detect candidate components by scanning the classpath (see Spring docs: Classpath scanning and managed components) or loading it from the project XML. The issue could be:
- The build path is wrong (see this answer by esaj if you're unfamiliar)
- The classpath is wrong, so Spring just doesn't see it. This seems like a Workday-specific config in this case.
- The bean is in the project XML, but nested. In that case, it'd only be accessible to the enclosing bean. One solution to this is to activate the corresponding profile.
- A packaging issue; if the bean isn't being included in the resulting deployed jar, then there will be issues. This solution by dawrutowicz should apply in a number of cases.
- Project configuration; all the settings in your screenshots look exactly correct and should work fine, so there might be something hidden in your project settings
Bug in Workday Studio
This seems somewhat less likely, but is always a possibility. If you haven't written any Java code whatsoever, then there's something either in the Workday code that's serving up this unexpected 'http-token-auth' or inappropriately accepting it from somewhere else and trying to load up a bean using it.
Final Thoughts
Since you're trying to work with a vendor's API, I'd strongly recommend you try to collaborate with one of the engineers there. Guaranteed, they have at least one engineer who has dealt with complicated integration issues before. They'll have more details about their API, and might be able to give you more direct input on any configuration/code you'd be able to share.
To preface; I'm not familiar with Workday Studio, and there don't seem to be any public docs, so there may be some nuance here that this answer misses.
Summary
Workday, your code, or possibly some library being used is referencing a bean (see Spring docs: Core Technologies) that does not exist or can not be found.
If you're not writing any Java code whatsoever here, it's almost certainly either a configuration issue or bug in Workday Studio. Below are some observations based on the information you've provided. But first, a wild guess.
Wild Guess
It seems likely that Workday is handling this a little differently than cURL or SoapUI. cURL and SoapUI are doing something like the following:
- Send GET request to URL with params, and include API key in header
- Server sends desired response
However, it sounds like Workday is doing something more like:
- Send GET request assuming a pre-auth scenario, using challenge-type: 'token'
- Server responds with the correct auth-type that its framework (presumably Rails) uses for tokens; 'http-token-auth'
- Workday (wrongly) assumes that the server is using the Spring framework, and tries to load the correct auth-type bean based on that response
- Spring framework barfs because there's no such bean
I imagine there's some way to get Workday to play nicely with a standard REST API, and just supply the API key to the vendor's server as it expects, rather than trying to do a challenge/response.
If this isn't it, there are some more weedy possibilities below.
Odd Bean Name
The bean name specified in the error is http-token-auth
, which is in kebab-case. The convention for naming beans is (lower-) camelCase, so wherever that's specified may have just used the wrong casing.
This could be in the Workday Studio configuration, the XML config file, or some custom code you've written, if any.
Configuration
If the bean name is correct, then there's likely some other configuration issue. Spring can implicitly detect candidate components by scanning the classpath (see Spring docs: Classpath scanning and managed components) or loading it from the project XML. The issue could be:
- The build path is wrong (see this answer by esaj if you're unfamiliar)
- The classpath is wrong, so Spring just doesn't see it. This seems like a Workday-specific config in this case.
- The bean is in the project XML, but nested. In that case, it'd only be accessible to the enclosing bean. One solution to this is to activate the corresponding profile.
- A packaging issue; if the bean isn't being included in the resulting deployed jar, then there will be issues. This solution by dawrutowicz should apply in a number of cases.
- Project configuration; all the settings in your screenshots look exactly correct and should work fine, so there might be something hidden in your project settings
Bug in Workday Studio
This seems somewhat less likely, but is always a possibility. If you haven't written any Java code whatsoever, then there's something either in the Workday code that's serving up this unexpected 'http-token-auth' or inappropriately accepting it from somewhere else and trying to load up a bean using it.
Final Thoughts
Since you're trying to work with a vendor's API, I'd strongly recommend you try to collaborate with one of the engineers there. Guaranteed, they have at least one engineer who has dealt with complicated integration issues before. They'll have more details about their API, and might be able to give you more direct input on any configuration/code you'd be able to share.
answered Mar 15 '18 at 2:29
![](https://lh3.googleusercontent.com/-eFRQLq7lK3A/AAAAAAAAAAI/AAAAAAAALZ8/LRJsVNJ8N7o/photo.jpg?sz=32)
![](https://lh3.googleusercontent.com/-eFRQLq7lK3A/AAAAAAAAAAI/AAAAAAAALZ8/LRJsVNJ8N7o/photo.jpg?sz=32)
Rob TrameRob Trame
363
363
Thanks Rob for the detailed explanation. Turns out it was a bug in Workday. -Remo
– Remo Hernandez
Apr 14 '18 at 12:13
add a comment |
Thanks Rob for the detailed explanation. Turns out it was a bug in Workday. -Remo
– Remo Hernandez
Apr 14 '18 at 12:13
Thanks Rob for the detailed explanation. Turns out it was a bug in Workday. -Remo
– Remo Hernandez
Apr 14 '18 at 12:13
Thanks Rob for the detailed explanation. Turns out it was a bug in Workday. -Remo
– Remo Hernandez
Apr 14 '18 at 12:13
add a comment |
I had an identical error message reported when sending a Rest POST request to a 3rd party web service from Workday Studio using Bearer authentication.
The resolution was to set the header output type to "message" instead of a "rootpart". It is not a bug in Workday Studio.
Workday Studio set header output type setting
Regards,
Shiraz
add a comment |
I had an identical error message reported when sending a Rest POST request to a 3rd party web service from Workday Studio using Bearer authentication.
The resolution was to set the header output type to "message" instead of a "rootpart". It is not a bug in Workday Studio.
Workday Studio set header output type setting
Regards,
Shiraz
add a comment |
I had an identical error message reported when sending a Rest POST request to a 3rd party web service from Workday Studio using Bearer authentication.
The resolution was to set the header output type to "message" instead of a "rootpart". It is not a bug in Workday Studio.
Workday Studio set header output type setting
Regards,
Shiraz
I had an identical error message reported when sending a Rest POST request to a 3rd party web service from Workday Studio using Bearer authentication.
The resolution was to set the header output type to "message" instead of a "rootpart". It is not a bug in Workday Studio.
Workday Studio set header output type setting
Regards,
Shiraz
answered Nov 22 '18 at 2:09
ShirazShiraz
62
62
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f49280295%2fworkday-studio-request-with-http-out-to-vendor-api-receiving-error-with-no-be%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This seems the error is coming from your vendor api. asked them to provide sample request payload with header set. They try the same in studio.
– Hikmat
Mar 26 '18 at 11:12