Dropbox and CodeWords: automating without fighting the sync client
Why the API and the desktop client disagree, shared folder sprawl, external link hygiene, and building file automation that does not produce conflicted copies.
Rithul Palazhi11 min read
On this page
Dropbox is two products that happen to share storage. There is the sync client, which makes a folder on your machine mirror the cloud, and there is the API, which reads and writes files directly. Most file automation trouble comes from forgetting that people are using the first while your automation uses the second.
An automation writing to a folder that four people have synced is writing into a space where four machines are also making changes, and the conflicted copies that result are confusing for everyone.
What we'll cover
- The sync client and the API
- What the Dropbox API reaches
- Connecting it to CodeWords
- Seven automations worth building
- Shared folder sprawl
- Links to the outside world
- Building it so it survives
- Limits worth knowing about
- What to build first
- Frequently asked questions
The sync client and the API
Three consequences worth designing around.
Conflicted copies happen when two things write. If your automation modifies a file while somebody's client is uploading a change to the same file, Dropbox preserves both and names one as a conflicted copy. Nobody reads those, and they accumulate.
Sync is not instant. A file written by the API appears on synced machines after the client notices and downloads it, which depends on the client running and the machine being awake.
Local paths are not API paths. A path on somebody's machine and the path the API uses look similar and are not the same thing, particularly for shared folders and team spaces.
The practical rule: have your automation write into folders people do not edit directly, and read from folders they do. Where an automation must modify a shared working file, prefer writing a new version beside it over editing in place.
What the Dropbox API reaches
Files and folders can be listed, uploaded, downloaded, moved, copied, and deleted, with a proper folder structure rather than key prefixes.
Upload sessions handle large files in chunks, which anything accepting arbitrary uploads needs.
File metadata can be read without downloading, including size, type, and revision, which is the cheap way to decide whether to process something.
Revisions are retained, so previous versions can be listed and restored, which changes what a bad write means.
Shared links can be created with expiry, password, and access settings, and listed, which supports the hygiene reporting below.
Shared folders can be listed with their members, which is how you find out who has access to what.
File requests let people upload to you without a Dropbox account, which is a genuinely useful and underused intake mechanism.
Webhooks notify on changes in a connected account, which is what lets automation react rather than poll.
Connecting it to CodeWords
CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.
- Open CodeWords and start a new automation.
- Describe what should happen in plain language to Cody, the automation builder: which folder, what arrives, and what should happen to it.
- Authorize the connection with scoped access, preferring an app folder or a specific shared folder over full account access.
- Describe the exceptions: a file still uploading, a name that collides with an existing file, a folder somebody has since moved.
- Test in a folder nobody has synced before pointing anything at a shared working area.
You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.
Seven automations worth building
Intake processing. Files arriving in a watched folder validated, renamed to a convention, and filed into the right place. This is the most common useful automation and it removes the filing that otherwise never happens consistently.
File request handling. Collect documents from people outside your organization through a file request, then process what arrives — check it is complete, chase what is missing, file the rest. Better than email attachments in every respect.
Document generation into a delivery folder. Produce a report or a pack and place it where the client or the team expects to find it, named predictably.
Shared link auditing. List existing shared links, find the ones with no expiry and the ones pointing at sensitive material, and report them. Covered further below.
Shared folder membership reporting. Who has access to what, particularly external members, reported periodically for review.
Conflicted copy cleanup. Find files with conflicted-copy names, report them with their age, and let somebody decide. They accumulate silently and nobody goes looking.
Storage and growth reporting. Which folders are growing, what is consuming the allowance, and what has not been touched in years.
Shared folder sprawl
Dropbox makes sharing easy, which is the point and also the problem at organizational scale.
Folders shared with people who have left. Membership persists after somebody departs unless removed deliberately, and offboarding rarely covers it.
Nested sharing nobody can reason about. A folder shared with one group inside a folder shared with another produces an access picture nobody can describe from memory.
Personal accounts in business folders. Someone joined with their own account rather than the organization's, so the access does not disappear when their work account does.
Folders shared for a project that ended. Three years later the external collaborator still has access to something nobody thought about again.
Report all four quarterly. An automation that lists shared folders with their external members takes an afternoon and routinely finds things that make people uncomfortable, which is exactly why it is worth running.
Links to the outside world
Shared links are how files leave your organization, and they are easy to create and forget.
A link without expiry is permanent access. Anybody who ever receives it, or finds it forwarded, has the file indefinitely.
Set expiry by default in any automation creating links. Where a person creates one by hand they will not, which is the argument for having automation do it.
Audit existing links periodically. List them, sort by age, and report the old ones pointing at anything sensitive.
Password-protect anything consequential. Available on paid plans and rarely used.
Record what was shared with whom. When somebody asks whether a document went outside, the answer should be retrievable rather than a matter of recollection.
Building it so it survives
Make it safe to run twice. Webhooks retry. Uploading the same file twice produces either an overwrite or a duplicate depending on the mode you chose, so choose deliberately.
Wait for uploads to finish. A file that appears in a listing may still be uploading. Check the size against expectation or wait for a stable revision before processing.
Use file IDs rather than paths where you can. Paths change when people move things, and an automation navigating by path breaks the first time somebody reorganises.
Write outputs somewhere separate from inputs. Writing results back into a watched folder creates an automation that triggers itself.
Report the outcome. Files seen, processed, skipped, and anything quarantined.
Limits worth knowing about
Rate limits apply per user, and the API signals when to back off, which an automation should respect rather than retry immediately.
Large files need upload sessions, so anything handling arbitrary uploads must implement chunked transfer rather than assuming a single request.
Deleted files are recoverable for a period that depends on plan, which is helpful and not a substitute for logging what you removed.
Team folders and personal spaces behave differently, particularly around paths and permissions, and an automation written against one may not work against the other.
Webhook notifications say something changed rather than what, so the automation needs to list and compare to find out, which is a design consideration rather than a bug.
What to build first
The shared link and shared folder audit, read-only. It needs read access only, it takes an afternoon, and it almost always surfaces access that should have ended — a link with no expiry pointing at something sensitive, or an external collaborator on a project that closed two years ago.
Two habits make the difference. Report it to a person rather than revoking automatically, since some of what looks abandoned is genuinely in use. And run it quarterly rather than once, because access sprawl is not a thing you fix; it is a thing you keep tidy.
Frequently asked questions
Why am I getting conflicted copies?
Because your automation and somebody's sync client wrote to the same file close together. Write into folders people do not edit directly, or write a new version alongside rather than modifying in place. Conflicted copies are Dropbox preserving both changes rather than losing one, which is the right behaviour and produces clutter.
Should the automation work through the API or the sync folder?
The API, always. Reading and writing through a synced folder on some machine means the automation depends on that machine running, that client being healthy, and sync having completed, which is three failure modes you do not need.
How do I handle large files?
Use upload sessions to transfer in chunks, and check metadata before downloading anything so an unexpectedly large file produces a sensible rejection rather than an exhausted automation.
Can I collect files from people outside the organization?
Yes, through file requests, which let somebody upload without a Dropbox account and deposit into a folder you choose. It is better than email attachments for size, for organisation, and for not having documents scattered across an inbox.
How do I find out who has access to what?
List shared folders with their members and shared links with their settings. This is the audit worth running quarterly, and it reliably finds external collaborators from finished projects and links created years ago with no expiry.
Should automation delete files?
Rarely, and always with a log of what was removed. Dropbox retains deleted files for a period depending on plan, which is a safety net rather than a reason to be casual. Moving to an archive folder is usually the better pattern.
Why does my automation stop finding a file?
Somebody moved or renamed it. Use file IDs rather than paths wherever the API allows, since IDs survive both, and paths are exactly the kind of thing people tidy without telling anyone.
How do I handle files that arrive with inconsistent names?
Normalise at intake, into a convention that includes whatever makes the file findable later — client, date, document type. Renaming at intake is one step; reconstructing what a file is from a name like "final v3 (2)" eighteen months later is not.
Should automation manage shared folder membership?
Report rather than change, at least initially. Removing somebody's access automatically because they look inactive is how a person loses a folder they were about to use. A quarterly report with names against it gets the same result with nobody surprised.
Should the automation have full account access?
No. Use an app folder or scoped access to the specific shared folders it needs. Full account access means an automation that files invoices can also read everything else in the account, which is far more reach than the job requires and outlives the reason it was granted.
How do I handle files that need to reach a client?
Create a shared link with an expiry and record what was shared with whom. File requests work well in the other direction. What to avoid is emailing attachments, which fragments the record of what was sent and leaves you unable to answer that question later.
What is the most common mistake in file automation here?
Processing a file that is still uploading. It appears in the listing at partial size, the automation reads it, and the result is silently truncated. Check metadata for a stable size or wait for a settled revision before acting.