Skip to main content

File Upload

The Lovina Chat SDK supports sending files (images, documents, audio, video) through the chat widget. Users can attach files via the paperclip button in the message composer.

Supported File Types and Size Limits​

ConstraintLimit
Max files per message5
Max file size5 MB per file
Accepted typesimage/*, application/pdf, text/*, audio/*, video/*

Enabling / Disabling File Upload​

File upload is enabled by default on web. To disable it:

window.lovinaSettings = {
features: { enable_file_upload: false },
};

File upload is disabled by default on native/hybrid platforms (Flutter, iOS, Android, React Native) — a browser file picker just works, but native platforms have real permission and setup requirements the widget can't verify on your behalf. To enable it, opt in explicitly once you've done the platform-specific setup described in How It Works on Each Platform:

// React Native
features: { enable_file_upload: true }

Flutter, iOS, and Android use the same enableFileUpload flag on their own LovinaFeatureFlags type instead — see the Flutter, iOS, or Android configuration reference for the exact syntax.

An explicit value from the host always wins, except on Android, where true is only honored if the native file picker actually registered.

How It Works​

User Experience​

  1. Attach files — User taps the paperclip icon in the composer to open the native file picker.
  2. Preview — Selected files appear in a horizontal preview strip below the composer. Images show thumbnails; other files show a file icon with extension.
  3. Remove — Each preview has an "x" button to remove a file before sending.
  4. Send — User taps send. Files are uploaded, then the message is sent with attachment references.
  5. Display — Images render inline in the message bubble. Other files show as download links with file icon and size.

Upload Flow​

The SDK uses a two-step upload flow:

1. User picks file(s) via native file picker
2. Files validated client-side (size + count limits)
3. Files staged in preview strip with blob URL thumbnails
4. On send:
a. A chat session is established first, if one doesn't already exist —
needed before any file can be uploaded
b. Upload each file: POST /sdk/chat/upload
→ Returns { attachment_id, file_url }
c. Send message: POST /sdk/chat/message
→ Body includes { message, attachment_ids: ["att-1", "att-2"] }
d. AI responds via SSE stream
5. On any upload failure: the whole message is marked failed (never sent
partially or text-only) and shows a Retry button. Files that already
uploaded successfully are not re-uploaded on retry.

Upload API​

Step 1: Upload File

POST /sdk/chat/upload
Authorization: Bearer <websiteToken>
X-Session-Token: <session_token>
Content-Type: multipart/form-data

Fields:
session_id string Active session ID
file File The file to upload (widget caps at 5MB; allow slightly more server-side for multipart overhead)

Response:

{
"attachment_id": "019078c3-d4e5-7f01-2345-678901abcdef",
"file_url": "https://storage.example.com/chat-attachments/.../document.pdf",
"file_name": "document.pdf",
"content_type": "application/pdf",
"size_in_bytes": 102400
}

Step 2: Send Message with Attachments

POST /sdk/chat/message
Authorization: Bearer <websiteToken>
Content-Type: application/json

{
"agent_config_id": "agent-xxx",
"message": "Here is the file",
"session_id": "session-xxx",
"attachment_ids": ["019078c3-d4e5-7f01-2345-678901abcdef"]
}

Attachment Object (in messages)​

FieldTypeDescription
idstringUnique attachment ID
fileTypestringCategory: 'image', 'file', 'audio', 'video'
dataUrlstringURL to download/view the file
thumbUrlstringThumbnail URL (images only)
fileSizenumberFile size in bytes

Error Handling​

ScenarioWhat User Sees
File > 5MBToast: "filename exceeds 5.0 MB limit" — file rejected
Server rejects the upload as too large (413)Toast: "File is too large to upload. Please choose a smaller file."
Unsupported file typeToast: "filename is not a supported file type" — file rejected
> 5 filesToast: "Maximum 5 files allowed" — extras rejected
Upload fails — network errorToast: "Network error. Check your connection."
Upload fails — session/auth (401)Toast: "File upload failed. Please refresh and try again. (401)"
Upload fails — server error (5xx)Toast: "Server error. Please try again later. (5xx)"
Upload fails — any other statusToast: "File upload failed. (status)"
Upload fails — no status determinedToast: "File upload failed."
Any upload failsThe whole message (text and any other attachments) is marked failed, never sent — no partial or text-only fallback
RetryFailed messages show red bubble with Retry button. Files that already uploaded successfully are preserved and not re-uploaded.

Platform Support​

PlatformStatusNotes
Web (all browsers)SupportedNative <input type="file"> with preview strip
Android WebViewSupportedonShowFileChooser + ActivityResultLauncher
iOS WKWebViewSupportedWKWebView presents a native action sheet internally (Photo Library, Take Photo or Video, Choose Files)
React NativeSupportedallowFileAccess props on WebView (v11+)
FlutterSupportedAndroid: dedicated file-selector plugin · iOS: native WKWebView
tip

File upload is supported on all platforms — support isn't the same as enabled-by-default, though; see Enabling / Disabling File Upload above for each platform's default.

How It Works on Each Platform​

When a user taps the paperclip button, the widget triggers <input type="file">. Each platform handles this differently:

PlatformWhat OpensPermissions Needed
WebBrowser file dialogNone
AndroidSystem file picker (ACTION_GET_CONTENT)None (system picker handles its own)
iOSNative action sheet (Photo Library, Take Photo or Video, Choose Files)None for Photo Library and Choose Files; the camera option has a requirement — see below
React NativeNative file picker via react-native-webviewNone
FlutterSystem file picker (ACTION_OPEN_DOCUMENT)None (system picker handles its own)
Important for Native SDK Developers

Android: Always call onReceiveValue() — even on cancel — or the WebView file input will hang permanently.

iOS: Always call completionHandler() — even on cancel — or WKWebView's file input silently breaks.

Permission Handling​

File upload uses system file pickers on most platforms, which means no runtime permissions are required from the user — the OS handles file access internally. iOS is the exception: WKWebView's action sheet also offers a camera capture option alongside Photo Library and Choose Files, and that option does carry a permission requirement (see below).

However, there are edge cases:

ScenarioWhat HappensUser Sees
Android: no file manager appIntent.createChooser shows empty list"No apps can perform this action" dialog
iOS: iCloud file not downloadedOS downloads file firstiOS download progress indicator
iOS: camera / video captureThe WKWebView action sheet's "Take Photo or Video" option is reachable today, and needs NSCameraUsageDescription and NSMicrophoneUsageDescription in Info.plist -- omitting either one crashes the app on tap, it does not just deny the prompt. This is default WKWebView behavior the SDK doesn't control -- see iOS File Uploads for why.iOS permission prompt (or a crash if the keys are missing)
Android < 13: restricted storageSystem picker still worksNormal picker (system handles permissions)
Android: WebView not configured<input type="file"> click does nothingAttach button hidden (enable_file_upload resolves to false)
Android: host context isn't a ComponentActivityThe SDK can't register a file picker at all; if enableFileUpload = true was requested, onEvent also receives ChatEvent.Error(code = "file_upload_unavailable")Attach button hidden; logcat shows LovinaChatWidget: Host context is not a ComponentActivity...
Android: enableFileUpload = true but the picker registered too lateThe button downgrades to hidden and onEvent receives ChatEvent.Error(code = "file_upload_unavailable")Attach button hidden; logcat shows LovinaChatWidget: Too late to register the file picker...
User cancels pickeronReceiveValue(null) / completionHandler(nil) calledNothing happens, widget stays functional
Permissions summary

Picking a file from the system UI — Photo Library, Choose Files, the Android or web file picker — does not require any runtime permission prompts; the OS grants temporary read access to that specific file. The one exception is iOS's in-sheet camera capture option, which needs the Info.plist keys noted above.