Why
Make publishing state visible
Postid exists to keep preparation, team review, scheduling and per-platform publishing results in one inspectable workflow.
About Postid
A clearer path from draft to publishing result
Postid is a social media workflow product. We focus on the parts teams need to inspect: who can act, what is approved, when content will publish and what each platform returned.
How
Describe the product from working behavior
Feature, platform and security copy is checked against the current application behavior and implementation boundaries. Unknowns stay unknown instead of becoming marketing claims.
Who
Published by the Postid product team
Public product documentation is maintained as part of product development. Corrections and questions are routed through the contact page.
What we do not claim
Trust needs boundaries
We do not publish invented team size, office, customer count, awards or performance statistics. Customer logos and case studies will appear only with permission and source data.
Read the security boundariesHow this content is kept true
The practice behind the copy
Saying "we describe the product from working behavior" is easy. These are the four mechanisms that make it hold when nobody is watching.
- One catalogue, not many pages
- What each of the 7 supported networks can do lives in a single capability catalogue. The platform table, every platform page and every comparison read from it, so they cannot drift into three different answers about the same network.
- Every claim carries its limit
- Support is recorded in four states rather than as a yes or no: available, bounded by the network's own API, waiting on that network's app review, or not offered. A partial capability is written as partial.
- Claims point at the implementation
- Each entry in the catalogue names the code path behind it — the publisher, the metric collector, the comment provider. That is what makes a correction possible: a claim that cannot be traced cannot be checked.
- Review dates expire after 180 days
- Each of the 49 public routes carries the date its content was last reviewed. Once that date passes 180 days, the sitemap stops publishing a freshness date for the page instead of restating an old one. If review slips, the result is silence rather than a false signal.
Frequently asked questions
Who publishes the product content on this site?
The Postid product team, as part of product development rather than as a separate marketing exercise. Feature, platform and security copy is checked against how the application currently behaves, and corrections are routed through the contact page.
Why are there no customer logos, case studies or usage statistics?
Because we do not have permission and source data for them yet. Invented team size, office locations, customer counts, awards and performance numbers are the easiest things to publish and the hardest to walk back. They will appear when there is something real to show.
What does Postid actually cover?
Preparation, team review and approval, scheduling, publishing to 7 networks, and the result each platform returned. Analytics and comment management are available where the network exposes them — the platforms page states that per network rather than in a single claim.
How do I report something that is wrong on this site?
Through the contact page. A claim that turns out to be inaccurate is a defect in the same sense a bug is: the catalogue entry, the page and the code path behind it are all reachable, so it can be corrected at the source instead of edited on one page.