Feature Request: Support Additional Data Sources (S3, SharePoint, etc.(native support)) other than FileSource and HTTPSource

[madhukargunda]

Currently, the Docling Java project supports document ingestion from the local file system and URLs.
While this works for basic use cases, many real-world and enterprise scenarios store documents in S3, SharePoint, or other cloud storage systems.

At the moment, there is no native support for connecting to these data sources.
Could you please consider this as a feature request to support additional cloud and enterprise document sources?

[edeandrea]

For now we support whatever the underlying docling-serve implementation supports. Maybe this feature request belongs there?

[madhukargunda]

@edeandrea The current version of Docling Serve already supports S3 integration. Below is a sample request and response demonstrating this capability.

This functionality could be implemented (or mirrored) as part of the Docling Java project to provide native support for S3-based document ingestion. Other integrations i will raise the issue in docling serve project.

{
  "sources": [
    {
      "kind": "s3",
      "endpoint": "s3.us-east-2.amazonaws.com",
      "access_key": "<your-access-key>",
      "secret_key": "<your-secret-key>",
      "bucket": "<your-bucket>",
      "key_prefix": "optional/prefix/",
      "verify_ssl": true
    }
  ],
  "target": {
    "kind": "s3",
    "endpoint": "s3.us-east-2.amazonaws.com",
    "access_key": "<your-access-key>",
    "secret_key": "<your-secret-key>",
    "bucket": "<your-bucket>",
    "key_prefix": "optional/output/",
    "verify_ssl": true
  }
}

[edeandrea]

Thank you for that. I will take it up once I am back from the holidays!

[edeandrea]

I'm happy to implement this, but I question whether sending your own access/secret keys within an unencrypted request body to some 3rd party system (i.e. Docling-serve) is a good idea?

To me it feels very succeptable to man-in-the-middle attacks and an easy way to leak your keys.

[edeandrea]

@madhukargunda have you successfully tried that REST request with a docling-serve instance? When I try it I get

← RESPONSE: 422
  HEADERS:
  content-length: 274
  content-type: application/json
  date: Sat, 27 Dec 2025 18:51:59 GMT
  server: uvicorn
  BODY:
{
  "detail" : [ {
    "type" : "error source",
    "loc" : [ "body" ],
    "msg" : "source kind \"s3\" requires engine kind \"KFP\"",
    "input" : {
      "sources" : [ {
        "kind" : "s3",
        "endpoint" : "127.0.0.1:39725",
        "access_key" : "test",
        "secret_key" : "test",
        "bucket" : "docling-java-tests",
        "verify_ssl" : false
      } ],
      "options" : { }
    }
  } ]
}

I've opened docling-project/docling-serve#462 for this

[edeandrea]

Seems like using s3 sources requires using Kubeflow. I'm not sure how I'm supposed to test that what I have here actually works. I can verify that the request body in the json contains the correct information but I can't really test the end-to-end flow unfortunately.

I was trying to use Localstack or Minio testcontainers to simulate the s3 storage.

[edeandrea]

@madhukargunda see #256

[madhukargunda]

@edeandrea Thank you !! .

[madhukargunda]

@edeandrea This is a valid concern, and I agree that blindly forwarding access/secret keys in plaintext would be unsafe.
other note

All communication with docling-serve is expected to happen over HTTPS/TLS, so the request body is encrypted in transit. Without TLS, this would indeed be vulnerable to MITM attacks. My assumption here is that docling server runs in a trusted environment.

the other alternate option considering is defining a clear security contract between the client and docling-serve .
This means the client and server may decide on an application-level encryption method for sensitive fields (like access/secret keys) in addition to HTTPS/TLS in transit, so credentials are:

• Before being sent, the client encrypts.
• Only inside docling-serve is it decrypted.
• Logs, intermediate proxies, and the wire are never visible in plaintext.

[edeandrea]

I 100% agree that just having TLS in transport is not good enough. Credentials like this should be supplied in a more secure manner, either through headers, tokens, etc.

Unfortunately that is something that the docling-serve team needs to implement before I can do anything on my side.

@dolfim-ibm thoughts? Should we move the security part of this conversation over to docling-serve?