Skip to main content

Official SDKs

An SDK (Software Development Kit)External LinkThis link leads to an external website and will open in a new tab is a pre-built library that lets your application talk to an external platform without implementing the underlying API yourself. Instead of constructing HTTP requests, parsing responses, and writing retry logic from scratch, you call functions in your favorite programming language that handle all of that for you. Companies publish SDKs to make their APIs easier to use correctly.

Many vendors treat their SDKs as an afterthought. They fall behind the API, miss features, have outdated documentation or broken code examples, and get updated only when customers complain. Files.com builds its own products on the same SDKs we publish, so ours are kept current.

What the Official SDKs Provide

The SDKs expose the Files.com REST API using your preferred programming language. If you're able to use one of our supported SDK languages, we strongly recommend using its SDK. Integrating directly against the REST API with a basic HTTP client or curl will work for a simple one-off request, but you're stuck managing the hardest parts of the integration that fail in production: retries, backoff, error handling, pagination, parallelizing transfers, and upload chunking.

Authentication and request formatting are handled for you by the SDK, so you don't need to construct signed requests or manage API conventions manually. Requests that fail due to temporary network or server conditions are retried automatically, with increasing delays between attempts, so your integration recovers from transient failures without extra error-handling code. Pagination works the same way: when a response spans multiple pages, the SDK fetches subsequent pages without requiring you to track cursors or page tokens.

For file transfers, the SDKs apply chunking and, in some languages, parallel uploads and downloads. This is why SDK-based transfers are faster than going through the file transfer protocols directly.

Files.com uses several of its own SDKs internally, which means they get continuous real-world testing. New platform features appear in SDK releases as they ship.

Supported SDK Languages

Files.com maintains SDKs for seven languagesExternal LinkThis link leads to an external website and will open in a new tab. Each is published to the appropriate package manager and has a dedicated section in the developer docs with installation instructions, configuration options, guidance for filtering and sorting, usage examples, and a full API reference of every object type.

Releases are tagged by version, which makes it easy to review what changed before upgrading.

The JavaScript SDK Is for Server-Side Use Only

The JavaScript SDK runs in Node.js. It is not for use in the browser.

Calling the Files.com REST API from browser-side JavaScript will produce CORS errorsExternal LinkThis link leads to an external website and will open in a new tab for your users. Your integration code using the JavaScript SDK must run on a server.

.NET SDK Version Requirements

The .NET SDK requires .NET 6 or later for full compatibility with our default secure ciphers.

TLS 1.3 support in .NET also depends on the underlying operating system. .NET 6 and newer provide partial TLS 1.3 support only on Windows 11, Windows Server 2022, or Linux distributions backed by OpenSSL 1.1.1 or later.

Using Older .NET Versions

If you are on an older version of .NET, the resolution depends on which version you are running.

If you are on .NET 4.5, TLS 1.2 is supported but is not enabled by default. Execute the following code before making a connection to opt in:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

If you are on .NET 4.0, TLS 1.2 is not supported. You will need to upgrade your application to a more recent version of the framework to use TLS 1.2.

If you cannot upgrade your .NET application, you can use the Insecure Ciphers capability in Files.com as a last resort.

SDK Authentication Methods

SDKs support two authentication methods: API key and session-based.

API key authentication is recommended for headless or unattended integrations. API keys can be site-wide, giving full access to the entire site, or scoped to a specific user to limit what the integration can access.

Session-based authentication creates a session using a username and password. It's best for an interactive application where users sign in with their own Files.com credentials. Sessions follow the same timeout rules as web interface sessions. When a session expires, your code needs to create a new one. SDKs can't re-authenticate sessions automatically, because they won't store your password.

Choosing Between an SDK and Other Methods

If your environment requires working in a supported language, we always recommend using its SDK.

If you're building an AI application, the Files.com MCP Server provides structured tools to interact with your Files.com site, available with no extra coding required.

If your environment calls for a scripting language, Infastructure as Code, an iPaaS platform, or a system that only supports file transfer protocols, consult the full decision guide covering all available integration methods.