A shared Google Drive folder is a perfectly reasonable image intake system. People already know how to drag files into it, suppliers can upload without learning a new portal, and nobody has to explain an S3 bucket before lunch. The trouble starts when the folder becomes busy enough that “someone will clean those up later” stops being a plan.
The useful automation is not merely “new file, call API.” It has to tell source files from its own outputs, download the actual bytes behind a Drive file, survive duplicate trigger runs, preserve the original, and leave a failed image somewhere a human can find it. Otherwise the workflow looks magical for twelve test photos and becomes a small purple mystery box in production.
This guide uses Google Drive as the intake and delivery surface and the BackgroundErase API for processing. The same shape works in Make, Zapier, n8n, Apps Script, or a small worker. The buttons move around between tools; the file contract does not.
Workflow rule
Download the file, process it once, and write the result somewhere the trigger cannot see.
- Use separate Incoming, Processed, and Needs review folders.
- Treat the Drive file ID plus its version or modified time as the source identity.
- Send actual image bytes to
POST /v2; a Drive preview link is not an image upload. - Create the output first, then mark the source complete so a half-finished run can recover.
- Retry timeouts, 429s, and transient 5xx responses; route bad inputs to review.
01
Start with a folder contract
The easiest way to prevent loops is to make the folders express the workflow. Create one folder where people are allowed to drop originals, one folder for finished PNGs, and one folder for anything that needs attention. Do not upload the processed image beside the original if your trigger watches that same folder. That is how an innocent automation ends up removing the background from its own background-removed image until everyone goes home.
Incoming
Original uploads only. Give uploaders write access here and keep the trigger scoped to this exact folder ID.
Processed
Transparent PNG outputs with predictable names. The automation writes here; the intake trigger ignores it.
Needs review
Unsupported, corrupt, oversized, or visually risky sources. Keep the original and a readable failure note together.
Run log
A sheet, database table, or workflow data store keyed by source file ID and version. Folder color is not durable state.
Use file IDs internally, not names. Two people can upload IMG_4821.jpg, and one person can rename a file after processing. A Drive file ID stays useful through renames and moves. For an idempotency key, combine that ID with modifiedTime, a revision identifier when available, or a content hash if your automation tool can calculate one.
02
Trigger on a state change, not a vague folder scan
In a no-code tool, choose the most specific “new file in folder” trigger available and bind it to the Incoming folder ID. Add a filter immediately after the trigger: the item must be a file, must not be trashed, and must have an image MIME type you intend to process. Folder shortcuts, Google Docs, and half-completed uploads are not product photos just because they appeared in Drive.
Assume at-least-once delivery
A connector can replay a trigger after a timeout, a user can move a file out and back in, and a manual rerun can feed the same test item through again. Check the run log before spending an API call. “The trigger only fires once” is a hope, not an idempotency strategy.
If you build directly against Drive, Google supports push notifications for the files and changes resources. The notification is a prompt to inspect Drive state, not a parcel containing the image itself. Notification channels also need lifecycle management, so a scheduled reconciliation scan is still useful. Google documents the current behavior in its Drive push notification guide.
Filter before processing
- MIME type starts with
image/, with an explicit allowlist if the downstream workflow is narrower. - File is inside the intended Incoming folder, not merely somewhere under a broad shared drive.
- Idempotency key is not already marked
processingorcomplete. - File size and known dimensions are within the processor contract.
- The item is not a shortcut, native Workspace document, or the workflow’s own output.
03
Get the real image bytes out of Drive
Google Drive exposes several things that look like links. A browser preview URL opens a Drive page. A sharing URL may require cookies or permission. A webContentLink can be useful for a signed-in browser. None of those should be confused with the actual JPEG or PNG body your processor needs.
The most reliable path is to use the connector’s “download file” action and pass its binary output to the next step. With the Drive API, blob files are downloaded with files.get and alt=media. Google Workspace-native documents use an export operation instead, although those are usually inputs you should reject in this workflow. The current methods and permission checks are covered in Google’s download and export documentation.
Drive API binary download
curl -L \
"https://www.googleapis.com/drive/v3/files/FILE_ID?alt=media" \
-H "Authorization: Bearer $GOOGLE_ACCESS_TOKEN" \
--output source-image.jpg403 from Drive
The connected account cannot download the file, the shared-drive permission is wrong, or downloading has been restricted. Retrying with the same credential will not negotiate better access.
HTML instead of an image
A preview or sign-in page was fetched. Inspect Content-Type and the first bytes before handing the body to the image API.
Zero-byte or changing file
The trigger arrived before the upload settled. Re-read metadata after a short bounded delay and require a nonzero, stable size.
Shared-drive surprise
The automation credential can see metadata but not download content. Test with the exact connected account, not your personal browser session.
04
Send the binary file to BackgroundErase
Once the workflow has bytes, call POST https://api.backgrounderase.com/v2 as multipart form data. Put the downloaded binary in the image_file field, send the API key in x-api-key, and request PNG plus RGBA when the destination needs a transparent cutout. Keep that key in the automation platform’s credential store, not in a Drive sheet named “DO NOT SHARE.”
BackgroundErase multipart request
curl -f "https://api.backgrounderase.com/v2" \
-H "x-api-key: $BACKGROUNDERASE_API_KEY" \
-F "[email protected]" \
-F "format=png" \
-F "channels=rgba" \
-F "size=full" \
--output cleaned-image.pngConfigure the HTTP step to return a file or binary body. A successful multipart request returns image bytes, not a friendly JSON object with a permanent download URL. Check the HTTP status and Content-Type before naming the response .png. Saving an error page as product-clean.png is the sort of bug that survives until a merchant opens the folder.
Use an API plan for the folder automation
Starter is the manual Studio plan; an automated Drive folder needs Business or Enterprise API access. Count one metered image for each unique source you process, then suppress replayed Drive triggers before they create duplicate work. See current pricing when estimating the folder’s volume.
05
Write the output without losing the source
Upload the returned binary to the Processed folder as a new file. Do not overwrite or delete the original during the same first-pass run. Originals are useful for reprocessing, debugging, and the inevitable request for a white-background JPEG three weeks after everyone agreed on transparent PNG.
Suggested run record
{
"sourceFileId": "1gDriveFileId",
"sourceModifiedTime": "2026-07-11T15:04:20.000Z",
"idempotencyKey": "1gDriveFileId:2026-07-11T15:04:20.000Z",
"status": "complete",
"outputFileId": "1gProcessedPngId",
"outputName": "sku-1842-background-removed.png",
"attempts": 1
}The safe commit order is: claim the idempotency key, download and process, upload the output, verify the new Drive file ID, then mark the run complete. If the workflow dies after upload but before the final state update, the retry should search for the recorded output name or processing token before uploading a duplicate. Exactly-once behavior usually comes from careful bookkeeping, not from a checkbox labeled “run once.”
Useful output metadata
- Source file ID, source name, MIME type, size, and modified time.
- Output file ID, output folder ID, and deterministic output name.
- Processor options such as format, channels, size, crop, and background color.
- Attempt count, last HTTP status, request ID when available, and completion timestamp.
- A link back to the original so reviewers do not have to search the folder tree.
06
Make failure states visible
No-code platforms are very good at showing a green check beside the last node that ran. That is not the same as proving the catalog received a usable image. Define failure states in the run log and make the final upload step part of success. If processing worked but Drive rejected the upload, the job is still incomplete.
| Failure | Action | Final state |
|---|---|---|
| Drive 403 or restricted download | Do not retry blindly; fix permission or ownership | Needs review |
| Unsupported or corrupt image | Keep original and record processor message | Needs review |
| 429 from image API | Honor Retry-After; retry with jitter | Queued |
| Timeout or transient 5xx | Retry a small number of times | Queued, then failed |
| Output upload conflict | Look up deterministic output before creating another | Verify or retry |
| Duplicate trigger | Return the existing output from the run log | Complete |
Permanent input and permission failures need a human. Network and service failures deserve bounded retries, not an indefinite replay loop.
Keep a reconciliation pass
Once or twice a day, compare eligible files in Incoming with completed run records. This catches expired trigger connections, disabled scenarios, files uploaded during maintenance, and runs that died between output upload and state update. Reconciliation is simple, explicit, and very good at finding what triggers missed.
07
Know when Drive has done enough
Drive is excellent for human-operated intake and modest ongoing volume. It becomes less charming when thousands of files arrive at once, several workers scan the same folder, or the business needs a strict processing SLA. At that point, keep Drive as the human-facing drop zone if people like it, but copy new files into object storage and put durable jobs on a queue.
Stay no-code
Good for supervised folders, modest batches, straightforward routing, and a team that wants to inspect every output in Drive.
Add a small worker
Useful when you need content hashing, stronger locks, custom backoff, structured logs, or exact control over binary streaming.
Move to a queue
Best when uploads are continuous, backlogs matter, multiple workers run, and completion needs to survive any one automation execution.
Keep Drive as the front door
The team can keep dropping files into a familiar folder while durable storage and job state live somewhere built for machines.
A solid first version is deliberately small: one intake folder, one output folder, one review folder, one run record per source version, and one bounded retry policy. That is enough structure to automate real work without pretending Google Drive is a message queue wearing a nice blue icon.
The practical version
Let Drive handle people. Let the workflow handle state.
The folder is the interface, not the database. Once the automation records source identity, moves real bytes, verifies the image response, and commits a durable output ID, the workflow becomes easy to operate instead of merely easy to demo.
Open the API docs