I am getting invalid_url again and again with /save_url, https://api.dropboxapi.com/2/files/save_url

Hi @ABDUL Salam,

You don't need to tag any slash! The backslashes you added make your link invalid (and not only - the next error would be that your path in invalid too). Trace where those data are coming from, in your code, and fix whatever needed.

By the way it's not a good practice to pass access token directly. Better build one 'opaque' structure holding all authentication data and pass that structure instead. You can get access token as result of dedicated function that get as param the same 'opaque' structure. Inside such a function you can trace whether access token is going to expire (let's say there are less that 5 or 3 mins) or already expired and if so perform a refresh. In such a way you won't need to do it in every API call (or another place), but instead in every API call, you will call to that function (that's responsible to all common things of authentication, including refresh whenever needed - there implement that last step we talked about previous). 😉

Also keep in mind that validity period is NOT something fixed! It's denoted in seconds when you receive access token and in spite typically 4 hours that's NOT something mandatory - can be less in some cases. Once you receive access token calculate expiration moment (based on current moment and validity period) and store that moment for future reference.

Hope this gives directions.

Hi @Здравко
Firstly would like to appreciate your suggestion related to coding practices.
Basically, this body with slashes is the output

json_encode($payload);

that I have sent in my curl request.
Also, the main issue is if I manually run my script from the terminal locally using php script.php
It works perfectly with the same code.
But when I schedule it as a cron job on my server this script does not run as it runs locally, it does complete code flow and return me async_job_id in response but when I check using this async_job_id it always gives me this

{
".tag": "failed",
"failed": {
".tag": "invalid_url"
}
}

I wonder what could be the reason.

@ABDUL Salam As Здравко said, the backslashes you have in the output you shared here are not expected or accepted in the URL, so make sure those aren't in the actual data you're sending to the API.

As for why this works locally but not on your server, does your server have a different version of any libraries you're using? Or are you perhaps using a different URL value on the server?

in curl, I passed the payload as a json_encoded body which adds these slashes, but I have also hardcoded an HTTPS URL in the payload as
$payload= [

"path" => "myPathHere",
"url" => "https://abc.com/"

]
and then json encoded that in curl and it worked, but it's not working with dynamic url's
such as

$payload= [

"path" => "myPathHere",
"url" => $url, //my dynamic URL comes here

]
still figuring it out on my side why it's happening.

payload:{"path":"/2023/November/#1135/GOLF-P-WE-AU-BLACK/#1135_GOLF-P-WE-AU-BLACK.eps","url":"https://cdn.customily.com/ExportFile/pf-dev-3/cfa42d7e-4418-47af-b120-83e9ca35b1c1.eps"}

uploaded customily orders to dropbox: {".tag": "async_job_id", "async_job_id": "ruN7OyTfOucAAAAAAAAAAQ"} 200

payload:{"path":"/2023/November/#1134/GOLF-P-WE-AU-BLACK/#1134_GOLF-P-WE-AU-BLACK.eps","url":"https://cdn.customily.com/ExportFile/pf-dev-3/a4da1953-2618-4e17-8f60-4c81e776f0a0.eps"}

uploaded customily orders to dropbox: {".tag": "async_job_id", "async_job_id": "Tz3sCHoe4-EAAAAAAAAAAQ"} 200
these are logs of my cron job
and against these async_job_id's I am getting

{

".tag": "failed",

"failed": {

".tag": "invalid_url"

}

although my URL in body seem valid

@ABDUL Salam, to be honest, I don't know why did you received exactly that error, but your path is definitely invalid (in the second case). In Dropbox whatever path you use must NOT end in slash and when we're talking for file path, it should include filename too - something missing in your case. Fix it.

Good luck.

@Здравко It was a typo mistake (second case) I have fixed it.

Hm..🤔 I just checked it and everything seems valid. In first case I received:

{
  ".tag": "complete",
  "name": "#1135_GOLF-P-WE-AU-BLACK.eps",
  "path_lower": "/2023/november/#1135/golf-p-we-au-black/#1135_golf-p-we-au-black.eps",
  "path_display": "/2023/November/#1135/GOLF-P-WE-AU-BLACK/#1135_GOLF-P-WE-AU-BLACK.eps",
  "id": "id:ElL7W-JPrdMAAAAAAABbFw",
  "client_modified": "2023-11-28T09:48:28Z",
  "server_modified": "2023-11-28T09:48:29Z",
  "rev": "60b335227a2e322ab554a",
  "size": 82890,
  "is_downloadable": true,
  "content_hash": "e84f56b1b7802b8cc4be23d765222a27b7286852f672a077c918f82b9cbae0e7"
}

Of course, It appears as expected:

изображение.png

The same when talking for the second case (after your typo correction):

{
  ".tag": "complete",
  "name": "#1134_GOLF-P-WE-AU-BLACK.eps",
  "path_lower": "/2023/november/#1134/golf-p-we-au-black/#1134_golf-p-we-au-black.eps",
  "path_display": "/2023/November/#1134/GOLF-P-WE-AU-BLACK/#1134_GOLF-P-WE-AU-BLACK.eps",
  "id": "id:ElL7W-JPrdMAAAAAAABbEg",
  "client_modified": "2023-11-28T09:42:34Z",
  "server_modified": "2023-11-28T09:42:35Z",
  "rev": "60b333d0821f622ab554a",
  "size": 251734,
  "is_downloadable": true,
  "content_hash": "80b133e0c090344bf04204c78b396fac3ef591122cd343ffd1722b7db8c82ab0"
}

изображение.png

To be able see "what is actually going through the wire" you need to inspect the actual queries (not just your logs). It's easy using netcat runing on your local machine and directing your queries there (replacing https://api.dropboxapi.com with http://XXX.XXX.XXX.XXX:8080). Here "XXX.XXX.XXX.XXX" is you public IP address and 8080 appropriate port to listen on. I suppose you know how to redirect such a query. In such a way you can see exactly what's going out of your code and what's wrong (not just supposings).

Good luck.

@ABDUL Salam Like Здравко, I just tried this using the values you provided and it also worked without issue for me. If you're still seeing this issue, please check the exact values you're sending as they mentioned, and if there's an issue on the Dropbox API side, share a sample we can use to reproduce it. Thanks!

@Greg-DB @Здравко

Listening on 0.0.0.0 8080
Connection received on DN-12 57
POST /2/files/save_url HTTP/1.1
Host: MY_IP:8080
Accept: */*
Authorization: Bearer sl.<tokenhere>
Content-Type: application/json
Content-Length: 174

{"path":"/2023/November/#1138/GOLF-P-WE-AU-BLACK/#1138_GOLF-P-WE-AU-BLACK.eps","url":"https://cdn.customily.com/ExportFile/pf-dev-3/a79b3bc0-80a1-4e48-aae7-eab0edd4b54d.eps"}

this is what I got after running netcat on my local machine and redirecting queries to my local system.

@ABDUL Salam Thanks for sharing that. I just tried plugging in those exact values, and the file saved successfully for me. Are you still seeing this issue if you try those exact values?

@Greg-DB

The issue arises when I execute my script as a cron task on my hosting platform. This script performs the following tasks:

Retrieves orders from an ecommerce store.
Processes the received data to refine its format.
Searches for a specific URL attribute within each order and stores it in an array if found.
Subsequently, it initiates a call to the Dropbox API to acquire an access_token. This token is obtained using a previously stored refresh token. Following this, it invokes the '/save_url' endpoint.
All operational information is logged in a dedicated file, signifying the successful completion of each step. However, upon calling the '/save_url' endpoint, an 'async_job_id' is returned.
Using this 'async_job_id' for verification purposes consistently results in an 'invalid URL' error. Interestingly, the same URL functions correctly when hardcoded in /save_url request parameter.

The same like in Greg's experiment, everything works as expected.

@ABDUL Salam wrote:
... It was working fine early on locally bu as soon as I have deployed my script and check the logs after execution then this endpoint returns me a async_job_id which I use to check job status from https://api.dropboxapi.com/2/files/save_url/check_job_status and I get ...

@ABDUL Salam, In this context, do you redirect your call from local machine or from the place where you are trying to deploy your script (where it fails actually)? If you do it locally only,... 🙂

@ABDUL Salam wrote:
... Interestingly, the same URL functions correctly when hardcoded in /save_url request parameter.

Do it in the same way when the request fails, not like when succeeds!

@Greg-DB Is there any way we can check what URL/OR params were passed to the job so that from its async_job_id we can see it in response? This currently generically gives a failed tag with invalid_url.
https://api.dropboxapi.com/2/files/save_url/check_job_status

{

".tag": "failed",

"failed": {

".tag": "invalid_url"

}