TikTok Publishing Handoff Template for Creators and AI Agents
"Post the latest video tomorrow" leaves nearly every publishing decision unresolved. The person handling delivery still needs to identify the file, caption, destination account, account settings, time zone, and…

"Post the latest video tomorrow" leaves nearly every publishing decision unresolved. The person handling delivery still needs to identify the file, caption, destination account, account settings, time zone, and evidence that will count as completion.
Use one handoff per video. The creator supplies the approved files and specifies whether to publish or schedule them. The person handling delivery checks what the connected account supports, carries out that instruction, and records the result with the evidence available.
The template below is a document you maintain. It is not a Groniz approval feature, and its field names are not an API schema.
Start with a complete approved package
Suppose a creator sells a downloadable pottery glazing log. Video GL008 shows where to record a glaze name and firing date using fictional entries. The approved package consists of export version 4, caption version 2, and the current product destination.
The creator wants it scheduled to one specific TikTok account. They provide the account identity and an explicit timestamp with a time zone, chosen for their own production plan. Those details give the person scheduling the post a specific account and time to use.
Use the version and checksum approach in organizing TikTok video files so both people know what approval covers. A request to alter the video or caption returns the package for review.
Copy this per-video handoff
Keep the approval portion intact after delivery and append the execution result. That preserves what was requested as well as what happened.
HANDOFF
Handoff ID:
Video ID and buyer question:
Owned offer and product version:
Approved export path and version:
Export checksum:
Approved caption reference and version:
Exact approved destination URL:
Approval record and reviewer:
Destination platform:
Connected account identity:
Verified integration ID:
Authorized action: publish now / schedule
Requested date, time, and time zone:
Account settings checked at:
Required settings and their verified values:
Commercial disclosure decision:
Verified route for required disclosure:
Media upload reference, once obtained:
Executor:
Instruction if a required value is unavailable:
RECEIPT
Handoff ID:
Attempt timestamp:
Account and integration used:
Export and caption versions used:
Uploaded media reference used:
Requested publication timestamp:
Returned operation or post identifiers:
Observed status and time checked:
Publication evidence, if confirmed:
Unresolved issue:
Next action and responsible person:
Use explicit values such as "unavailable" or "awaiting creator decision" in incomplete fields. An empty disclosure-route field should not be interpreted as permission to proceed without checking it.
The creator counts paid glazing-log purchases in checkout records. The delivery receipt records what happened to the post; it takes separate evidence to measure purchases and connect them to a video. The broader TikTok automation and owned-offer model explains that distinction.
Let account discovery resolve delivery details
Groniz Connectors handles OAuth, per-platform formatting, and supported delivery operations. Its capabilities differ across networks. Check the requirements for the connected account before acting on the handoff.
For a CLI workflow, authenticate and use whoami to confirm identity. Use integrations:list to locate the intended connection, then integrations:settings with its real integration ID to inspect the current requirements. Use the returned settings to build the request. The template's labels describe information to collect and may differ from the fields the platform accepts.
Upload the approved media before using it in a delivery request. Record the returned .path and associate it with the approved export. Then construct the request using verified settings and the authorized timestamp.
Treat this as a handoff example. It has not been tested with a live TikTok delivery, and you need to inspect the account's current settings before building a request. The Codex and Groniz TikTok publishing guide provides the wider publishing context.
Resolve disclosure before execution
TikTok requires its content disclosure setting when content promotes a brand, product, or service, including the creator's own business. Record that requirement in the handoff, using TikTok's content disclosure guidance.
The person handling delivery then verifies how the chosen route satisfies the requirement. A disclosure decision in a document does not activate a platform setting. If the necessary control cannot be verified on that route, hold the handoff and use a supported route after the creator resolves the delivery plan.
Check an unknown outcome before retrying
Imagine the GL008 scheduling request times out before the executor receives a clear result. The receipt should say that the submission outcome is unknown, preserving the attempted timestamp and any returned identifier. It should not say "failed" simply because the client stopped waiting.
Before retrying, reconcile the request against the available delivery records and destination evidence. A second submission while the first is unresolved can create a duplicate. If the available evidence remains inconclusive, assign a person to investigate and keep the retry pending.
When a scheduling request is accepted, record acceptance. Confirm publication separately when publication evidence becomes available. If the requested time passes with no confirmed result, append the latest observation and its timestamp; do not rewrite acceptance as proof of publication.
Return the receipt to the creator, including any result that still needs checking. Once your approved package is complete, open Groniz Connectors, verify the intended connection, and execute only the delivery decision recorded in that package.

