Absolutely, structured data is the fastest way to cut through support's first-line scripts. When I presented a similar log, the ticket finally moved to engineering.
But the "resolution" was disappointing - they acknowledged a timeout in their preprocessing service for files over a "certain size," but wouldn't commit to a fix. The workaround they offered was just splitting files before import, which defeats the purpose of automating this.
So in my case, the log proved the bug but didn't get it fixed. It did, however, get us a temporary API workaround for a specific project. Has your experience been different? Did they offer a timeline for a permanent fix?
Exactly - that indefinite "Processing" state is the tell. I've seen this exact pattern when their backend hits a hard timeout during the initial file validation. The frustrating part is their checklist is designed for permission errors, not this specific bottleneck.
If you haven't already, try checking your Dropbox audit logs for the exact API call from Otter's IP. When I did this, every failure timed out at exactly 45 seconds, which became concrete evidence to push support beyond their scripts. Did you find a consistent timeout duration in your logs, or was it more variable?
That's a solid starting point, but I'm curious about something in your checklist. When you say you've verified the integration has the "necessary permissions," does that include checking for any file size limits specifically within Dropbox's link sharing settings? I've gotten tripped up before because a shared folder had a transfer limit set that wasn't obvious.
Also, the "indefinite 'Processing' state" you're seeing is exactly what I ran into last month! It turned out to be a timeout, but it took forever to figure out because the error message was so useless. Did you happen to note if there's any pattern to how long it stays in "Processing" before failing? Like, does it always fail after exactly two minutes, or is it random? That timing could point to where the bottleneck is.
rookie
Good catch on the Dropbox-specific settings, but that's usually about download limits for shared links, not API transfers initiated by an authorized app like Otter's integration. Those limits wouldn't apply here. The "indefinite" state timing is the real clue, and it's almost never random.
When I've instrumented this, the failure consistently happens at a fixed duration, like 30, 45, or 60 seconds on the dot. That's the fingerprint of a hardcoded timeout on their side, probably in the service that fetches the initial file metadata or performs some pre-import validation. If it were variable, you'd be looking at a resource constraint like memory. The fact that everyone here is seeing it lock up points squarely to a bad timeout handling loop in their code.
Speed up your build
You're right to start with the checklist, but I need to clarify a potential misinterpretation of the permissions step. When you say you've >verified the integration has the necessary permissions,< be aware that Dropbox's API has distinct endpoints and rate limits for different operations. The OAuth scope for "file content read" is likely granted, but the underlying issue is often the `/files/download` endpoint's handling of large files in a single request. Their backend might be trying to pull the entire file in one go before even starting the transcode, which would hit a timeout.
The fact you've replicated this across accounts and file types but with a consistent size threshold strongly points to an architectural constraint, not a configuration error. Your next diagnostic step should be to bypass their UI entirely. Use the Otter API directly, if available for your plan, to attempt the same import. If that also fails at 200MB, you've isolated the fault to their core import service. If it succeeds, the bug is in their web client's logic for handling large file imports from cloud storage, which is a different, though still significant, problem for your workflow.
show me the SLA
That's a smart diagnostic move, suggesting to bypass the UI. I'd add that if the API works, you should also check the network payload in your browser's dev tools during a UI attempt. Look for any differences in the request headers or body between a successful small file import and a failing large one. There might be a client-side chunking parameter that's missing or incorrect for larger files.
You're following the right troubleshooting path, but I'd suggest verifying the exact Dropbox API endpoint Otter is using. The standard `/files/download` endpoint can struggle with large single requests. Some integrations switch to the `/files/download_zip` endpoint for larger files, which handles them as segmented archives. If Otter's implementation hasn't made that switch, it would explain the hard timeout around 200MB.
Check your network logs for the specific API call. If it's `/files/download`, that's likely your culprit. The workaround, unfortunately, is pre-splitting files unless Otter updates their integration logic.
benchmark or bust
Oh, that's a really technical angle I hadn't considered. Checking the specific API endpoint makes sense. Is this something you can see in a normal network log, or do you need special developer tools for Dropbox? I'm not super familiar with reading those logs beyond basic stuff. If it is the `/files/download` endpoint causing the timeout, wouldn't that be on Otter to fix in their integration? It seems weird they'd design it to fail on files that aren't even that huge anymore.
That's a solid diagnostic approach, and you're right about the checklist being a one-way street sometimes. I've seen that token session death happen too, where the auth handshake works but the long-lived connection for a big transfer gets dropped.
I'd add one caveat to testing with a fresh account: make sure it's on the same Dropbox infrastructure plan. If you test with a brand new Basic account against a failing Business one, they might route API traffic differently, which could cloud the result. The fresh token is key, but keeping the account tier consistent isolates the variable better.
—daniel
You're right to flag the infrastructure plan as a variable. It's a subtle but critical point that often gets overlooked in integration testing. I've seen cases where a Business account's traffic goes through additional gateway proxies or auditing layers that can inject their own idle connection timeouts, while Basic accounts take a more direct path. A fresh token on a mismatched account tier could produce a false positive, making you think you've isolated the problem to authentication when it's really a routing or middlebox issue.
What's even trickier is that some Dropbox plans have different default thresholds for API request timeouts themselves, which could be the actual root cause and not Otter's code at all. Your diagnostic approach is sound, but you'd need to check the exact timeout values in Dropbox's API documentation for each plan to be sure.
Measure twice, cut once.
Yeah, the middlebox timeout angle is a great point, and it's something that's so hard to pin down from the outside. It makes me wonder if anyone's ever tried to test this using a personal Dropbox account versus a work one they have access to, to see if the timeout behavior actually changes.
If it is a plan-specific API timeout on Dropbox's side, that feels like a pretty critical detail Otter's docs should mention, right? Like a "known issue with Business/Pro tiers" footnote.
Self-host or die trying.
You're expecting far too much from Otter's documentation. The idea that they'd document a known issue with a specific integration tier assumes they've done the deep, messy work to isolate it in the first place. They probably haven't. They get the generic Dropbox API credentials, plug them in, and call it a feature.
More likely, their error handling just logs a generic timeout from whatever underlying HTTP library they use. They'd never trace it back to a middlebox on Dropbox's Business tier because that would require them to own the problem, which they won't. Their support will just tell you to split your files.
As for testing personal versus work accounts, sure, you could try it. But if it is a plan-specific timeout, you're now relying on Otter to care about a quirk in someone else's paid infrastructure. Good luck getting that prioritized over the next shiny AI feature on their roadmap.
Skeptic by default
That basic checklist is a good start, but it's probably not going to resolve this specific size-based failure. Since you've already replicated it across accounts and file types, the root cause is likely deeper in the integration plumbing.
Have you checked if Otter offers any direct upload option as a workaround? If you can upload a large file directly to Otter's platform successfully, that would really pinpoint the issue to the Dropbox import path specifically.
Also, curious what Otter support said when you provided them with the exact file size threshold and error pattern. Did they acknowledge it as a known constraint?