What happens when things break, and what this will not do.
Whether it is running right now is a different question, and it is answered on the status page.
| Format | What it is | What we check |
|---|---|---|
| text | A post, up to 3,000 characters. | The body as LinkedIn will receive it, including the citation where the destination carries it there. |
| single image | One graphic, at the size the destination expects. | Refused before it is queued if the size is wrong: a published image cannot be replaced, so it cannot be cropped later. |
| multi-image | Two to twenty graphics in one post. | Each one is checked, and the post is refused rather than published with one wrong image among nine right ones. |
| document | A PDF carousel. | The title is what LinkedIn shows on the card, so it is asked for rather than derived from a filename. |
| poll | A question and two to four options. | Validated when it is written — thirty characters an option, and a duration LinkedIn actually offers — because a format constraint discovered as a failed publish is the most complained-about failure in this category. |
| video | One video, with the upload done in parts. | Four API calls rather than one, which the plan's allowance accounts for. |
A decision rather than a limitation, and it is not on a roadmap. Every one of these is a thing this product could build and will not: the network's own terms forbid some of them, and the rest are how a tool of this kind gets an account banned and its customers with it. Printed from the channel's own record, so it says what this installation is actually bound by.
Official API only. No scraping, no browser automation, no automated connection requests and no automated messages.
| Never |
|---|
| scraping |
| browser automation |
| auto-connect |
| auto-message |
| exporting member data |
| No advertising: this product never creates, funds or targets a campaign. |
| No database of people, bought, built or sold. |
The network's conditions, not ours, and printed before anybody signs up rather than discovered on the Connections tab.
| What you need | Why, and how to get it |
|---|---|
| Admin rights on the company page you want to post to | The connection is authorised by a person, and this network only offers the page to somebody who already administers it. A colleague who is an admin can connect it instead; it does not have to be you. |
| A verified company on this network | Page verification is what this network asks for before it will grant a developer application access to publish for an organisation. It is done on the network, by the company, and not by this product. |
| A person's own profile needs neither | Posting as yourself is authorised by you signing in, so a founder or a consultant publishing under their own name can start without either of the two above. |
Some of these are limits and some are decisions. Which is which is said plainly.
| Scheduling inside LinkedIn's own scheduler | Posts are held here and published at their slot through the API. A post handed to LinkedIn's scheduler is one nobody here can pull back, and 'pull that post' is a thing customers ask for. |
| Automated likes, comments or follows | Not a limitation — a decision. LinkedIn's terms forbid it, and the account it would be done from is the customer's livelihood. |
| Connection requests, at any volume | The same answer, for the same reason. |
| Direct messages | There is no API for sending them, and doing it any other way means automating a browser against somebody's account. |
| Editing a published image | LinkedIn's edit exposes the text and not the image. A graphic is size-checked before it goes out because that is the only moment it can be. |
| Deleting a published post | Permanent, and the account holder's to do. Nothing here deletes from LinkedIn. |
These are the values the code enforces, not a policy written beside it. Deletion runs on a schedule; the trust page shows whether anything is overdue.
| What | Kept | Why that long |
|---|---|---|
checkins | 1.2 years | which licensed installations have said they exist: a licence id, an installation id, a build, two counts and the address it arrived from. One row per installation, kept for a licence year and its grace, because a dispute about a term is argued after the term |
credential_calls | 2 days | one row per call made on a credential, which is how a ceiling that belongs to the credential rather than to the installation is counted. The window is a minute; two days is kept so a burst can still be explained the morning after, and past that the row has no reader |
deliveries_out | 90 days | every attempt to tell another system what happened, and what was sent |
enquiries | 2.0 years | the client's own enquirers, in their own words — their commercial record, kept two years so a year-on-year comparison is possible, then gone |
li_actors | 1 days | other members' profile data — cache only |
li_comments | 42 days | organization social activity |
li_deliveries | 60 days | webhook de-duplication, our own |
li_member_stats | 1.0 years | the authenticated member's own data |
li_mentions | 42 days | organization social activity |
li_stats | 1.0 years | page admin and reporting data |
login_challenges | 1 days | a five-minute note saying a password was right and a code is still needed. Spent on use, and the row deleted within a day either way |
reply_drafts | 42 days | replies drafted to comments on this account's own posts. Swept on the same clock as the comments they answer, because a reply to a comment nobody can read any more is text with nothing on the other side of it |
resets | 1 days | password reset links — a way into an account, held for hours and deleted within a day |
sandbox_mail | 90 days | mail a sandbox account produced, captured here instead of being delivered. It carries the addresses somebody typed into a demonstration, which are usually real people's, so it is swept on a clock like any other personal data rather than kept because it is only a demonstration |
sentiment_reads | 42 days | how the comments on a post were read, as counts and the comments behind them. Swept on the same clock as the comments themselves, because a verdict whose evidence has aged out is a bare number |
sessions | 14 days | where each person is signed in — the address and browser a session was started from, so somebody can see a session they do not recognise and end it. Swept well past the point where the session itself has expired |
sign_offs | 7.0 years | who approved what, with the address it came from. Seven years, because the question an approval answers is asked long after the fact and a regulated client's retention obligation is usually six |
voice_vetoes | 2.0 years | a person saying a draft did not sound like them, with their name. Two years: after that the record it fed into is the thing that matters, not the objection |
Which product this installation is, and what the other one is. The difference is whose application a post leaves under, and that is what decides where it can be published.
| Edition | Who runs it | Whose application | Destinations | What it costs |
|---|---|---|---|---|
| Hosted — yours | XONIK | XONIK's | people's profiles | a plan, below |
| Licensed | you, on your own server | your own | profiles and company pages | $4,800 the first year, then $3,600, plus $600 a year for each further person |
A licensed installation warns for 30 days before its term ends and names the date. If the term ends, it stops publishing and nothing else: you keep signing in, reading and exporting for a further 60 days.
Anything you can do yourself — renew, move the installation within what the licence allows, reinstall, read your own standing — costs nothing. Work you ask XONIK to do for you is charged at $60 an hour, agreed before it starts.
Every figure below is the one the software refuses on, read from the plan table itself. A sign-in is somebody who works in the panel; a client who only reviews and approves opens a signed link and costs no seat.
| Plan | Brands | Destinations | Sign-ins | Posts a month | Price a year |
|---|---|---|---|---|---|
| solo | 1 | 3 | 2 | 40 | $228 |
| team | 5 | 15 | 5 | 200 | $588 |
| agency | 15 | 45 | unlimited | 600 | $1,548 |
| custom | 10,000 | 100,000 | unlimited | 100,000 | quoted |
| trial | 1 | 1 | 2 | 10 | quoted |
These are the platform's own rules for a product built on it that puts a language model near published content — not our summary of them — and what this product does about each one. They are printed from the same record the code reads, so a rule that changes changes here too.
| What is required | What this does |
|---|---|
| The feature must be labelled as AI-powered | Anything a model helped write carries the label wherever the person who will publish it can see it — in the panel, on the approval link a client opens, in the notification mail, in the export and on the printed report. |
| The output must be disclosed as possibly inaccurate | The same surfaces carry the accuracy warning beside the label, and the warning names what to check rather than saying that errors are possible. |
| The person must be able to edit before anything is published | An assisted draft is editable on the screen where it is approved, and every edit is kept as a version with the name of whoever made it. Approval alone is not the edit this requires. |
| AI content must never be published without the user involved | Nothing publishes without a person approving it, assisted or not, and approval is a separate act from writing. |
| Explicit consent is required for the specific use case before learning from a member's data | Three separate consents — drafting, learning how somebody writes, and drafting replies. Each records who agreed and the exact wording they were shown; changing that wording ends the consent rather than carrying it over. Nothing is sent until the consent for that use is live. |
| Content must not be generated for pages that are not using the application | Generation is refused for any destination this account has not connected, verified and left switched on. |
| There must be a way to report harmful output | A report button on the content itself. Each report is recorded against the account and sent to a person; where no mail transport is configured it still appears on the operator's screen rather than being lost. |
| No training on a member's data | Nothing this product holds is used to train any model. Learning how somebody writes is arithmetic over that account's own posts — counts and medians — computed here, kept here, and never sent anywhere or shared between accounts. |
The platform's limits, in its words. The table above this one is what the code enforces; if the two ever disagree, this one is the rule and that one is the bug.
| What | Limit | Note |
|---|---|---|
| Other members' profile data | 24 hours | cache only; storage is not permitted |
| Members' social activity | 48 hours | |
| Organizations' social activity | 6 weeks | 6 months where the organization authenticated |
| Organization profile data | 8 weeks | where authenticated |
| Page admin and reporting data | 1 year | |
| Standardized data such as geography and industry | 1 year | |
| Where two limits both apply | the shorter one | the network's own rule for every ambiguous case |
Four doors, and one line drawn through all of them: the API reads and it drafts. It never approves, queues, schedules or publishes — the platform's terms require a person to edit and release AI-assisted content, and a key that could approve would be a way to script exactly that step.
| Door | What it is for |
|---|---|
| A spreadsheet | The supported way to bring a month of posts in at once: a CSV or an XLSX on the Library tab, with a column per field. It is checked row by row and reports what it refused and why, rather than importing most of it. This is the front door for bulk work; there is deliberately no second one. |
| The API | A versioned address at /api/v1, authenticated by a key an agency issues to its own tooling. It reads posts, destinations, sources and the report, and it writes drafts through the same checks the panel uses. Keys are shown once, revocable, and scoped to one account and its brands. |
| Webhooks | Six events sent to an address you nominate — a draft waiting, a post published, a post that failed, a source that moved, comments that turned, an invoice raised. Every delivery is signed so you can verify it came from here, failures retry with backoff, and every attempt is in a log you can read. |
| A calendar feed | The schedule at a token-authenticated address, read-only, so a whole team sees what is going out inside the calendar they already keep open. It takes its own kind of key, which reaches the calendar file and nothing else: the address carries the key in it, and anything that ends up in a browser's history or a calendar client's settings should only ever be a schedule. An API key is refused there, and a calendar key is refused everywhere else. |
| Email a draft in | Not built. It needs inbound mail handling this deployment does not have, and a half-working version that silently drops a message is worse than an honest absence. |
Write to support@xonik.com. A person reads it; there is no queue and no ticket number.
Monday to Friday, 09:00 to 18:00 India Standard Time, excluding Indian public holidays. Outside that window nobody is watching a screen. What there is instead is a product that holds a post rather than losing it, tells whoever owns the account when a connection has failed, and never publishes twice. There is no response-time promise and no uptime commitment, and there will not be one until there are real numbers behind it.