Vendorian vendor sync

Vendorian is where your organization manages its vendors. The Vendorian integration mirrors those vendors into Componecat as catalog entities, so you can relate a component to the third parties it depends on — payment-gateway depends on vendor://vendors/stripe — and see that context alongside everything else in the catalog.

Vendorian stays the system of record. Componecat copies a vendor’s core details on a schedule and keeps them read-only; everything you add around a vendor in the catalog — owners, relationships, documentation — is yours.

Vendor sync is the Entity sync capability on a Vendorian integration. See Integrations for how connections and capabilities work in general. It needs a plan that includes integrations (Pro or Enterprise).

Set up a service account in Vendorian

Componecat signs in to Vendorian as a service account, not as a person.

In Vendorian, open Organization settings → Service accounts and create a service account for Componecat.
On that service account, create an OAuth client with Vendors: Read access, organization-wide. That is the only access Componecat needs.
Copy the client id and client secret. The secret is shown once.

Componecat exchanges the client id and secret for an access token using the OAuth client credentials flow. One connection reads one Vendorian organization — the one the service account belongs to.

Connect Vendorian

In Componecat, go to Organization settings → Integrations and choose Add integration, then Vendorian.

Enter:

Field	Value
Base URL	Your Vendorian address, for example `https://vendorian.example.com`.
Client ID	The OAuth client’s id.
Client secret	The OAuth client’s secret. It’s encrypted and never shown again.

Choose Test connection. A successful test means Componecat could sign in and list vendors. If the test passes but says no vendors are visible, the service account can sign in but its Vendors access doesn’t reach any vendor. Check that it has Vendors: Read for the whole organization.

Enable entity sync

Open the integration and find the Entity sync card. Review the settings before you switch it on — the first run uses them.

Setting	Default	Meaning
Target kind	`vendor`	The kind vendors are created as.
Namespace	`vendors`	The namespace in each vendor’s reference, such as `vendor://vendors/acme`. Changing it moves the vendors already synced into the new namespace on the next run.
Default owner team	Your Default team	The owner given to newly created vendor entities. You can change each vendor’s owner afterwards.
Statuses to sync	Every status except Draft	Only vendors with these Vendorian statuses are mirrored.
Schedule (cron)	Hourly	How often the sync runs.

Use Run now after enabling to see the first results straight away instead of waiting for the schedule.

The vendor kind

When you enable the capability, Componecat makes sure the target kind exists and has the fields the integration writes:

No kind with that key — Componecat creates it, with documentation and an activity log turned on.
You already have a kind with that key — Componecat adopts it. Its name, icon, color, and features stay as you set them; only missing fields are added.
A field with the same key already exists — fields are shared across your organization, so an existing field of the same type is reused rather than duplicated.
A field with the same key but a different type — enabling is refused, and the error names the field. Rename that field’s key and try again. Nothing is created until the conflict is resolved.

Fields the integration adds aren’t required, so you can still create vendor entities by hand.

While the integration exists, the kind and the fields it uses are protected. You can’t delete them, change their key or type, remove a field from the kind, or remove a select option the integration relies on. Everything else is yours to edit: names, descriptions, icons, colors, feature toggles, extra fields of your own, and making a field required. On the Entity Kinds and Field Definitions pages, the kind and its synced fields carry a Used by Vendorian sync badge; hover or focus it to see which integration uses them and what’s protected. The protected actions are turned off there, each with a tooltip saying why.

What syncs

Each Vendorian vendor becomes one entity of the target kind.

In Componecat	From Vendorian
Display name (and the name in its reference)	The vendor’s name
Description	The vendor’s description, up to the first 500 characters
Lifecycle	The vendor’s status — see below
`legalName` (text)	Legal name
`vendorStatus` (select)	Status: Draft, Active, On hold, Inactive, or Terminated
`vendorCategory` (text)	Category
`businessType` (text)	Business type
`industry` (text)	Industry classification
`website` (URL)	Website
`contactEmail` (text)	Email
`country` (text)	Country
`erpVendorId` (text, searchable)	External (ERP) vendor id

Lifecycle follows the vendor’s status:

Vendorian status	Lifecycle
Draft	Development
Active, On hold	Production
Inactive	Deprecated
Terminated	Retired

A value cleared in Vendorian is cleared in Componecat on the next sync.

Some vendor data is deliberately not mirrored: tax id, phone, street address, risk assessments, contacts, agreements, and spend. They aren’t catalog concerns, and they stay in Vendorian.

Editing a synced vendor

The values in the tables above are read-only in Componecat. They show a Managed by Vendorian label linking to the vendor in Vendorian — change them there, and the next sync brings the change across.

Everything else on a vendor entity stays editable:

its owner team and tags;
fields that aren’t synced, including ones you’ve added to the kind;
relationships — relate your components to the vendors they depend on;
documentation and interfaces.

A synced vendor can’t be deleted in Componecat. To stop mirroring a vendor, filter it out with Statuses to sync, or release it.

Releasing a vendor

An admin can Release a synced vendor from its page. Its values become editable, and it’s an ordinary entity from then on. Its relationships and documentation are kept.

Releasing is permanent. Later syncs skip that vendor even if it still exists in Vendorian, and they never create a second entity for it. To bring a released vendor back under sync, delete the entity; the next sync creates it again.

How vendors are matched

Componecat tracks each vendor by its Vendorian id, not by its name. Renaming a vendor in Vendorian renames its entity here, and its relationships and documentation follow. If the new name is already taken, a numeric suffix is added (acme-2).

If you entered vendors by hand before connecting Vendorian, you don’t need to start over. On its first sync, a vendor is matched to an existing entity of the target kind with the same name in the same namespace, and that entity is adopted: it keeps its relationships, documentation, and owner, and its synced values come from Vendorian from then on. An entity managed by a descriptor or by another integration is never adopted — the run records an error for that vendor instead.

An entity is managed by either a descriptor or an integration, never both. A componecat.yaml descriptor that points at a synced vendor isn’t ingested.

Vendors that disappear

When a vendor is deleted in Vendorian, or no longer matches Statuses to sync, its entity is marked No longer in Vendorian. It isn’t deleted and its lifecycle isn’t changed, however long it stays missing — relationships to a vendor you’ve stopped using are history worth keeping. Retire, release, or keep it as you see fit.

If the vendor comes back, the entity goes back to syncing.

Sync history

The Entity sync card lists recent runs with the number of vendors created, updated, unchanged, adopted, and missing, and any errors. Errors are per vendor, so one vendor that fails — an invalid value, a name collision — doesn’t stop the rest of the run.

Each vendor created counts toward your plan’s catalog entity limit. Once you reach it, new vendors are recorded as errors and existing ones keep updating. See Plans and limits.

Remove the integration

Deleting the Vendorian integration stops syncing and lifts the protection on the kind and its fields. The kind, its fields, and every vendor entity stay in the catalog as ordinary data you can edit or delete.

Troubleshooting

Test connection says the credentials are invalid. The client id or secret is wrong, or the OAuth client was deleted or its secret rotated. Create a new secret in Vendorian and enter it on the integration.
Test connection fails with 403. The service account’s OAuth client doesn’t have Vendors: Read. Grant it organization-wide in Vendorian and test again.
Enabling fails with KIND_SPEC_CONFLICT. A field in your organization has the same key as one the integration writes, but a different type. The error names the field — rename its key, then enable again.
Some vendors are missing. Check Statuses to sync; Draft vendors are excluded by default.
A vendor shows an error in the history. Open the run to read it. A common cause is a field you’ve narrowed since it was added — for example a URL pattern on website that a vendor’s value doesn’t satisfy.
I can’t edit or delete a vendor’s field. Synced values are read-only; edit them in Vendorian. To take a vendor out of sync entirely, release it.

Integrations — connecting a provider and the shared capability controls.
Entities and kinds — kinds, fields, and references.
Relationships — relating components to the vendors they depend on.
Plans and limits — integrations and the entity limit.