Syndication

Syndication hands your channels' posts on to your participants: whoever joins one of your groups in its iframe. You make the channels, the content and the branding; your participants post it on their own accounts.

Syndication sits under Publication, beside Channels, and is part of Enterprise. On every plan below, it is not in the menu. Your plan includes a number of syndication participants, agreed with us in your Enterprise offer, and you add more yourself as Additional syndication participants on Plan, at the price in your offer. That one number is also how many groups you can have, and it counts your participants across all your groups together (only those who can receive something), so one group can hold all of them, or every group one. The figure at the top right of Syndication groups counts them against it, and its question mark leads to Allowance.

With no syndication participants at all, syndication is off, as on the plans below: it is not in the menu and its pages take nobody. The first participant you add on Plan, or a new offer that includes some, turns it on.

The screen holds four cards, one under the other: Syndication groups, Email settings, Branding and Syndication log.

How it works

1. You make a group of your channels. Each group has an iframe of its own.
2. Your coder copies the group's iframe code into your portal, on the page where those participants should join. You decide who sees which iframe.
3. In the iframe, each participant joins themselves: they choose the channels they want, and give an email address and/or a webhook address, as the group allows. Each is confirmed by email before anything goes to it. The page and the emails speak of joining a broadcast and leaving it, never of a subscription, which would read as something to pay for.
4. From then on, every post of the channels they chose reaches them when it is handed over to you. If a channel asks for approval, the participant gets the post once it is approved, as you do.

Some ways to use it:

• One client, one channel. Make a group with the one channel you made for that client, and put its iframe on that client's page only. With one channel there is nothing to choose: they give an address or a webhook and receive it.
• Everybody, every channel. Make one group of all your channels and put its iframe before all your participants. Each chooses the ones they want: all, some or one.
• By language. Make a group per language and show each participant the iframe of theirs, by your own portal's rules.

Nothing a participant does is reported back, and your Posts screen follows your own hand-over only. If a group's iframe reaches somebody it should not, make a new group and remove the old one.

Syndication groups

The first card lists your groups: each one's name and description, how many channels it hands on, how its posts reach participants, the sites it may be shown on, and how many participants it has. Add new syndication group opens the group's dialogue; Settings on its row opens it again. It holds what the group is:

Setting	What it is
Name	Yours alone, to tell your groups apart. Participants never see it.
Page title	The heading at the top of its iframe, up to 100 characters. Left empty, it reads "Ready-to-post videos from" and the title in your Branding.
Description	What participants read at the top of its iframe, under the page title.
Channels	A table of your channels, with their platform, ratio and language, searched, ordered and paged like every list; tick the ones the group hands on. They are offered to participants to choose from. With one channel there is no choice to make and nothing is shown: every participant receives it, even after you swap that channel for another. With several, each participant chooses the ones they want.
How its posts reach participants	By email, an email with a link to the post kit, and/or by webhook, a signed call to the participant's own system. At least one. The group decides, whatever its channels hand over by themselves.
What participants see	Logo and title in the sign-up page: on, the page starts with your logo and title as the emails do; off, it starts with its first card, for a portal that shows it under a header of its own. Then three buttons, each opening an example in a dialogue of its own: the sign-up page in the iframe (its buttons do nothing there); an email that a post is ready; and the post kit it opens, built from your newest post of the group's channels where there is one, else from a sample. All three are drawn in your branding from the values in the dialogue, saved or not, so they are there in Add new syndication group before the group exists.

Closing the dialogue with a change unsaved asks whether to save it, discard it or keep editing, as the Branding and Email settings dialogues do.

Implementation on the group's row holds how the group is built into your portal, the part for whoever codes it. It opens by itself after you add a group, with the code ready to copy:

Part	What it is
Where it may be shown	The site whose pages may show it, such as https://portal.example.com, several separated by commas. Anywhere else, browsers refuse to show it, and the page does not open on its own either. Empty is any site. The one setting here, kept with Save.
The code for your portal	The iframe code, for your coder to copy into the HTML of your portal's page where participants should join. Its allow="clipboard-write" lets the Copy buttons on the page copy from inside your portal; iframe code copied before it still works, as the page falls back to another way of copying.
Participant IDs and email addresses (optional)	The group's portal key, and the code your coder needs to tell the page which of your participants is looking. See Your own participant IDs and email addresses below.

Letting the frame fit the page. The iframe code starts 900 pixels high, which can leave empty space under a short page or cut a long one off. The page inside it tells your portal its own height each time that changes, so a few lines of script beside the iframe can make the frame exactly as tall as the page, with no empty space and no second scroll bar. Your coder adds them like this:

<iframe id="partner-page" src="..." style="width:100%;height:900px;border:0" allow="clipboard-write"></iframe>
<script>
  window.addEventListener("message", (event) => {
    const frame = document.getElementById("partner-page");
    if (event.source === frame.contentWindow && event.data?.type === "partner-frame:height") {
      frame.style.height = `${event.data.height}px`;
    }
  });
</script>

A channel added to a group is offered to its participants as a new choice; one taken out is no longer handed on. Remove on the group's row takes the group away with its iframe and its participants, once you have typed the group's name to confirm it.

Participants on a group's row lists who receives its posts: your participant ID for them where your portal gave one or you typed one, their email address, their webhook, how many channels they take, how they came to be there under Sign-up (Self-service for those who joined in the iframe, Added by owner for those you added), and their status: Active where posts reach them, Not confirmed while what they gave still waits (an address or a webhook to be confirmed by email, a webhook to answer its test), Blocked, or Paused for one paused through the API. Search by participant ID, address or webhook, newest or oldest first, and choose how many to a page, as on every list. At the top of it:

• Add participant manually adds one yourself: their channels where the group has several, an email address and/or a webhook as the group allows, and your participant ID for them if you have one. An address still gets an email asking its owner to confirm it, since only they can say yes to it, and a webhook still gets a test call first. Adding a webhook shows the group's signing secret once, to pass on to them: they never saw the iframe that shows it.

And on each row:

• Settings changes their participant ID, their channels, their email address and their webhook. Another address gets an email asking its owner to confirm it, and the one confirmed keeps receiving until they do; another webhook gets a test call first. Emptying the address or the webhook stops that way.
• Block stops everything to them, and the same address, webhook or participant ID cannot join the group again until you Unblock them. A blocked participant does not count against your plan.
• Remove takes them off for good, with their lines in the log. They can join again in the iframe; block them instead to keep them out.
• Resend invite, on a row whose email address still waits for its owner to confirm it, sends the email asking them to confirm it once more, for when the first one went missing. A minute must pass between two, and a participant gets at most five such emails a day.

Syndication log

The last card lists every email and webhook call to your participants, newest first: when, its status, the participant and their group, the way, what it was (a post, an update or a delete request), the channels it carried and what came back. The status says what happened: Sent for an email the mail server took, Success for a webhook that answered with a 2xx, Failed, retrying while it is tried again on a ladder, and Failed once it ran out of attempts; a line not sent yet reads Queued or Sending. Search by participant, address or error, filter by status, way and kind, and Send again queues a line from its first attempt. A participant's webhook is given five seconds to answer, so one slow receiver never holds up the others.

What goes to participants does not depend on the channel's own ways out: a channel with Handed over by email, by webhook and by platform connector all off still reaches every participant whose group takes it. See Channels.

Your own participant IDs and email addresses

Where your portal knows who is signed in, it can tell the page, and the page then shows them what they joined with. What you call them in your portal is up to you; here it is their participant ID. Your coder adds two values to the iframe's address for your own ID for them, two for their email address, or all four:

<iframe src="https://reelwire.io/embed/...?participant=C-1001&sig_participant=SIG_PARTICIPANT&email=anna@example.com&sig_email=SIG_EMAIL" ...></iframe>

participant is your own ID for them, up to 100 characters, and sig_participant is its signature: the HMAC-SHA256 of the ID, keyed with the group's portal key, in hex. email is their address and sig_email its signature, made the same way. With the address, the page asks them for none at all: their confirmations go to it, and it finds them by it. The group's Implementation shows the key, and the code that makes both signatures in Node.js, PHP, Python and C#. Make them on your server, never in the browser: the address can be edited by anybody, and a value without the right signature is refused, so nobody can see or change what another participant receives by typing their ID or address. A participant joins each group once; their ID is shown beside them under Participants.

What a participant does in the iframe

The page has a card for each thing to give, each with its own buttons:

• Your channels: the ones they want, where there are several. A participant your portal named saves a change with Save my channels; anybody else's go with each Join.
• By email: their Email address and Join. An email asks its owner to confirm it, and nothing is sent to it until they do. Every email has a link to stop them.
• By webhook: the Webhook address, the Email address to confirm it from, and Join. That address is only for confirming: it receives no posts, and it is not asked where your portal passed one or the participant gave one before. Once confirmed, the webhook gets a test call, and posts go to it once it has answered one with a 2xx. Send a test call is always under the address, before joining as well as after, and tries the address shown or typed without keeping it. Below it is the group's signing secret with a Copy button, and Implementation instructions: how a call is signed and answered, and example code for checking one in Node.js, Python, PHP and C#, with the group's secret already in it and a Copy example code button. A webhook can also stop by answering a call with 410 Gone.

Every joining, change and leaving is confirmed by email, in two steps. The email opens a confirmation page in your branding, and the button on that page does it; opening the link alone changes nothing, so a mail scanner that opens every link cannot add or remove anybody. The stop link at the foot of every post email works the same way.

A participant your portal named sees what they have in each card, as a fixed value rather than a field: an address that receives posts is tinted light green with a tick beside it, and Leave at the foot of the card emails them the confirmation, also for something still waiting for its own. They change their channels at once with Save my channels, since your portal vouches for them. A blocked participant is told that posts from here are not sent to them any more, and gets nothing to join with.

Somebody your portal did not name gets every field open, with Join / Update and Leave in each card: the email address they type is who they are, and the email that follows proves it. The page cannot know whether that address receives already, so the same button adds it or, where it receives, asks to confirm the channels chosen now. Every answer is the same whether the address receives the videos or not, so the page never tells anybody who does.

Every card reads the same way: what explains it under its title or a field's caption, then the field, then the one place a message appears, then its buttons across the card's full width. The webhook card's Join comes last, after the signing secret that goes into the receiver first. While a button's request is on its way, the button itself says so with a spinner, and only one message shows on the page at a time.

Each group has one signing secret, made with the group; you never need to see it. There is no account and no settings page beyond that. The same email address cannot join one group twice. A participant who leaves with everything they gave is removed from Participants at once, with their lines in the log; one whose confirmations are not pressed within a week is removed too. A few emails a day go to one participant, and a few joins an hour are accepted from one internet address. Everybody who can receive something counts against your plan; when it is full, the iframes take nobody new.

What a participant receives

• By email: an email saying the post is ready, with a button to their post kit: the video to download or share, the cover, and the text with a copy button. It has no Mark as published and no Skip.
• In every email, a box under its first line says what it is about: the group's Page title (or "Ready-to-post videos from" and your title), and the channels, each with its platform, shape and language. The email asking them to confirm also carries the group's Description, and says in plain words what comes, how, and that they post it themselves, on their own accounts.
• By webhook: the same signed call format as your own webhook call, cut to the channels they chose. See Syndication in the API manual.

A change to a post and a request to take one down reach the participants who were given that post, and nobody else. A resend of a post to your own people is not sent to participants. On a channel with none of its own ways switched on, Resend post request on Posts sends the post again to its participants instead, by the ways each group allows.

Email settings

The Email settings card shows how the emails to your participants are sent, the sender's name and address, and where their replies go. Change the email settings opens the dialogue. The emails go one of two ways, chosen at the top of it:

• From an address on reelwire.io, through Reelwire's mail service. You choose the part before the @, such as acme-news@reelwire.io: up to 40 lower case letters, digits, dots and hyphens, and nothing else can be typed there. No mailbox stands behind it and nothing sent to it is read, so set Replies go to to an address of yours that somebody reads. Until you choose one, emails come from Reelwire's no-reply address under your name.
• Through your own mail server (SMTP), from your own address. Fill in what your mail provider's settings say:

Field	What to enter
Mail server	Its name, such as mail.example.com. It must be on the internet.
Port and security	587 with STARTTLS is the usual; 465 with TLS; 25 and 2525 are there too.
Login	The mail account's user name, often its address, and its password. The password is kept encrypted and never shown again: a saved one shows as dots, and stays unless you type a new one over it.
Address to send from	The address your participants see the emails come from: one your mail account may send as.

Saving tries the mail server first. If it does not answer or does not take the login, nothing is saved and the dialogue says what the server said. Emails that go through your own server are yours: whether they arrive depends on your server and your domain's settings, and a bounce comes back to your mailbox, not to Reelwire.

Either way, the sender's Name is your branding's title and follows it, until you give it a name of its own, and Replies go to takes an address of up to 254 characters, the letters, digits and signs an address is made of. Send a test email sends one email in your branding, the way the values in the dialogue say, saved or not, to your own address.

Branding

Everything a participant sees wears your branding: every group's iframe, every email, and the post kit an email opens. The Branding card shows it, and Change the branding opens the dialogue. It is your logo, a title beside it, a footer under the card (your company's name and address, or a notice your participants need, one line per line), a font, and four colours:

Colour	What it colours
Page	the background behind everything
Card	what the words sit on
Accent	buttons and links
Signature	the title beside the logo, and every heading

The font is chosen as a brand's fonts are: a preinstalled font or a font file from your media library, and its size, from 0.8 to 1.4 times. It draws every group's iframe, every email, and every page an email opens (the confirmations and the post kit). Mail apps that load web fonts, such as Apple Mail, show it in the emails; those that load none, such as Gmail and Outlook, show the nearest font they have.

Every other colour follows from these: words are dark or light by what they sit on. The logo is a PNG, JPEG or GIF from your media library, at most 512 KB, because it travels inside every email. The dialogue shows an email as a participant will see it while you choose, and asks before closing with a change unsaved. Nothing a participant sees carries Reelwire's name, with one exception: with neither a logo nor a title of your own, Reelwire's logo and name stand at the top instead. The texts still call you by your workspace's name.