Start a Trend Board From Any Post Link
New: Turn a single post into a trend board
Found one Instagram or TikTok post that nails exactly the content you're after? The Trends API now accepts a post_link alongside keyword, semantic, and centroid search. Glystn resolves the source post's stored embedding and runs the full time-series trend analysis from that anchor — so your board starts from real, concrete content instead of a semantic prompt you're still tuning.
How it works
- POST to
/api/trends(or the public/api/public/trends) with apost_link— any Instagram permalink, a TikTok video URL, or a youtu.be-style short link for the TikTok side. - Glystn looks up the stored embedding for that post, then clusters similar content across the date range and period settings you pick.
- The run comes back with
source: "post"and the originalpost_linkechoed back on every GET, so you can always trace a board to the post that seeded it.
Cleaner period-based time controls
- Renamed inputs. Time-series inputs are now
periodsandposts_per_periodinstead ofmonths/posts_per_month— so the field names finally match weekly and quarterly runs. The old names still work as deprecated aliases; existing integrations keep running untouched. - Period size is locked to weekly, monthly, or quarterly.
period_daysmust be7,30, or90. Anything else returns a clear validation error up front instead of running a surprise bucket size. - Tuned defaults. Trending runs default to
1000posts per period (down from 5000), and topical runs now default to2000with a10000ceiling. Fewer wasted credits when you don't actually need forty thousand posts.
Refreshed /docs for trending vs topical
The Trends section of /docs picked up a new "How to Think About This Endpoint" walkthrough that frames every trend run around four decisions: your search mode, your analysis mode, your time controls, and your filters. There are side-by-side examples for trending and topical boards, a full post-link example, and TikTok is now called out alongside Instagram throughout.
Under the hood
Also fixed: trend run responses now consistently surface the originating centroid on deep-dives via parent_centroid_id fallback, so the UI can always render the "built from" badge even on older runs.