← All posts

n8n can't reach your phone. Here's the handoff.

7 min read

n8n is very good at deciding things. It will watch a Drive folder, branch on a field, call three APIs, retry the one that timed out and fan the result into a spreadsheet, all without you writing glue. That is a real skill and this post is not going to argue with it.

What it cannot do is tap a screen. An HTTP Request node talks to servers with public addresses. The phone on your desk is on the far end of a USB cable, behind your router, speaking adb rather than HTTP. There is no node for that and none is coming, because the missing piece is not a node — it is a process running on the machine the cable is plugged into.

So the question is not how to make n8n reach the phone. It is where to put the boundary.

What the templates do instead

Search n8n's template library for TikTok or Instagram and you will find plenty of workflows that post. Look at what they actually call: most of them route through a third-party posting service. That is not laziness. It is what is left once the official publishing APIs are gated behind app review, and those gates are their own subject — see what TikTok's posting API will and won't let you do.

Routing through a reseller works. It also means your posting now depends on a company whose platform access can be revoked, whose queue you cannot inspect, and whose relationship with the platform is not yours. You inherited every gate and added a vendor.

The other handoff

The alternative keeps every decision in n8n and moves only the last mile. n8n POSTs the finished file to a webhook. The file lands in a folder. An automation watching that folder fires. A routine runs on a phone you own.

Three words, kept apart, because blurring them is how this gets confusing: a routine is what a phone does — open the app, pick the file, type the caption. An automation decides when a routine runs. A flow is the graph around both. n8n calls its graphs workflows, so that is the word used for them here and flow is reserved for NOISEY's.

n8n hands over one thing — a file — and keeps everything it is good at. Note the second arrow: the desktop app opens that connection outward, so a job waits in the queue until your Mac shows up rather than the server reaching in.

That second arrow is worth a sentence. NOISEY's servers cannot drive a handset — there is no path from them to a phone that does not run through software on your own machine, which is a structural fact rather than a policy (the docs put it the same way). The practical consequence is the one people trip on: a job that says queued is a job waiting for a desktop app that is not currently there.

The contract

One webhook URL serves the whole account, and the request names the folder. That is deliberate: it means an n8n node can expose the folder as an ordinary expression field instead of you minting a URL per queue.

The two things people get wrong are the folder and the body. The token in the URL is drawn redacted on purpose, because illustrations get copied.

In n8n specifically, four fields:

  1. An HTTP Request node placed where your workflow has the finished video as binary data.
  2. Method POST, URL your webhook plus ?folder=Morning posts — make it an expression if the workflow feeds more than one queue.
  3. Body content type n8n binary file, pointing at the binary property. Not JSON, not a form.
  4. A header x-filename with the file's name. It is how the upload is labelled in Media; leave it off and you get a timestamp.

From a script it is one command:

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"

--data-binary and not -d, which mangles binary. A folder can also be given as a path — ?folder=Clients/Acme — and if two folders share a name you get a 409 telling you to use the path, rather than a coin flip over which client's queue the video lands in.

What a 404 means at 3am

Every failure mode here is a distinct answer, because the alternative — a 200 that quietly did nothing — is the one that costs you a morning.

Six places a POST can stop, and what each one says when it does. Only the last two need a phone to be involved at all.

The one that surprises people is "deduped": true. Files are fingerprinted by their contents, per folder, so bytes already seen are recognised rather than re-ingested and nothing fires. A Drive re-sync or a retrying pipeline must never post yesterday's video to twenty phones a second time. The same clip deliberately dropped into two different folders is still two pieces of scheduling — the fingerprint is scoped to the folder, not the account.

Zapier, Make, or cron

Identical contract, no special-casing. Zapier is Webhooks by Zapier → Custom Request; Make is HTTP → Make a request. In both, send the file's bytes as the raw body — not a form wrapper, not base64 in a JSON field. The docs carry the field-by-field version if you want it beside you.

Where to put the decision

If a model should judge the content before it posts, that can live on either side of the line. Neither answer is always right.

Keep it in n8n when the decision needs your other systems: a CRM record, a sheet, an approval in Slack, credentials n8n already holds. Also when you want n8n's retry semantics and execution history, which are better than anything a posting tool will give you. If the deciding is the interesting part, do not move it.

Use a NOISEY flow when the decision needs something only NOISEY has — the file that just arrived, which client a phone belongs to, what a routine returned — or when your Mac may be asleep, since flows run server-side and the resulting job simply waits.

Two honest constraints on that second option, before you build on it:

The narrow pitch

We are not competing with n8n. n8n has a node for everything with an API, and it is better at orchestration than we intend to be. What it cannot have is a node for the handset in front of you, because that needs a process on your machine holding a cable.

That is the whole offer: you keep the workflow, we take the last mile. The full webhook contract is in the docs, and the walkthrough from watched folder to posted video shows what happens after the 200.

Read the docs →