Uploading Source Files

If a task expects a file, the API payload does not accept file content in Base64 form. For file fields, use one of these approaches:

• url — a public http/https URL that Problembo can download itself
• fileId — an identifier of a file that you uploaded to Problembo File Store in advance

Option 1: pass a url

This is the simplest option if your file is already available by direct http/https link.

{
  "srcImage": {
    "url": "https://example.com/input/photo.png",
    "origFilename": "photo.png"
  }
}

When you submit the task, Problembo downloads the file, uploads it to internal storage, replaces url with fileId, and then processes the task.

Option 2: upload the file yourself and use fileId

Use this flow for server-to-server integrations when the file is local, private, or you do not want Problembo to download it from a third-party URL.

This upload flow uses API token auth and the /apis/v1/client/files/* endpoints.

Step 1: request a presigned upload URL

curl 'https://problembo.com/apis/v1/client/files/upload-url-for-src' \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -d '{
    "origFileName": "photo.png",
    "fileSizeBytes": "2458123"
  }'

Typical response for a regular single-part upload:

{
  "fileId": "910e1b85-4677-49d4-abd3-41218733ab60.png",
  "uploadUrl": "https://...",
  "contentDisposition": "inline; filename=photo.png",
  "origFileName": "photo.png"
}

Step 2: upload the binary file to uploadUrl

curl -X PUT 'UPLOAD_URL_FROM_STEP_1' \
  --upload-file ./photo.png

Step 3: confirm the upload

curl 'https://problembo.com/apis/v1/client/files/upload-complete' \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -d '{
    "fileId": "910e1b85-4677-49d4-abd3-41218733ab60.png"
  }'

Response:

{
  "remoteFile": {
    "fileId": "910e1b85-4677-49d4-abd3-41218733ab60.png"
  }
}

Step 4: use fileId in /apis/v1/client/tasks

{
  "srcImage": {
    "fileId": "910e1b85-4677-49d4-abd3-41218733ab60.png",
    "origFilename": "photo.png"
  }
}

Client upload-flow notes:

• forceRoute is not supported in the external client API
• there is no separate source-file download endpoint in v1
• any API token from the same Problembo account may reuse this fileId
• /apis/v1/client/tasks validates that every fileId belongs to the token owner and is already ACTIVE

Multipart uploads for large files

If step 1 returns multipartPlan, you must use multipart upload instead of a single PUT request.

In that case:

1. Upload each chunk to its own multipartPlan.parts[].uploadUrl
2. Collect etag values returned by S3-compatible storage
3. If needed, request refreshed presigned part URLs via /apis/v1/client/files/multipart-plan
4. Finalize the upload via /apis/v1/client/files/upload-multipart-complete

Example request to refresh the multipart plan for an expired part URL:

curl 'https://problembo.com/apis/v1/client/files/multipart-plan' \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -d '{
    "fileId": "910e1b85-4677-49d4-abd3-41218733ab60.mp4",
    "partNumbers": [2]
  }'

Example response:

{
  "uploadId": "upload-123",
  "partSizeBytes": "5242880",
  "parts": [
    {
      "partNumber": 2,
      "uploadUrl": "https://..."
    }
  ]
}

Example finalize request:

curl 'https://problembo.com/apis/v1/client/files/upload-multipart-complete' \
  -X POST \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_TOKEN' \
  -d '{
    "fileId": "910e1b85-4677-49d4-abd3-41218733ab60.mp4",
    "parts": [
      { "partNumber": 1, "etag": "etag-part-1" },
      { "partNumber": 2, "etag": "etag-part-2" }
    ]
  }'

{
  "remoteFile": {
    "fileId": "910e1b85-4677-49d4-abd3-41218733ab60.mp4"
  }
}

Which option should you choose?

• Use /apis/v1/client/files/* for server-to-server uploads authenticated by API token
• Use url if the file is already available by direct http/https link
• Use fileId if the file is local, private, large, or generated inside your own system
• Do not send Base64 file content inside the task payload

Last updated: March 8, 2026