disk.file.upload

What disk.file.upload does

Puts documents into Bitrix24 Drive programmatically — contracts from generators, KYC documents from portals, call recordings, invoices from ERP. Usually paired with attaching the file to a CRM record.

Business use cases

• Generated contracts/invoices stored on the deal
• KYC/document-collection portals feeding applicant files into CRM
• Archiving external attachments (portal lead documents, email attachments)
• Recording files attached where telephony providers deliver them separately

Typical fields and parameters

• id (folder) — Target folder ID — discover via disk.storage.getlist and disk.folder.getchildren
• data[NAME] — Filename including extension
• fileContent — Base64-encoded content for direct upload (fine for documents; use the two-step upload URL flow for large files)
• generateUniqueName — true to avoid collisions instead of erroring

Example workflow

1. Contract generator produces order-8842.pdf
2. disk.folder.uploadfile into the 'Contracts/2026' folder with base64 content
3. Returned file ID set on the deal's file-type custom field via crm.deal.update
4. disk.file.getExternalLink generates a share link posted to the timeline for one-click access

Example request

POST .../disk.folder.uploadfile.json

{
  "id": 3312,
  "data": { "NAME": "order-8842-contract.pdf" },
  "fileContent": ["order-8842-contract.pdf", "JVBERi0xLjcKJc... (base64)"],
  "generateUniqueName": true
}

Example response

{
  "result": {
    "ID": "9917", "NAME": "order-8842-contract.pdf",
    "SIZE": "182344", "DOWNLOAD_URL": "https://...",
    ...
  },
  "time": { ... }
}

Field mapping notes

• Attaching to CRM: file-type custom fields accept uploaded file references; check the exact expected format for your field via crm.deal.fields — it differs from a bare Drive ID in some flows
• Folder structure is API-discoverable but portal-specific — resolve paths by walking disk.storage.getlist → getchildren, don't hardcode IDs across portals
• Base64 inflates payloads ~33%; large recordings belong in the upload-URL flow, not inline

Security notes

• External links (getExternalLink) are public URLs — generate them only for documents that may leave the org, and prefer expiring/internal sharing where possible
• Uploaded files inherit folder permissions — put client documents in folders scoped to the right teams

Common errors

• 413 / payload too large — Inline base64 for a big file — switch to the two-step upload flow or chunking
• File uploaded but not on the deal — Setting a file field requires the field's expected reference format, not just the Drive ID — verify against the field definition
• 'Folder not found' — Hardcoded folder ID from another portal/environment — resolve dynamically

Production implementation tips

• Create a dated folder convention (Contracts/2026/07) programmatically — flat thousand-file folders make Drive unusable
• Store the Drive file ID in your system next to the source document ID for reconciliation
• Virus-scan user-submitted files before uploading them into the company Drive

Webhook or OAuth app?

Document flows often carry sensitive content — the token hygiene of an OAuth app is worth it for portals handling client uploads; internal generators can use scoped webhooks.

Full decision guide: webhook vs OAuth app in Bitrix24.

When to use a queue worker

Uploads are slow calls; never do them inline in a user request. Queue with generous timeouts and resumable retries.

How Tech Titan can help

Tech Titan builds production Bitrix24 integrations around disk.file.upload and its siblings — with authentication, field mapping, queue workers, retry logic, duplicate handling, and structured logs as standard. If this method is on your critical path, bring the requirement to a free audit call and leave with an architecture sketch.