Widget overview
The widget is a set of ready-made screens served from social.missless.tel and embedded in your product in an iframe. They talk to the same API you do, scoped to one workspace by a short-lived embed session you mint on your server. Use them where you do not want to build UI; use the API where you do.
Surfaces
Section titled “Surfaces”| Surface | URL | What it does |
|---|---|---|
composer |
https://social.missless.tel/embed/composer?session=mle_… |
Write a caption, attach media, pick accounts, set per-network options, publish now or schedule |
calendar |
https://social.missless.tel/embed/calendar?session=mle_… |
Month and week views of scheduled and published posts in the workspace timezone. Open a post to edit, reschedule, cancel or retry |
inbox |
https://social.missless.tel/embed/inbox?session=mle_… |
Conversations across the workspace’s accounts. Reply to DMs, answer comments, send private replies, mark read, close |
accounts |
https://social.missless.tel/embed/accounts?session=mle_… |
Connected accounts with status, a Connect button that opens the hosted connect flow, and disconnect |
all |
https://social.missless.tel/embed/all?session=mle_… |
The four surfaces behind a tab bar |
Every surface reads the workspace timezone and the session locale (en or nl) and follows the session theme.
How it authenticates
Section titled “How it authenticates”- Your server calls
POST /v1/embed-sessionswith your partner key and gets a token starting withmle_. - You put that token in the iframe URL, or in the loader’s
data-sessionattribute. - The iframe calls
/v1/embed/*with the token. Those endpoints only ever see the session’s workspace.
The token expires (default one hour). It cannot read or change anything outside its workspace, cannot mint keys, and cannot reach your partner-level resources, so it is safe in a browser. Mint a fresh one on every page load. Details in Embed sessions.
What the widget calls
Section titled “What the widget calls”For transparency, the iframe uses these endpoints, all under /v1/embed/ and all requiring an mle_ token. They mirror the partner API with the workspace fixed by the session.
| Method | Path |
|---|---|
| GET | /v1/embed/session |
| GET | /v1/embed/accounts |
| DELETE | /v1/embed/accounts/:id |
| POST | /v1/embed/connect-link |
| POST | /v1/embed/media |
| GET, POST | /v1/embed/posts |
| GET, PATCH, DELETE | /v1/embed/posts/:id |
| POST | /v1/embed/posts/:id/publish |
| GET | /v1/embed/conversations |
| GET | /v1/embed/conversations/:id |
| POST | /v1/embed/conversations/:id/messages |
| PATCH | /v1/embed/conversations/:id |
You do not call these yourself. Your backend uses the partner API.
Everything stays in sync
Section titled “Everything stays in sync”A post created in the composer is a normal post: it shows up in GET /v1/posts, fires post.published to your webhook, and carries created_by: "embed". A reply typed in the inbox surface fires message.sent with sent_by: "embed". Accounts connected through the accounts surface fire account.connected. Your API-driven views and the widget never disagree because they read the same records.
The iframe also tells the parent page what happened through postMessage, so you can refresh your own UI without waiting for a webhook. See Widget events.
Choosing between widget and API
Section titled “Choosing between widget and API”| You want | Use |
|---|---|
| A social tab in your product this week | all, or the individual surfaces in your own tabs |
| Your own composer and calendar, MissLess as the engine | The API: Posts and Scheduling |
| Your own composer but not your own inbox | API for posts, inbox surface for messages |
| Just a “connect your accounts” screen | The accounts surface, or a connect link and your own list |
Mixing is normal. The Next.js guide uses the API for publishing and the accounts surface for connecting.