One API covers half this product.
Community Management gives AMI everything it needs to publish and to handle what comes back. For finding conversations to join it gives nothing — and no LinkedIn product does.
The boundary
LinkedIn draws one line through its platform. AMI sits on both sides of it, and everything below follows from that.
Publish as the page. Read its posts, comments, reactions and mentions. Reply to them. That is the Community Management API — gated, weeks of human review, worth starting today.
Keyword search. Reading a post by someone who never mentioned you. No API — not gated, not expensive, absent. AMI's whole listening module lives here.
Why it matters commercially. The sanctioned half sells with no argument. Keeping listening separate is what lets you sell it without defending the other half.
Community Management API
The only official product needed. Sign In is its prerequisite; Share posts to a person not a page; Advertising and Lead Sync are out of scope.
| Capability | What it gives AMI | Scope |
|---|---|---|
| Post as an organization | An approved draft lands on the page. Replaces today's copy-paste-then-mark-published step. | w_organization_social |
| Read your page's posts | Reconciles what AMI thinks is published with what is — and catches posts made outside AMI. | r_organization_social |
| Comments & reactions | Closes the loop FR-704 closes only for Reddit today. | r_organization_social |
| Reply to comments | An approved reply posts back through the same gate. | w_organization_social |
| Mentions of the page | The one listening-shaped thing on offer. Narrow, but no grey area. | r_organization_social |
| Page admin metadata | Which pages the token may act for. | r_organization_admin |
Measured against what AMI actually doessix capabilities · four covered
| AMI needs to… | Community Management | Covered |
|---|---|---|
| Publish an approved post | Yes — as the organization. | fully |
| Read replies to it | Yes — comments and reactions on your own posts. | fully |
| Post an approved reply | Yes — reply to a comment on your post. | fully |
| Find people talking about you | Mentions only — not people describing your problem without naming you. | partly |
| Search public posts by keyword | No product exists. This is not a permission you can apply for. | not at all |
| Read a stranger's post to reply to it | No product exists. | not at all |
Getting accessfile this week — the clock is not ours
What the application needs
- An app under a verified Company Page — decide whose before applying.
- A live privacy policy URL.
- A use case. Use the true one — reviewer-approved posts to a page, comments read back, human approval before any reply. The approval clause helps in review.
- Sign In with LinkedIn is self-serve; request it at the same time.
- Review takes weeks and blocks nothing else here. File first, build in parallel.
Engineering contract
- flow
- OAuth 2.0 three-legged; a page admin consents on LinkedIn's screen.
- tokens
- Belong encrypted per workspace in
IntegrationCredential— a table that today has no reader and no writer. - headers
LinkedIn-Versionpinned per release; versions retire on a published cadence.- reversal
- Narrows FR-707 to "publishes only an approved item, on an explicit action". The gate is untouched.
- verify
- Tiers, lifetimes and throttles here are working knowledge — confirm in the portal.
Defects to clear first
Read from the source. None are LinkedIn-specific — all would surface as "the LinkedIn integration is broken". Three are severity one.
The ledgernine, by severity
Rendered media 404s in production
Renders write to local disk; production serves from object storage. Every generated asset is unreachable once deployed.
Only one worker can run
Boot recovery is global, not instance-scoped, so a second worker reaps the first's live jobs.
Scrapes and renders write no job record
JobKind has nine values; only RESEARCH is written. Scrapes and renders create no row — so the spec marks NFR-09 live while two of three job kinds have nothing to recover.
Nobody can be invited to a workspace
Every sign-up makes an isolated org with no way to add anyone, so generate-then-someone-else-approves cannot happen. Four permissions appear in the UI with no route behind them.
The test suite cannot reach the database
CI runs tests before migrations, so no schema exists while they run. Zero tests touch the database — the approval machine, the queue, the SSRF allowlist and the signed-file HMAC are all unverified.
No cost is ever recorded
ProviderRun.costUsd exists and is never written. Quotas, plans, trials and pricing all rest on that empty column.
Roughly 15% of the schema is dead
PromptTemplate has a screen but no route. IntegrationCredential is unused — and it is exactly where LinkedIn's tokens belong. Three more models and one vector column are never written.
Two integrity rules have no database backstop
Nothing enforces that an Approval has exactly one target. And MemoryChunk.companyId has no foreign key — a deleted company leaves its passages quotable.
The web container image cannot build
The web Dockerfile copies a public directory that does not exist. The image build should be failing.
The honest read. The architecture is sound and roughly 85% substantive — the work outstanding is completion, not correction. But the three severity-one items must clear before LinkedIn work is worth deploying.
Listening, if you want it
Optional and separately licensed. The only route to the capability §00 shows has no crossing: a component you licence plus one integration you build.
An undetectable Chromium fork with the recipe runtime and LinkedIn catalog. Built, running, and maintained by us — including repair when LinkedIn changes its internals, the part that otherwise rots.
Lift the session from a browser your user is already signed into and load it into the agent profile. Small and self-contained — no password is typed into software you don't control.
What sits on each side of the line
In the licenceours
- Undetectable Chromium fork on a real logged-in profile.
- Reads by replaying LinkedIn's own internal API, not scraping the DOM — the difference between weeks and years of half-life.
- Verified recipes already running — plus
linkedin:search, the one this brief adds. - Rate floors, not defaults — enforced across processes, no caller can opt out.
- Recipe maintenance — the ongoing work, on our side.
- Profile isolation — one directory per workspace; tenants cannot read each other.
On your sideyours · about a week
- Export the session cookies from the user's own signed-in browser.
- Transport it to the agent profile. A session, not a password — it expires, and the user can revoke it.
- Load and probe. A successful read is the only thing that marks a connection live.
- Re-import in one action — and the product must ask. A silent empty feed is the failure to avoid.
- Plus three small AMI changes: one backend, three optional fields, a connect/reconnect surface.
Stated plainly, because it will be asked
The trade
- Automated collection is contrary to LinkedIn's User Agreement. Decide it deliberately; record it.
- Reverses FR-402, a Must. Narrowly: the session is the customer's, the product stores a profile not a secret.
- The account carries ban risk — whose account it is matters more than anything technical here.
- Search at volume is a different traffic pattern from posting. Start low, measure.
What makes it defensible
- Nothing is published by it. Every word reaching LinkedIn goes through the official API after approval.
- No credential is stored — by AMI or by us.
- It fails loudly — with a reason, never as an empty result.
- It degrades — falls back, and records which backend served.
One thing is unproven. Every existing recipe covers your own surface. Keyword search is the one this brief adds, and the only part not already running. The spike is hours — until it returns, treat §03 as a proposal.
Two shapes this can take
A floor and a ceiling, not alternatives. Do both — in an order that puts what you don't control first.
| A · page only | B · plus listening | |
|---|---|---|
| Data source | Community Management API only. | The API, plus the licensed chrome-agent browser for public posts. |
| AMI can | Publish approved posts to the page; read comments, reactions and mentions back; post approved replies. | All of A, plus: search public conversations, triage them, and draft grounded replies to people who never mentioned you. |
| Social Listening | Ships disabled for LinkedIn, with an honest message. Reddit keeps working. | Ships working. |
| Terms posture | Fully sanctioned. Nothing to explain to anyone. | Needs a recorded decision. The session and its risk belong to the customer. |
| Commercial shape | One gated API application. No third-party licence. | Adds a licence for the browser and a cookie import you build — about a week. |
| Blocked by | LinkedIn's review — weeks, outside our control. | Nothing. Buildable now, in parallel with the review. |
| Who maintains it | You. LinkedIn's API is versioned and stable. | Split: recipes are ours — we repair them when LinkedIn changes. The import and the wiring are yours. |
| Recommendation | Do both, in this order. File the application this week — that clock isn't yours. Clear the three S1 defects while it reviews. Run the spike in parallel; it costs hours and is the only thing here that could change the answer. | |
Sequence
Nothing waits on anything it needn't. Only the last step needs a decision not yet taken.
File the application
App under a verified Company Page; Sign In is self-serve. Review starts the day you file, not the day you are ready.
Prove the listening path
Search by hand in the fork, capture the call, replay it. Confirm posts by strangers return author, body, timestamp.
Clear the three severity-one defects
Storage driver on the write path; instance-scoped recovery; job rows for scrapes and renders. Plus the two-line CI fix.
The official adapter
OAuth connect, encrypted tokens, publish and read-back behind the existing gate. Independent of §03.
Chrome agent and cookie import
Only if §04 is B. Licence the browser, build the import, wire the backend and the reconnect surface.
Three questions, all commercial before technical. Whose Company Page owns the app. Whose LinkedIn account the session belongs to — i.e. who absorbs the risk. And whether option B is taken at all.