Integrations
Systems that write here
Plenty of systems generate documents nobody reviews. Bladbase is where that output becomes something a person can read, argue with and approve — and where the approval is a record rather than a claim.
What a system gets
Its own membership
A system joins the workspace as a service member with a role, not as a person’s login. The trail reads “MarketPilot drafted · you approved”, which is the only version worth having.
An identifier that survives
Stamp your own durable id on a page and republishing updates that page instead of making a second one. Two findings with the same title stay two pages.
A gate it cannot open
A brief waits at “awaiting review” until a person moves it. Any later edit withdraws the approval, so “approved” always refers to words somebody actually read.
A cursor, not a crawl
Ask for what changed since the last instant you saw, oldest first. A watcher advances without re-reading the workspace.
Events, not polling
Subscribe to page and comment events and get a signed POST when an approval lands — retried, logged, and switched off if your endpoint stops answering.
A trail either side can read
Every write, status change and comment becomes an activity record with the principal that caused it. Your audit claim stops being an assertion.
All of it is the same MCP surface a coding agent uses — no second API, no glue service, no shared database. The only coupling is a token and an identifier. The tool reference is generated from the running service, so it cannot drift from what the server accepts.
The worked example: MarketPilot
MarketPilot (marketpilotseo.com) is a separate product from the same team — an AI marketing and SEO platform. It is not part of Bladbase and not bundled with it. It is here because it is the first system to write into a Bladbase workspace, and because building it is what shaped the integration surface everyone else gets.
MarketPilot crawls a client’s site and its competitors, scores the difference, and turns each finding into one scoped brief with acceptance criteria. Its promise to clients is that AI does the reading and the drafting while people do the deciding — and that promise needed somewhere the deciding visibly happens. A brief in its own dashboard had no comment thread, no revision history, and no record of who approved what.
MarketPilot finds something
A scan turns a finding into an implementation brief.
It publishes the brief here
Created against its own fingerprint, typed as a brief, awaiting review.
A person decides
Reads it, comments, approves or rejects — in Bladbase, or mirrored from MarketPilot’s own portal.
The work happens
A coding agent reads approved briefs over MCP and does them.
The next scan re-measures
Nothing is marked done on an AI’s say-so; the underlying signal decides.
Two things integrating taught us
Both are invisible from a tool description, and the next system to connect would have hit them too, so they are worth stating here rather than in a changelog.
Identity has to outlive the run
A per-run id is regenerated every scan, so pages published in March cannot be found from the same finding in June. What goes on the page is a fingerprint that is stable by construction — which is why the API asks for durable identity rather than only retry-safety.
Never echo a status back
Read a page, revise it, republish it, and a naive client re-states the status it read earlier — quietly undoing the person who moved it in between. Declare the type once and leave the lifecycle to the people who own it.
Bring your own system
- Add it to a workspace as a service member with the role it should have.
- Mint a token for it, scoped to read, write or publish.
- Publish against your own identifier so republishing updates rather than duplicates.
- Subscribe to a webhook, or poll for what changed, and act when a person approves.
Questions people actually ask
How does an external system publish into a workspace?
It connects over MCP with a token bound to a service member, then creates or updates a page. The token decides the workspace and the permitted scopes, so the same endpoint serves every workspace without the caller naming one.
What stops a second run creating a duplicate page?
A durable external identifier. The system stamps its own id on the page, and a later run upserts against that id — so a re-publish updates the page it wrote before, and a page a person archived stays archived rather than quietly returning.
Can an integration approve its own work?
No. Publishing and approving are separate permissions, and a token without the publish scope cannot open the gate it is waiting at. That separation is the whole point of routing machine output through review.
References
- Model Context Protocol specification — the protocol an integration speaks
- MarketPilot — the worked example on this page