Hi Mark,

This should be the way to do it:

The {api_key_value} needs to be an Endpoint input parameter, after which you can supply a value through the process flow input parameter to this parameter.

Or choose to enter a static value with the API key value, e.g. "ABCDEF123456”

@Mark Jongeling 

That does not seem to do it.

I have even recreated the most basic HTTP connector to compare it with and that one works, but the Web connection gets rejected.

For my testing purpose I have entered the value as static.
 

It is also hard to debug these processes as the main thing I can get from like a process flow monitor is that the Web connection gave me a status 0. Looking in Application Insight I see that the url is indeed made the exact way as the HTTP connector version, except I cannot see information about the header.

The endpoint is giving me a 401, which is to be expected when the header is not applied or not applied with the correct information/format.

For completeness what I have in the basic HTTP connector
 

Any suggestions what should be changed about the Headers in the Web connection or how I might see more information what the Web connection outputs?

Oh sorry Mark, I made a mistake. The name should have been x-api-key and the value the api-key value, like this:

Name = Key, Value = Value 

Hope this does the trick!

That did the trick!

I am not too familiar with these type of processes, but is the column name “Name” still the correct one to use in this case or would it benefit from a rename to “Key”? (I understand it could mean more work than just a translation change)

Thanks for the help. This at least motivates that reworking our process flows should not be too much trouble and we can get rid of a lot of DB stored information to make HTTP connectors work over different environments.