← All posts

From a folder to a posted video, without touching an API

9 min read

The job, as people state it: anything I drop in this folder should go up on phone 3.

Anyone who has built this in n8n or Zapier knows the shape of the disappointment. The workflow is easy right up to the final node — the one that actually posts — and that node needs an API you probably cannot get. Instagram publishing wants a professional account linked to a Facebook Page. LinkedIn's company-page API is for registered organisations. TikTok forces every post from an unaudited client to private, which looks exactly like success and is seen by nobody.

NOISEY's last mile is a handset instead of an API client. This post is the whole loop, including the parts that do not exist yet.

Three words, kept apart

Tools in this space become unusable the moment these blur, so NOISEY keeps them separate and so does this post:

There is no fourth word. The docs say the same thing, and the reason they bother is that “post what lands in this folder” should never require drawing a diagram.

The loop, end to end

Three steps to build it: make a folder, point an automation at it, and choose the routine and the phones. If you pick more than one phone you also set the seconds between them, which is the only number in the whole setup with an opinion attached.

One line, left to right: files arrive through one of two doors, land in a named queue, and an automation turns each arrival into one job per phone — spaced, so twenty uploads do not leave the building at once.

Two doors, not four

Most write-ups of this pattern list four ways to get a file in. NOISEY has two, and being straight about that is more useful than padding the list.

Your webhook. One URL for the account; the request names the folder. Anything that can POST a file speaks it — n8n, Zapier, Make, a render pipeline, a shell script:

curl -X POST \
  -H "content-type: video/mp4" \
  -H "x-filename: sunrise-take-1.mp4" \
  --data-binary @sunrise-take-1.mp4 \
  "https://api.noisey.app/webhooks/media/<your-token>?folder=Morning posts"

The bytes are the raw body, streamed, so a long video is fine. x-filename is optional and a timestamped name is invented without it. ?folder= (or an x-folder header) takes a folder name, an id, or a path like Clients/Acme.

A watched Google Drive folder. Point NOISEY at it and new videos are pulled in server-side, landing in the NOISEY folder you chose and triggering automations exactly like a webhook arrival.

There is deliberately no upload button. NOISEY is plumbing between where videos are made and the phone that posts them, and a drag-and-drop box would make it look like storage, which it is not — on the free plan a file lives 24 hours from upload.

Seconds between phones, and the word this industry ruined

When an automation fires on a group, each phone's job is scheduled a fixed number of seconds after the previous one. The default is 2.

It is worth being explicit about why, because “delay” and “stagger” have been thoroughly poisoned by tools that sell randomised timing as a way to look human. That is not what this is. Twenty phones uploading simultaneously through one computer and one upstream connection is a self-inflicted traffic jam; the spacing is a courtesy to your own bandwidth and your own machine, nothing more. There is no control that randomises it, no jitter, and no per-phone variation — because a knob like that only makes sense if the goal is not being recognised, and that is not a goal NOISEY has.

The spacing is also per phone, which took a bug to learn. It used to accumulate across the whole file × phone loop, so thirty files across twenty phones pushed the last job twenty minutes out at the 2-second default. A phone's second job needs no spacing at all, because one job at a time per handset is already enforced further down.

Two locks, because posting twice is the failure that matters

Every other failure in this system is recoverable. Posting the same video to a client's account twice is not, and it is exactly what a retrying pipeline or a re-syncing Drive folder will try to do at three in the morning.

The first lock recognises the same bytes; the second recognises the same piece of work. Note which statuses do not block: a failed or missed job means the post never happened, so it stays retryable.

The first lock is content. Files are fingerprinted by their bytes. A file NOISEY has already seen in that folder is recognised rather than re-ingested — the webhook answers "deduped": true and fires nothing. Genuinely new content, down to a single changed frame, is a new file and triggers normally.

The check is scoped to the folder, not the account, and that is deliberate: the same clip placed in two folders on purpose is two pieces of scheduling, and deduplicating across folders would silently merge them.

The second lock is the job. Every job is keyed by automation × file × phone. A combination that already has a queued, dispatched, running or succeeded job is skipped — by a webhook arrival and by Run now alike. The exception is stated last because it is the one that matters: a failed job may be retried, because the post never happened.

What happens when the Mac is asleep

NOISEY's servers never touch a phone. They cannot: the phones are plugged into your machine, so the desktop app is always the thing doing the work. A job leaves the server only when three things are true at once — it is due, the machine that phone belongs to has the desktop app connected, and that phone has nothing else running. The last of those is a unique index in the database rather than a check in code, because a dispatcher restarting mid-flight would otherwise interleave two runs on one handset.

Take the server away and the right-hand half is untouched: the phones are in the room and driving them needs nothing but the cable. What pauses is arrival, queueing and dispatch — visibly, behind a banner, never silently.

Jobs triggered by an arrival wait indefinitely. Open the app tomorrow and they run. Jobs from a schedule are different: they carry a start window, and one that is still queued when the window closes is marked missed rather than dispatched late. A 09:00 post going out at 14:37 because a laptop lid was shut is worse than not posting, and Activity says so in those words.

With no connection at all, the desktop app shows a banner and keeps going: mirroring, tapping, typing, running a routine by hand on the phones in front of it. A server outage should never brick a rack that needs no server to function. The docs commit to this.

What this does not do

The list matters more than the feature tour, because everything above is only believable if this part is honest.

Who this is not for

If the goal is twenty accounts that read as twenty unrelated strangers, NOISEY is the wrong tool and nothing here will help. It does not spoof device identifiers, rotate proxies, or register accounts, and it never will. The whole design assumes the opposite premise: these are real accounts belonging to real people who registered them, on phones you or your client own. That trade-off has its own post.

And if the API route is open to you, take it. One brand, one professional account, predictable volume — an API is more reliable than any UI automation and always will be. What each posting API will and will not let you do is the honest comparison, and TikTok's audit gate is the specific one people hit first.

The interesting case is the one in between: the logic belongs in a tool you already run, and only the last mile is missing. That handoff — n8n keeps the decisions, a phone does the posting — is the shortest version of everything above.

Read the docs →