Media

What the library is

Media is everything your workspace has uploaded: the images and videos Tempio holds, and the ones a platform has taken its own copy of. Every asset belongs to one ad account, so the account it was uploaded for is what decides which platform ever receives it.

Tempio holds the bytes in the workspace's own file store. A platform holds a copy of its own only after an upload draft is approved and applied — until then the file exists here and nowhere else, and the library says so on the card.

The Creative pages have three tabs at the top: Assets, which is the library, Presets and Brand kit. The number beside Assets counts the files you can open in this workspace.

Generated creative

The Presets and Brand kit tabs make ad stills rather than hold uploads. A model draws a scene with no words in it and Tempio sets your copy, compliance line and logo over it, in your brand's colours and typeface. A still you use in an ad is copied into this library for that account and goes to the platform through the same upload draft as any other file.

• Create: how a still is made on Presets, covering the two layers, the copy fields and their limits, the gallery, adding a ratio and editing copy, using a still in an ad, and the monthly allowance.
• Brand kit: the six colour roles, the contrast check, typography, voice, the compliance line, forbidden words, products, and importing a kit from a website.
• Presets: the seven system presets, which fits which job, and what a preset holds.

Uploading a file

Pick the ad account the file is for, then drop the file onto the upload area, or press Choose a file. The upload starts as soon as the file is in; there is no second button. With an empty library the upload area fills the page, and once the library holds files it becomes a strip above them. A workspace with no connected ad account has nowhere to send a file, so the page sends you to Connections instead. One file goes at a time: a drop that holds several files, or none, is refused with the words Nothing was uploaded. Five things happen, in this order:

1. Your browser reads the file and computes its content hash.
2. It asks Tempio for an upload token. The token is issued only to a signed-in member of the workspace, only for a key inside that workspace's own part of the store, and only for the content types and the size ceiling the file's kind allows.
3. The browser sends the bytes straight to the file store. They never pass through Tempio's servers.
4. Tempio records the asset. It reads Held by Tempio, with the account, the size, and whatever shape the browser could measure — pixel dimensions for an image, dimensions and duration for a video. A file the browser cannot decode is still uploaded; it simply carries no shape.
5. Tempio writes one upload_media draft against that account's connection. Approving it is what hands the file to the platform.

The asset row and the draft are written together, and the row stands even if the draft is refused: the bytes are in the store, and a library that showed otherwise would be lying about where your file is.

What the library holds

Those ceilings are the widest a platform accepts rather than the narrowest. A file inside them is worth holding even when one platform refuses it, and the platform that refuses says so at the gate in its own words, with its own limit — Google's image limit of 5 MB is checked there, against the size recorded at upload, before a single byte is fetched.

Who approves an upload

A media upload is one of the changes no approval rule can clear. You approve it, or an MCP key holding the approve scope does. The drafts page has the full list of what a rule never approves and why.

An applied upload has no undo either. The file is in the ad account's own library from that point, and building an ad from it is a change of its own.

What each platform does with it

Google is the one that differs in kind. Its image limit is 5 MB, its bytes are checked against the size and the hash recorded at upload — a file of a different length or different contents is not the file that was approved — and its only video asset is a YouTube video, named by its id. A video in this library is a file for Meta and TikTok; a Google video draft names a YouTube address instead.

A transcode is a separate fact from an arrival. An applied video upload means the file reached the account; whether it can run in an ad is what the platform's own processing decides, and the draft reports it.

What the status means

An upload reads Held by Tempio, and applying its draft is what moves it.

It reads On the platform, with the platform's id beside it, when the platform took the file and can run it.

It reads Processing when the applied draft ended on the platform saying, about that file, that it is still transcoding it. Meta and TikTok both hand back the video id at the same time, so the id sits on the asset while it still reads Processing. Processing, below, is what moves it.

It reads Refused when the upload draft failed: the platform turned the file down and the reason is on the draft, in the platform's own words. The bytes are still in the workspace's store, so a second upload draft for the same file, one the platform does accept, returns the asset to On the platform. An asset the platform is already holding never reads Refused — those bytes are there, under an id every creative in the account can reference or one still being prepared, and a second draft for the same file being turned down is a refusal of the draft, not of the asset.

Processing

A video Meta or TikTok is still transcoding is not a video an ad can run, so the library holds it at Processing rather than calling it landed. Each platform is asked once, the moment it accepts the upload, whether the file is usable yet; a video it already calls ready goes straight to On the platform, and only one it says it is still preparing reads Processing. Tempio then asks the platform again about every asset sitting there, once every ten minutes: the ones the platform now reports as ready move to On the platform, the ones it reports as failed move to Refused, and there is nothing for you to press.

An asset that has read Processing for twenty-four hours is marked Refused. A transcode still unfinished a day after the platform accepted the file is one that is not coming back, and a record that read Processing forever would be the library lying about a file you can simply upload again — the bytes are still in the workspace's store, so a fresh upload draft for the same file is one draft away. The clock runs from the platform's own last word about the file, and choosing the same file again in the upload area does not restart it.

A connection that is paused, disconnected or in error is not asked at all: there is no working grant to ask through, and a question that can only fail is not worth one request every ten minutes. Assets under it wait where they are, and the first pass after the connection is working again is the one that answers them — including with the twenty-four-hour limit, which by then has long since passed.

Google assets never read Processing at all: its images are sent inline and are usable as soon as the call returns, and its only video asset is a YouTube video, which is named rather than uploaded.

The same bytes are one asset

An asset's identity is the content hash of its bytes, not its file name. Uploading the same file twice into the same ad account gives back the first asset rather than a second copy — one row, one object in the store, one id for a draft to name. It is what makes an upload safe to retry: a repeat costs nothing and creates nothing.

The same file uploaded for a different ad account is a different asset, because each platform account holds its own copy and gets its own id back.

Deleting

Delete, the bin icon in a card's footer, drops Tempio's record of an asset the platform is not holding — one that reads Held by Tempio, or one that reads Refused, because a file the platform turned down left nothing there to account for. For an asset that reads On the platform or Processing it is switched off, and its tooltip says why: the platform has the bytes, the applied draft is the only account of how they got there, and removing the record would remove that account. Take that file out of the platform's own library on the platform.

Deleting a record leaves the object in the file store. The bytes are addressed by their hash, so one distinct file costs one object however many records point at it, and uploading the same file again adopts that object rather than writing a second one.

Finding an asset from an agent

Your own AI over MCP reads the library with list_media_assets. It lists only, newest first, and uploads nothing. Each row carries:

• id — Tempio's own id for the asset;
• organizationId — the workspace the row was read from, always your own;
• adAccountId, platform and kind;
• fileName and blobUrl — the name and the address of the bytes Tempio holds;
• bytes, width, height and durationMs;
• platformExternalId — the Meta image hash, TikTok video id or Google asset resource name, which is null until the platform has ingested the file;
• platformStatus.

An ad or creative draft references an asset in media[], by platformExternalId: the platform's own id for those bytes is what a creative names, and it lands on the row when the upload draft is applied. Read the library first and reference what is already there — re-uploading a file the account already holds is a change nobody needed.