Step 3 · Bring in your vendors

Available now You invite vendors and grant their apps yourself, on the portal's

Your house: vendors page. How it works, click by click, is in Bring your vendors into your house. This page is about what to decide.

Brief each vendor

Send each vendor, before you invite it:

1. Their part of your newsroom map: what their product must publish and receive, and in which flows (step 1).
2. Their ids: the system_ids you expect them to stamp, and your naming.
3. Your house rules (step 2).
4. What "ready" means to you: the readiness checklist lines for their role, the test runs you expect a results statement for, and the workflows from step 4.
5. For a skill vendor: the skills you want to run, with your values (Configuring your house's skills).
6. A date for the joint run.

Point them to Integrate as a vendor. Ask them to work through it in their own vendor workspace, and to share a results statement with your organisation, before the joint run.

Invite them

By email, or from the vendor directory for vendors that chose to be listed. A vendor new to the bus gets a pre-approved sign-up with the invitation. See Invite a vendor, and the vendor's side in Join a publisher's house.

Grant the minimum

Each vendor app asks for what it needs; you grant that, or less (Decide on a connection). Give each only the message types its role needs, and only its own system_ids. It does two things:

• A vendor's product can't speak as another of your systems. The bus refuses a message stamped with a system_id the connection wasn't granted (producer.system_id_not_allowed).
• You learn early when a product sends what it shouldn't (producer.message_type_not_allowed): a graphics engine that tries to publish its own story.context, or to clear its own standards gate.

If the vendor shared a results statement for that app with you, the request shows it, so you see what the app passed before you grant it. After granting, check your routing map: each system on the right of your flow map should now be listed as a receiver.

When a product doesn't support SOM yet

Common, and fine for an evaluation. In order of preference:

Option	Who builds	Trade-off
Native SOM in the product	The vendor	Best, but on their roadmap
An adapter from the product's own API or events	The vendor, you or a third party	Fast; someone owns the adapter
An RND stand-in plays the role in your rehearsals Available now	RND	Your workflows run end to end while you wait; the gap stays visible
Leave it out, and publish its messages with a script	You	The rest of the house moves; the gap stays visible

An adapter or a script is an app like any other, held to the same checks.

What you see of a vendor

Counts per connection (accepted, refused, duplicate, last seen), never its rule ids or refused messages, unless it shares a results statement with you. See Who sees what in a house. That's why step 6 asks vendors for evidence.

Next: Step 4 · Rehearse workflows end to end.