Wall posting
How scheduling a post or story to your OnlyFans wall actually works — the plan table, the two write gates, and why scheduling and delivery are separate steps.
Wall posting is TEASE's plan for your OnlyFans feed and stories — separate from the inbox (DMs to individual fans) and separate from broadcasts (a paced campaign to a segment). You compose a post or a story frame in the panel, put it in the plan, and TEASE hands it to OnlyFans at the time you chose. The Posts view is the other half of the same feature: it reads back what actually happened on the wall — views, likes, tips, and purchases per post — once OnlyFans has published it.
Scheduling writes only to our database
Putting a post "in the plan" never talks to OnlyFans. A separate dispatcher — a background
tick, not the request you made — reads the plan and hands due rows to the platform. This is
why a freshly-scheduled post's status is scheduled, not sent, and why nothing goes out at
all while that dispatcher's write gate is off. See Troubleshooting
for what each status actually means.
Posts and stories are two kinds, two gates
A row in the plan is either kind: "post" (feed) or kind: "story" (24-hour story). They share
the same table and the same plan screen, but everything else about them is independent:
| Post | Story | |
|---|---|---|
| Write gate (env) | OF_POST_WRITE | OF_STORY_WRITE |
| Native scheduling | Yes — OnlyFans holds the scheduled time itself | No — TEASE must publish it at the right moment |
| Can carry a price | On a free page, yes | Never |
| Can be taken down after publishing | Yes, by request | No — OnlyFans gives no confirmed takedown address; it expires on its own within a day |
| Caption | Plain text field | Burned into the image — OnlyFans stories have no native caption |
Each gate is one of three values: off (nothing is sent, everything queues as a shadow log),
shadow (the same dry-run logging), or signed (real delivery). Story publishing defaults to
off independently of posts — its publish address was still being calibrated live when this was
written — so a page can have live post publishing and disabled story publishing at the same
time. An unrecognized value for either variable is treated as off: a typo can never accidentally
mean "publish for real."
Pricing a feed post
A feed post can carry a price only when your OnlyFans page is a free page — a paid post on a
paid-subscription page isn't something the platform allows; you'd sell that content through a
message instead. The panel asks the server first (can_price_posts) and only shows the price
field when the answer is yes, rather than showing it and then rejecting the number after the
fact.
The price also only reaches OnlyFans if the post carries at least one media file — a paid post with nothing attached is meaningless, so the server drops the price from the outgoing body whenever there's no media. The composer mirrors this rule locally too: if you type a price and then remove the attached file, scheduling is blocked until you either re-attach something or clear the price, rather than silently sending the post out free.
The content firewall runs at schedule time
Every caption and its media references pass through the same offline content-safety lint used
elsewhere in TEASE (off-platform payment solicitation, contact-info leaks, and a short list of
categories OnlyFans and card processors both hard-ban). The verdict is stamped onto the row as
firewall_state — clean, flagged, or blocked — the moment you schedule, not later when the
dispatcher picks it up. A blocked verdict fails the row immediately: it never reaches the
dispatcher at all.
Media comes from the OnlyFans vault, not your page assets
The picker you attach files from reads your indexed OnlyFans vault — the same index behind content search and vault performance — not TEASE's page-design media library. What ends up in the post body is the vault's own file id, because that's the identifier OnlyFans itself understands. A vault item marked "do not send" can't be picked at all; the picker disables it rather than letting you attach something the dispatcher would refuse later.
Preview shows the real request body
Because the actual body OnlyFans receives — media ids, the price in dollars, the ISO scheduled time, the expiry window rounded up to whole days — is assembled by the same server function the dispatcher will eventually call, the panel's "Preview" action can show you that exact object before anything is scheduled. It's not a guess at what the request will look like; it's the literal function called with your current form values, so there is nothing "under the hood" left between what you see and what goes out.