Build File Transfer Into Your Product.
Add INNORIX file transfer to your application with APIs and SDKs. Keep your own UI and user experience while INNORIX handles file movement behind the scenes.
Python
Create the code step by step to create, monitor, and control a 1:1 transfer by calling the API from a Python application between two already registered devices.
Device registration is assumed to be complete (the source and target devices are displayed in the device list). Always check the Swagger documentation for the exact endpoint schema.
Common Setup
First, configure a reusable session and authentication headers for all requests.
Base URL and Session Setup
Configure the common settings once with requests.Session and reuse them.
Issue a Token by Logging In
Log in with your account to obtain an access token. Use data.user.accessToken from the response for subsequent requests.
Configure Authentication Headers
Add the issued token and workspace ID to the session's default headers so you do not need to specify them repeatedly for each request.
If the token expires, obtain a new token using POST /api/auth/refresh-token (header X-Refresh-Token) or GET /api/auth/get-token, then set it again.
Create a 1:1 Transfer
This is the core flow for sending files directly from the source device to the target device.
Check the Source and Target Devices
Use GET /api/device to retrieve the device list and identify the deviceId of the device that will send the files (source) and the device that will receive them (target).
Check Connectivity
Checking that both the source and target devices are online before starting the transfer can reduce failures.
Browse the Source Path
Skip this step if the file path to be sent is already known in the code. If the path needs to be found dynamically, browse the path on the source device.
Specify the Target Path
Specify the target storage path as a plain-text absolute path based on the target device.
For Windows paths, it is safer to use forward slashes (/) instead of backslashes (\).
Create the Transfer
Create the transfer using the source/target deviceId, the file paths to send, and the target storage path (targetPath). Save the monitorId from the response because it is used for subsequent control and monitoring.
Request body fields: sourceId (sending device), targetId (receiving device), targetPath (storage path on the target device), sourceItem (list of files/folders to send — specifying a folder path also transfers its contents).
Check Transfer Status
Poll the progress periodically using monitorId. Wait until the transfer is completed or fails.
After completion, retrieve the detailed result with GET /api/transfer-history/{monitorId}/detail?idType=monitor and file-level results with GET /api/transfer-history/{monitorId}/get-files?idType=monitor.
The exact status strings (
completed, etc.) may vary depending on the environment, so check the actual response logs before finalizing the termination conditions.
Transfer Control
Control an in-progress transfer using monitorId.
Pause · Resume · Cancel
All three actions use PATCH requests with no request body.
Pass one of pause, resume, or cancel as the action.
Retry Failed Files
If some files fail during the transfer, retry only the failed files.
Complete Example
This is a minimal executable example that combines login, transfer creation, and status polling. For actual integration, enhance token renewal, error handling, and retries as appropriate for your environment.
Automation
For scheduled transfers that run repeatedly at a specified time, use the automation endpoint instead of the one-time manualTransfer. The field structure differs from an immediate transfer, so first check the differences below.
| Item | Immediate transfer (manualTransfer) | Scheduled transfer (automation) |
|---|---|---|
| Source/target fields | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (object array) | ["...", "..."] (string array) |
| Execution | Once immediately | Repeated according to schedule |
Configure the Schedule
Define the execution cycle. Use hour and minute for the execution time, timezone for the reference time zone, and startDate and endDate for the validity period.
type is day (every day), hour and minute specify the execution time (for example, 09, 30), timezone specifies the reference time zone (for example, Asia/Seoul), and startDate and endDate use ISO 8601 UTC format (for example, 2026-01-01T00:00:00.000Z).
Create an Automation
Create an automation containing the schedule and transfer details (details). Use the automationId from the response for subsequent updates, deletion, and control.
Example:
Automatically Generate an Automation Name
If you do not want to specify a name manually, the server can generate one.
Pause · Resume Automation
Use the pause value to stop or restart the automation.
Update · Delete Automation
Change the schedule or transfer details, or remove the automation.
Retrieve the automation's progress and status with GET /api/automation/{automationId}/details.
Common Issues
| Symptom | Cause · Solution |
|---|---|
401 Unauthorized | Token expired or header missing. Refresh the token with refresh-token and call set_auth() again. |
| Transfer does not start | Source/target device is offline. Check whether both devices are online with connectivity. |
| File is saved in the wrong location | Check that targetPath is an absolute path based on the target device. |
| Source file cannot be found | sourceItem path is not an absolute path based on the source device. Check the actual path with fileSearchV3. |
| Only some files fail | Retry only the failed files with retry-failed-files. |
Development Resources and Examples
Code examples and documentation required for transfer integration are available on INNORIX GitHub, and the complete endpoint specification is available in the Swagger documentation.
Node.js
Create the code step by step to create, monitor, and control a 1:1 transfer by calling the API from a Node.js application between two already registered devices.
Device registration is assumed to be complete (the source and target devices are displayed in the device list). Always check the Swagger documentation for the exact endpoint schema.
Node.js 18 or later can use the built-in fetch directly (no additional installation required).
Common Setup
First, configure the constants and authentication headers to be reused for all requests.
Base URL and Constants
Declare the Base URL, workspace ID, and token variable that will be populated after login.
Issue a Token by Logging In
Log in with your account to obtain an access token. Use data.user.accessToken from the response for subsequent requests.
Configure Authentication Headers
Create a function containing the token and workspace ID and reuse it for subsequent requests.
If the token expires, obtain a new token using POST /api/auth/refresh-token (header X-Refresh-Token) or GET /api/auth/get-token, then set it again.
Create a 1:1 Transfer
This is the core flow for sending files directly from the source device to the target device.
Check the Source and Target Devices
Use GET /api/device to retrieve the device list and identify the deviceId of the device that will send the files (source) and the device that will receive them (target).
Check Connectivity
Checking that both the source and target devices are online before starting the transfer can reduce failures.
Browse the Source Path
Skip this step if the file path to be sent is already known in the code. If the path needs to be found dynamically, browse the path on the source device.
Specify the Target Path
Specify the target storage path as a plain-text absolute path based on the target device.
For Windows paths, it is safer to use forward slashes (/) instead of backslashes (\).
Create the Transfer
Create the transfer using the source/target deviceId, the file paths to send, and the target storage path (targetPath). Save the monitorId from the response because it is used for subsequent control and monitoring.
Request body fields: sourceId (sending device), targetId (receiving device), targetPath (storage path on the target device), sourceItem (list of files/folders to send — specifying a folder path also transfers its contents).
Check Transfer Status
Poll the progress periodically using monitorId. Wait until the transfer is completed or fails.
After completion, retrieve the detailed result with GET /api/transfer-history/{monitorId}/detail?idType=monitor and file-level results with GET /api/transfer-history/{monitorId}/get-files?idType=monitor.
The exact status strings (
completed, etc.) may vary depending on the environment, so check the actual response logs before finalizing the termination conditions.
Transfer Control
Control an in-progress transfer using monitorId.
Pause · Resume · Cancel
All three actions use PATCH requests with no request body.
Pass one of pause, resume, or cancel as the action.
Retry Failed Files
If some files fail during the transfer, retry only the failed files.
Complete Example
This is a minimal executable example that combines login, transfer creation, and status polling. For actual integration, enhance token renewal, error handling, and retries as appropriate for your environment.
Automation
For scheduled transfers that run repeatedly at a specified time, use the automation endpoint instead of the one-time manualTransfer. The field structure differs from an immediate transfer, so first check the differences below.
| Item | Immediate transfer (manualTransfer) | Scheduled transfer (automation) |
|---|---|---|
| Source/target fields | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (object array) | ["...", "..."] (string array) |
| Execution | Once immediately | Repeated according to schedule |
Configure the Schedule
Define the execution cycle. Use hour and minute for the execution time, timezone for the reference time zone, and startDate and endDate for the validity period.
type is day (every day), hour and minute specify the execution time (for example, 09, 30), timezone specifies the reference time zone (for example, Asia/Seoul), and startDate and endDate use ISO 8601 UTC format (for example, 2026-01-01T00:00:00.000Z).
Create an Automation
Create an automation containing the schedule and transfer details (details). Use the automationId from the response for subsequent updates, deletion, and control.
Example:
Automatically Generate an Automation Name
If you do not want to specify a name manually, the server can generate one.
Pause · Resume Automation
Use the pause value to stop or restart the automation.
Update · Delete Automation
Change the schedule or transfer details, or remove the automation.
Retrieve the automation's progress and status with GET /api/automation/{automationId}/details.
Common Issues
| Symptom | Cause · Solution |
|---|---|
401 Unauthorized | Token expired or header missing. Refresh the token with refresh-token and reset accessToken. |
| Transfer does not start | Source/target device is offline. Check whether both devices are online with connectivity. |
| File is saved in the wrong location | Check that targetPath is an absolute path based on the target device. |
| Source file cannot be found | sourceItem path is not an absolute path based on the source device. Check the actual path with fileSearchV3. |
| Only some files fail | Retry only the failed files with retry-failed-files. |
Development Resources and Examples
Code examples and documentation required for transfer integration are available on INNORIX GitHub, and the complete endpoint specification is available in the Swagger documentation.
Java
Create the code step by step to create, monitor, and control a 1:1 transfer by calling the API from a Java application between two already registered devices.
Device registration is assumed to be complete (the source and target devices are displayed in the device list). Always check the Swagger documentation for the exact endpoint schema.
Use the built-in HttpClient (java.net.http) in Java 11+, and use Jackson for JSON processing (Maven dependency).
Common Setup
First, configure a reusable client and authentication headers for all requests. The methods in each subsequent step belong to this ExacoolaClient class.
Base URL and Client Setup
Create the HttpClient and Jackson ObjectMapper once and reuse them.
Issue a Token by Logging In
Log in with your account to obtain an access token. Use data.user.accessToken from the response for subsequent requests.
Configure Authentication Headers
This helper creates a request builder containing the token and workspace ID. Reuse it for all subsequent calls.
If the token expires, obtain a new token using POST /api/auth/refresh-token (header X-Refresh-Token) or GET /api/auth/get-token, then set it again.
Create a 1:1 Transfer
This is the core flow for sending files directly from the source device to the target device.
Check the Source and Target Devices
Use GET /api/device to retrieve the device list and identify the deviceId of the device that will send the files (source) and the device that will receive them (target).
Check Connectivity
Checking that both the source and target devices are online before starting the transfer can reduce failures.
Browse the Source Path
Skip this step if the file path to be sent is already known in the code. If the path needs to be found dynamically, browse the path on the source device.
Specify the Target Path
Specify the target storage path as a plain-text absolute path based on the target device.
For Windows paths, it is safer to use forward slashes (/) instead of backslashes (\).
Create the Transfer
Create the transfer using the source/target deviceId, the file paths to send, and the target storage path (targetPath). Save the monitorId from the response because it is used for subsequent control and monitoring.
Request body fields: sourceId (sending device), targetId (receiving device), targetPath (storage path on the target device), sourceItem (list of files/folders to send — specifying a folder path also transfers its contents).
Check Transfer Status
Poll the progress periodically using monitorId. Wait until the transfer is completed or fails.
After completion, retrieve the detailed result with GET /api/transfer-history/{monitorId}/detail?idType=monitor and file-level results with GET /api/transfer-history/{monitorId}/get-files?idType=monitor.
The exact status strings (
completed, etc.) may vary depending on the environment, so check the actual response logs before finalizing the termination conditions.
Transfer Control
Control an in-progress transfer using monitorId.
Pause · Resume · Cancel
All three actions use PATCH requests with no request body.
Pass one of pause, resume, or cancel as the action.
Retry Failed Files
If some files fail during the transfer, retry only the failed files.
Complete Example
This is a minimal executable example that combines login, transfer creation, and status polling. For actual integration, enhance token renewal, error handling, and retries as appropriate for your environment.
Automation
For scheduled transfers that run repeatedly at a specified time, use the automation endpoint instead of the one-time manualTransfer. The field structure differs from an immediate transfer, so first check the differences below.
| Item | Immediate transfer (manualTransfer) | Scheduled transfer (automation) |
|---|---|---|
| Source/target fields | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (object array) | ["...", "..."] (string array) |
| Execution | Once immediately | Repeated according to schedule |
Configure the Schedule
Define the execution cycle. Use hour and minute for the execution time, timezone for the reference time zone, and startDate and endDate for the validity period.
type is day (every day), hour and minute specify the execution time (for example, 09, 30), timezone specifies the reference time zone (for example, Asia/Seoul), and startDate and endDate use ISO 8601 UTC format (for example, 2026-01-01T00:00:00.000Z).
Create an Automation
Create an automation containing the schedule and transfer details (details). Use the automationId from the response for subsequent updates, deletion, and control.
Example:
Automatically Generate an Automation Name
If you do not want to specify a name manually, the server can generate one.
Pause · Resume Automation
Use the pause value to stop or restart the automation.
Update · Delete Automation
Change the schedule or transfer details, or remove the automation.
Retrieve the automation's progress and status with GET /api/automation/{automationId}/details.
Common Issues
| Symptom | Cause · Solution |
|---|---|
401 Unauthorized | Token expired or header missing. Refresh the token with refresh-token and reset accessToken. |
| Transfer does not start | Source/target device is offline. Check whether both devices are online with connectivity. |
| File is saved in the wrong location | Check that targetPath is an absolute path based on the target device. |
| Source file cannot be found | sourceItem path is not an absolute path based on the source device. Check the actual path with fileSearchV3. |
| Only some files fail | Retry only the failed files with retry-failed-files. |
Development Resources and Examples
Code examples and documentation required for transfer integration are available on INNORIX GitHub, and the complete endpoint specification is available in the Swagger documentation.
C#
Create the code step by step to create, monitor, and control a 1:1 transfer by calling the API from a C#/.NET application between two already registered devices.
Device registration is assumed to be complete (the source and target devices are displayed in the device list). Always check the Swagger documentation for the exact endpoint schema.
This example is based on .NET 8 and uses HttpClient and the built-in System.Net.Http.Json. PatchAsJsonAsync is available in .NET 7 and later.
Common Setup
First, configure a reusable client and authentication headers for all requests. The methods in each subsequent step belong to this ExacoolaClient class.
Base URL and Client Setup
Create the HttpClient once with BaseAddress and reuse it.
Issue a Token by Logging In
Log in with your account to obtain an access token. Use data.user.accessToken from the response for subsequent requests.
Configure Authentication Headers
Add the token and workspace ID to the HttpClient default headers so you do not need to specify them repeatedly for each request.
If the token expires, obtain a new token using POST /api/auth/refresh-token (header X-Refresh-Token) or GET /api/auth/get-token, then set it again.
Create a 1:1 Transfer
This is the core flow for sending files directly from the source device to the target device.
Check the Source and Target Devices
Use GET /api/device to retrieve the device list and identify the deviceId of the device that will send the files (source) and the device that will receive them (target).
Check Connectivity
Checking that both the source and target devices are online before starting the transfer can reduce failures.
Browse the Source Path
Skip this step if the file path to be sent is already known in the code. If the path needs to be found dynamically, browse the path on the source device.
Specify the Target Path
Specify the target storage path as a plain-text absolute path based on the target device.
For Windows paths, it is safer to use forward slashes (/) instead of backslashes (\).
Create the Transfer
Create the transfer using the source/target deviceId, the file paths to send, and the target storage path (targetPath). Save the monitorId from the response because it is used for subsequent control and monitoring.
Request body fields: sourceId (sending device), targetId (receiving device), targetPath (storage path on the target device), sourceItem (list of files/folders to send — specifying a folder path also transfers its contents).
Check Transfer Status
Poll the progress periodically using monitorId. Wait until the transfer is completed or fails.
After completion, retrieve the detailed result with GET /api/transfer-history/{monitorId}/detail?idType=monitor and file-level results with GET /api/transfer-history/{monitorId}/get-files?idType=monitor.
The exact status strings (
completed, etc.) may vary depending on the environment, so check the actual response logs before finalizing the termination conditions.
Transfer Control
Control an in-progress transfer using monitorId.
Pause · Resume · Cancel
All three actions use PATCH requests with no request body.
Pass one of pause, resume, or cancel as the action.
Retry Failed Files
If some files fail during the transfer, retry only the failed files.
Complete Example
This is a minimal executable example that combines login, transfer creation, and status polling. For actual integration, enhance token renewal, error handling, and retries as appropriate for your environment.
Automation
For scheduled transfers that run repeatedly at a specified time, use the automation endpoint instead of the one-time manualTransfer. The field structure differs from an immediate transfer, so first check the differences below.
| Item | Immediate transfer (manualTransfer) | Scheduled transfer (automation) |
|---|---|---|
| Source/target fields | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (object array) | ["...", "..."] (string array) |
| Execution | Once immediately | Repeated according to schedule |
Configure the Schedule
Define the execution cycle. Use hour and minute for the execution time, timezone for the reference time zone, and startDate and endDate for the validity period.
type is day (every day), hour and minute specify the execution time (for example, 09, 30), timezone specifies the reference time zone (for example, Asia/Seoul), and startDate and endDate use ISO 8601 UTC format (for example, 2026-01-01T00:00:00.000Z).
Create an Automation
Create an automation containing the schedule and transfer details (details). Use the automationId from the response for subsequent updates, deletion, and control.
Example:
Automatically Generate an Automation Name
If you do not want to specify a name manually, the server can generate one.
Pause · Resume Automation
Use the pause value to stop or restart the automation.
Update · Delete Automation
Change the schedule or transfer details, or remove the automation.
Retrieve the automation's progress and status with GET /api/automation/{automationId}/details.
Common Issues
| Symptom | Cause · Solution |
|---|---|
401 Unauthorized | Token expired or header missing. Refresh the token with refresh-token and call SetAuth() again. |
| Transfer does not start | Source/target device is offline. Check whether both devices are online with connectivity. |
| File is saved in the wrong location | Check that targetPath is an absolute path based on the target device. |
| Source file cannot be found | sourceItem path is not an absolute path based on the source device. Check the actual path with fileSearchV3. |
| Only some files fail | Retry only the failed files with retry-failed-files. |
Development Resources and Examples
Code examples and documentation required for transfer integration are available on INNORIX GitHub, and the complete endpoint specification is available in the Swagger documentation.
curl
Organize step by step how to create, monitor, and control a 1:1 transfer by calling the API with curl between two already registered devices.
Device registration is assumed to be complete (the source and target devices are displayed in the device list). Always check the Swagger documentation for the exact endpoint schema.
curl is provided by default in most environments. The complete example script requires jq for JSON parsing (sudo apt install jq or brew install jq).
Common Setup
First, configure the variables and authentication headers to reuse for all subsequent requests. (The examples below assume they are executed in a single shell session.)
Base URL and Variable Setup
Set the Base URL and workspace ID as shell variables.
Issue a Token by Logging In
Log in with your account to obtain an access token. Store data.user.accessToken from the response in a variable for subsequent requests.
Configure Authentication Headers
Creating the authentication headers as an array allows you to reuse them in all subsequent requests with "${AUTH[@]}".
If the token expires, obtain a new token using POST /api/auth/refresh-token (header X-Refresh-Token) or GET /api/auth/get-token, then set it again.
Create a 1:1 Transfer
This is the core flow for sending files directly from the source device to the target device.
Check the Source and Target Devices
Use GET /api/device to retrieve the device list and identify the deviceId of the device that will send the files (source) and the device that will receive them (target).
Check Connectivity
Checking that both the source and target devices are online before starting the transfer can reduce failures.
Browse the Source Path
Skip this step if the file path to be sent is already known. If the path needs to be found dynamically, browse the path on the source device.
Specify the Target Path
Specify the target storage path as a plain-text absolute path based on the target device.
For Windows paths, it is safer to use forward slashes (/) instead of backslashes (\).
Create the Transfer
Create the transfer using the source/target deviceId, the file paths to send, and the target storage path (targetPath). Save the monitorId from the response because it is used for subsequent control and monitoring.
Request body fields: sourceId (sending device), targetId (receiving device), targetPath (storage path on the target device), sourceItem (list of files/folders to send — specifying a folder path also transfers its contents).
Check Transfer Status
Check the transfer status using monitorId. Poll periodically until it is completed or fails.
After completion, retrieve the detailed result with GET /api/transfer-history/{monitorId}/detail?idType=monitor and file-level results with GET /api/transfer-history/{monitorId}/get-files?idType=monitor.
The exact status strings (
completed, etc.) may vary depending on the environment, so check the actual response before finalizing the termination conditions.
Transfer Control
Control an in-progress transfer using monitorId.
Pause · Resume · Cancel
All three actions use PATCH requests with no request body.
Pass one of pause, resume, or cancel as the action.
Retry Failed Files
If some files fail during the transfer, retry only the failed files.
Complete Example
This is a minimal executable script that combines login, transfer creation, and status polling. For actual integration, enhance token renewal, error handling, and retries as appropriate for your environment. (jq is required for JSON parsing.)
Automation
For scheduled transfers that run repeatedly at a specified time, use the automation endpoint instead of the one-time manualTransfer. The field structure differs from an immediate transfer, so first check the differences below.
| Item | Immediate transfer (manualTransfer) | Scheduled transfer (automation) |
|---|---|---|
| Source/target fields | sourceId / targetId | senderId / receiverId |
sourceItem | [{"filePath": "..."}] (object array) | ["...", "..."] (string array) |
| Execution | Once immediately | Repeated according to schedule |
Configure the Schedule
Define the execution cycle with the schedule object. Use hour and minute for the execution time, timezone for the reference time zone, and startDate and endDate for the validity period.
Create an Automation
Create an automation containing the schedule and transfer details (details). Use the automationId from the response for subsequent updates, deletion, and control.
Automatically Generate an Automation Name
If you do not want to specify a name manually, the server can generate one.
Pause · Resume Automation
Use the pause value to stop or restart the automation.
Update · Delete Automation
Change the schedule or transfer details, or remove the automation.
Retrieve the automation's progress and status with GET /api/automation/{automationId}/details.
Common Issues
| Symptom | Cause · Solution |
|---|---|
401 Unauthorized | Token expired or header missing. Run the login step again to refresh ACCESS_TOKEN and AUTH. |
| Transfer does not start | Source/target device is offline. Check whether both devices are online with connectivity. |
| File is saved in the wrong location | Check that targetPath is an absolute path based on the target device. |
| Source file cannot be found | sourceItem path is not an absolute path based on the source device. Check the actual path with fileSearchV3. |
| Only some files fail | Retry only the failed files with retry-failed-files. |
Development Resources and Examples
Code examples and documentation required for transfer integration are available on INNORIX GitHub, and the complete endpoint specification is available in the Swagger documentation.