Examples

Two complete configs you can copy, paste into PATCH /draft, and publish. Both are syntactically valid (CI runs ConnectorConfigV3.model_validate on each on every push).

1. compass-light - simple mode

_examples/compass-light.json is the smallest possible useful config: one entity (company), one schema (hubspot), four field mappings, one inbound flow.

Read top to bottom:

• version: "3.0" - pinned.
• entities[0].name = "company" - the entity name; steps reference it.
• entities[0].schemas.hubspot - the only schema. Because there is exactly one schema and it is named hubspot, infer_entity_mode returns simple. The dashboard renders the single-schema editor.
• schemas.hubspot.identity = {"strategy": "match_or_create", "property": "hs_tax_id"} - HubSpot side does a lookup by hs_tax_id; if no company has that tax id, create one. See entities.md “Identity”.
• field_mappings[] - read from $.payload.* directly (the inbound webhook body), no canonical hop.
• flows[0] matches (source: "compass_inbound", event_type: "upsert_company"), with event_type_from: "$.event" recording the payload path that carries the event type. The single step upsert_hubspot upserts the whole payload into the company schema via data: "$.payload".

To deploy this config:

curl -X PATCH https://app.plugsync.com/api/connectors/<id>/draft \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d @docs/content/reference/config-v3/_examples/compass-light.json

Then publish from the dashboard (“Review changes” -> “Publish v1”).

2. fooshop - federated mode

_examples/fooshop.json is the real config that (internal plugsync tooling - see the source repo) builds. The setup script remains the canonical source; the JSON here is a snapshot.

Key features:

• Two entities (contact, order), both classified federated by infer_entity_mode because each has two schemas (fooshop and hubspot).

• The flows transform from the source schema into a canonical shape via the $.canonical.* JSONPath, then upsert from canonical to HubSpot:

  {"id": "to_canonical", "action": "transform", "entity": "contact",
   "from_schema": "fooshop", "to_schema": "canonical"}

  followed by an upsert against target: "hubspot" that reads $.canonical. The fooshop_signup flow has exactly this pair (one transform + one upsert). The fooshop_order_paid flow extends the pattern: two transform steps (one for contact, one for order), a plugin step (compute_shop_stage from plugins.fooshop.shop_stage) that enriches the canonical state in between, and two upsert steps (contact then deal, with the deal carrying an associations entry that links it back to the upserted contact).

This hub-and-spoke pattern is the standard shape for any case where multiple sources need to converge on a single target representation (or vice versa). See simple-vs-federated.md for when to reach for it, and step-actions.md for the per-action reference.

Validating your own config

The validator that runs in CI is callable standalone. Drop your JSON next to the existing examples and run:

(internal plugsync tooling - see the source repo)

(You’ll also need to add an entry to EXPECTED_MODES in validate.py for the new file.)