Connectors#
A connector is a bidirectional link to an external system. Every connector defines two contracts:
- A source contract — capture changes out of the system into Stream.
- A destination contract — write records into the system through Forge Load, with snapshot/verify/rollback preserved.
The matrix#
| Connector | Source | Destination | Auth |
|---|---|---|---|
| Salesforce | ✓ | ✓ | OAuth 2.0 |
| HubSpot | ✓ | ✓ | OAuth 2.0 |
| Stripe | ✓ | ✓ | API key |
| JIRA | ✓ | ✓ | Basic (email + token) |
| Zendesk | ✓ | ✓ | Basic (API token) |
| NetSuite | ✓ | ✓ | Token-Based Auth |
| Dynamics 365 | ✓ | ✓ | OAuth 2.0 (app-only) |
Connect any of them from the Connect your systems guides.
Event hub: Slack and Microsoft Teams are also full bidirectional connectors (post/capture messages), and Forge can bridge a Teams channel and a Slack channel with provable loop-prevention.
In preview#
Built on the same framework and mock-tested end to end, pending live verification against a customer sandbox — available on request:
| Connector | Source | Destination | Auth |
|---|---|---|---|
| Shopify | ✓ | ✓ | Admin API token |
| ServiceNow | ✓ | ✓ | Basic (Table API) |
| Marketo | ✓ | ✓ | OAuth 2.0 (client credentials) |
| Snowflake | ✓ | ✓ | OAuth bearer |
| Google Sheets | ✓ | ✓ | OAuth 2.0 |
| Workday | ✓ | ✓ | OAuth 2.0 (refresh token) |
Accounting / ERP / billing family:
| Connector | Source | Destination | Auth |
|---|---|---|---|
| QuickBooks Online | ✓ | ✓ | OAuth 2.0 (Intuit) |
| FreshBooks | ✓ | ✓ | OAuth 2.0 |
| Sage Intacct | ✓ | ✓ | Web Services session |
| Sage X3 | ✓ | ✓ | HTTP Basic (Syracuse) |
| Sage 300 | ✓ | ✓ | HTTP Basic (Web API / OData) |
Each implements the full source + destination contract with the same credential handling, error taxonomy, and snapshot/verify/rollback discipline as the live connectors — the live-verification step confirms each system's per-object quirks (natural keys, change-feed shape) against a real tenant.
How credentials are handled#
Every connector reads its credentials from a per-tenant credential store at the moment of use — never from environment variables, never cached across tenants. The store uses an encrypted backend (HashiCorp Vault, with an encrypted-Postgres fallback so a Vault outage never wedges a connector). Credentials are never returned by any API, never logged, and scrubbed out of every error message before it reaches a log or a dead-letter.
The error taxonomy#
Connectors classify failures consistently so the platform reacts correctly:
- 401 / 403 → permanent. Auth or permission is wrong — abort, don't retry against the system's auth and risk a lockout.
- 429 / 503 → transient. Back off and retry.
- Validation (the system's own 400/422) → data error, naming the offending fields so you can fix the mapping.
Honesty about deletes#
A connector's delete doesn't just trust a 2xx. It confirms the record is actually gone (read-after-delete), so a rollback never reports a delete that didn't happen — a real bug this discipline caught and fixed in HubSpot.
Note: Adding a new system is a recipe, not a rewrite — implement the source + destination contracts and the connector inherits the credential store, taxonomy, and snapshot/rollback machinery.