Some Requests/Shares initiated via API show a blank recipient in the Sharefile message log

We recently implemented a custom integration with Salesforce using Sharefile's API. We have some processes that create files and trigger invites to be sent to those files for upload or download. A few of the messenger log entries in Sharefile from these processes are not showing a recipient of the share (It just shows a blank space- see below). Can you help us understand why that might be? We are using sf/v3/Shares/Request and sf/v3/Shares/Send endpoints. It is not clear on the blank logs who the message was intended for and if they received it or not. Blank recipient example


  • Hi Bob,

     

    Any clear, defining characteristics of the specific calls that are failing to display the recipient? Request vs Send, missing contact info from Salesforce, etc?

     

    As per api.sharefile.com, Request vs Share links should be established in the request payload, to the same endpoint rather than separate endpoints.

     

    In my quick testing, specifying a recipient that's not already an existing user on your ShareFile account should produce an error, but still show "Anonymous" in the message history; likewise, leaving a recipient off entirely will produce a response with a link (with no authentication required) but also still show "Anonymous" in the message history.

     

    My most immediate suggestion is to retry with the officially supported endpoints. If this continues, any additional context you're able to share would be helpful.

     

    To send:

    POST to https://account.sf-api.com/sf/v3/Shares?notify=false

    { 

     "ShareType":"Send", 

     "Title":"Sample Send Share", 

     "Items": [ { "Id":"itemid01" }, { "Id":"itemid02" } ], 

     "Recipients":[ { "User": { "Id":"userid" } }, { "User": { "Email": "user@email" } } ], 

     "ExpirationDate": "2013-07-23", 

     "RequireLogin": false, 

     "RequireUserInfo": false, 

     "UsesStreamIDs": false

    } 

     

    To request:

    https://account.sf-api.com/sf/v3/Shares?notify=false

    { 

     "ShareType":"Request", 

     "Title":"Sample Request Share", 

     "Recipients":[ { "User": { "Id":"userid" } }, { "User": { "Email": "user@email" } } ], 

     "Parent": { "Id":"folderid" }, 

     "ExpirationDate": "2013-07-23", 

     "RequireLogin": false, 

     "RequireUserInfo": false, 

     "TrackUntilDate": "2013-07-23", 

     "SendFrequency": -1, 

     "SendInterval": -1 

    } 

     

     

    Selected as Best
  • Hi Bob,

     

    Any clear, defining characteristics of the specific calls that are failing to display the recipient? Request vs Send, missing contact info from Salesforce, etc?

     

    As per api.sharefile.com, Request vs Share links should be established in the request payload, to the same endpoint rather than separate endpoints.

     

    In my quick testing, specifying a recipient that's not already an existing user on your ShareFile account should produce an error, but still show "Anonymous" in the message history; likewise, leaving a recipient off entirely will produce a response with a link (with no authentication required) but also still show "Anonymous" in the message history.

     

    My most immediate suggestion is to retry with the officially supported endpoints. If this continues, any additional context you're able to share would be helpful.

     

    To send:

    POST to https://account.sf-api.com/sf/v3/Shares?notify=false

    { 

     "ShareType":"Send", 

     "Title":"Sample Send Share", 

     "Items": [ { "Id":"itemid01" }, { "Id":"itemid02" } ], 

     "Recipients":[ { "User": { "Id":"userid" } }, { "User": { "Email": "user@email" } } ], 

     "ExpirationDate": "2013-07-23", 

     "RequireLogin": false, 

     "RequireUserInfo": false, 

     "UsesStreamIDs": false

    } 

     

    To request:

    https://account.sf-api.com/sf/v3/Shares?notify=false

    { 

     "ShareType":"Request", 

     "Title":"Sample Request Share", 

     "Recipients":[ { "User": { "Id":"userid" } }, { "User": { "Email": "user@email" } } ], 

     "Parent": { "Id":"folderid" }, 

     "ExpirationDate": "2013-07-23", 

     "RequireLogin": false, 

     "RequireUserInfo": false, 

     "TrackUntilDate": "2013-07-23", 

     "SendFrequency": -1, 

     "SendInterval": -1 

    } 

     

     

    Selected as Best
  • Hi Bob,

     

    I was able to reproduce the missing recipient behavior when creating shares using the POST /sf/v3/Shares/Request endpoint shown in your example.

     

    In my testing, shares created using the documented POST /sf/v3/Shares endpoint with the recipient specified in the request payload correctly populated the recipient information in Sent Messages, while requests created through /sf/v3/Shares/Request resulted in entries where the recipient was not displayed.

     

    As Bruno mentioned, /sf/v3/Shares/Request is not one of the documented share creation endpoints. The supported approach is to create both Send and Request shares using POST /sf/v3/Shares and specify "ShareType":"Send" or "ShareType":"Request" in the payload.

     

    I'd recommend updating the integration to use the documented endpoint and payload structure Bruno provided above. Based on my testing, that avoids the missing-recipient behavior in Sent Messages.

     

    Please let us know if you continue to see the issue after switching to the documented endpoint.