Sarah Pardikes asked a question.
ShareFile API Integration Questions
- Developer access: Is there a developer/trial account or sandbox environment available so our team can build and test the integration before touching the client’s production account? Is there a cost?
- Upload flow: For a server-side .NET application uploading PDFs into a client-owned account, what is the recommended upload method (standard vs. streamed), and what does the upload response return? Specifically, does it include the item ID and folder location of the created file?
- Share links: Can we programmatically create a share link to a file immediately after uploading it? Can that link be restricted so only authenticated users of the client’s ShareFile account can open it (rather than anyone with the link)? Do links expire, and is the expiration configurable?
- Write-without-read: Can the integration account be configured so it can upload files and create links but cannot download or read file contents afterward? Which folder permission combination achieves that, and does the API enforce it? We want to verify the account genuinely cannot retrieve documents after upload.
- Overwrite/delete: With upload-only permissions, can the account overwrite or delete existing files? We’d prefer it cannot, so a compromised credential can’t destroy records.
- Authentication: For an unattended server-side integration using a dedicated service account, what OAuth2 flow is recommended? How do SSO or two-factor policies on the client’s account affect a service account? What are token lifetimes and the recommended refresh/rotation pattern?
- Redirect URIs and environments: Can one API key hold multiple redirect URIs (dev, UAT, production), or should the client request a separate key per environment?
- Errors and idempotency: What’s the recommended way to confirm an upload fully succeeded (vs. partial/failed), and is there a safe retry pattern that avoids duplicate files?
Hello @Sarah Pardikes - Thank you for posting on the forums!
Please see the responses below:
1. Developer access
ShareFile offers trial accounts for a limited period, including API access. If additional testing time is required, please contact our Sales team to discuss available options.
2. Upload flow
All upload methods documented in our API are currently supported. For on-premises StorageZones, the standard upload method has file size limitations.
For standard uploads, a successful response returns HTTP 200 with a response body similar to: OK: filename.
If you use the Threaded Uploader, you can append fmt=json to the ChunkUri to retrieve additional metadata, including the uploaded file's Item ID once the upload completes.
Documentation: https://api.sharefile.com/docs/resource?name=Items
3. Share links
Yes, share links can be created programmatically immediately after upload. Share links can be configured to require authentication depending on the share settings used when creating the Share object.
Documentation: https://api.sharefile.com/docs/resource?name=Shares
Please note that ShareFile performs antivirus scanning, and programmatic sharing can occur before the scan completes. While this is generally not an issue, we recommend validating the behavior in a trial environment.
4. Write-without-read
ShareFile supports granular folder permissions. An integration account can be granted upload permissions without download access.
However, creating share links requires download/view permissions. If your requirements include both uploading and sharing files, you would typically need separate integration accounts with different permission sets.
5. Overwrite/delete
Files are owned by the user who uploads them. As the file creator, that user can delete the uploaded file.
6. Authentication
For unattended server-side integrations, please review the following article, which discusses supported authentication options and token management:
https://support.sharefile.com/s/question/0D5QP00002akKZH0A2/is-there-a-supported-authentication-method-for-sharefile-that-allows-an-unattended-backend-service-to-obtain-and-refresh-access-tokens-without-requiring-a-browser-login-or-manual-generation-of-the-initial-authorization-code-process
7. Redirect URIs and environments
A single API key supports only one configured redirect URI. Separate API keys are required for different environments (for example, Development, UAT, and Production).
8. Errors and idempotency
A successful upload returns an HTTP 200 response. Failed uploads must be retried from the beginning.
To verify success, confirm that the upload completed and a 200 response was returned. If implementing retry logic, additional checks on your application side are recommended to prevent duplicate uploads. ShareFile does not provide a dedicated idempotency mechanism for uploads. Preventing duplicate files should be handled by the integration logic, such as tracking upload status, file hashes, or unique identifiers.
Please feel free to reach out to us for specifics.