Forum Discussion

AJ81's avatar
AJ81
Copper Contributor
Dec 02, 2025

Copy Data Activity Failed with Unreasonable Cause

It is a simple set up but it has baffled me a lot. I'd like to copy data to a data lake via API. Here are the steps I've taken:

  • Created a HTTP linked service as below:

 

  • Created a dataset with a HTTP Binary data format as below:

 

 

  • Created a pipeline with a Copy Data activity only as shown below:

 

  • Made sure linked service and dataset all working fine as below:

 

 

  • Created a Sink dataset with 3 parameters as shown below:

 

 

 

  • Passed parameters from pipeline to Sink dataset as below:

 

 

  • That's all. Simple, right? But the pipeline failed with a clear message "usually this is caused by invalid credentials." as below:

 

 

Summary: No need to worry about the Sink side of parameters etc. which I have used same thing for years on other pipelines and all succeeded. This time the API failed to reach a data lake from source side as said "invalid credentials". In Step 4 above one could see the linked service and dataset connections were succeeded, ie. credentials have been checked and passed already. How come it failed in data copy activity complaining an invalid credentials? Pretty weird. Any advice and suggestions will be welcomed.

 

 

1 Reply

  • The screenshots point to a request-authentication mismatch, not the sink. The activity is receiving a real HTTP 401. Your linked-service description says Ocp-Apim-Subscription-Key and token values are required, but the Copy Activity source shows Additional headers empty. A successful Test connection does not prove the final GET request is authorized; it validates the linked-service endpoint and configured Basic credential.

     

    Send the same authentication data the API expects on the runtime request. If APIM requires a subscription key, add Ocp-Apim-Subscription-Key. If it requires a bearer token, add Authorization: Bearer <token>, or use the API’s exact token header. Keep those values in Key Vault or secure authentication headers rather than plain text.

     

    Then reproduce the exact URL, method, and headers outside ADF. A 401 there confirms the API-side contract. If it fails only in ADF, inspect the activity output for the resolved request URI and confirm the factory managed identity can read the current Key Vault secret. The sink is irrelevant until the source returns a 2xx response.