Salesforce

Stream Salesforce objects into Streamkap with a service account (client credentials), or by connecting with Salesforce over OAuth

The Salesforce source pulls objects — accounts, contacts, opportunities, and more — out of your Salesforce org and streams them into Kafka topics, one topic per object. Records land flat in your destination like any other Streamkap source, so every existing destination consumes them unchanged.

How It Works

1. Authentication — Streamkap connects to your org one of two ways. With Service account (client credentials) — the default — you create an External Client App in Salesforce and give Streamkap its Consumer Key and Consumer Secret; Streamkap reads your org as the app’s run-as user. With OAuth (Connect with Salesforce) you authorize Streamkap in a Salesforce consent screen and it syncs with the access you grant. See Authentication options.
2. Incremental sync — On the first run each selected object is read in full. After that, the connector polls on a schedule and fetches only records whose SystemModstamp moved since the last poll, tracking a per-object cursor.
3. Deletes — A periodic sweep finds records deleted in Salesforce and emits a delete marker (__deleted = true) so downstream sinks flip the row to deleted. The sweep depends on the Recycle Bin; a slower daily reconciliation pass backs it up for deletes that age out of that window — see Deletes and tombstones.
4. API allocation — Salesforce enforces a rolling 24-hour API request allocation for the whole org. The connector paces itself to leave headroom for your other integrations (see Behavior & Limits).

Each object you select produces a topic named source_<id>.salesforce.<Object> — for example source_<id>.salesforce.Account. Object names are case-sensitive API names, so the topic carries the object’s API name exactly.

Authentication options

Streamkap authenticates the Salesforce source one of two ways. The Authentication dropdown on the Auth tab offers both; you choose when you create the connector.

Service account (client credentials)

The default — the form opens on this option. You create an External Client App in Salesforce and give Streamkap its Consumer Key and Consumer Secret; Streamkap reads your org as a fixed run-as user through the OAuth client-credentials flow. Choose it when the connection should belong to a service identity you control rather than to a person’s login, which is usually what a production integration needs. It is the more involved path: you build the app in Salesforce first (Salesforce Setup), then enter its credentials in Streamkap.

It is also the only path that takes your My Domain URL directly, so it is the one to use if your org’s My Domain policy blocks the standard Salesforce login host.

OAuth (Connect with Salesforce)

The quicker path, with nothing to create in Salesforce. You pick your org’s environment — Production or Developer Edition, or Sandbox — then click Connect with Salesforce, approve Streamkap’s access in a Salesforce consent window, and the connection is established. There are no keys to create and none to paste. Streamkap syncs with the access the authorizing user granted and keeps that authorization refreshed on its own; if it is ever revoked or expires, the source prompts you to reconnect (see Reconnecting an OAuth connection).

Prerequisites

• A Salesforce org.
• A Streamkap workspace with permission to create source connectors.
• For a service account: permission to create an External Client App in Setup, and a run-as user in that org with read access to every object you want to sync.
• For Connect with Salesforce: a Salesforce login that can grant Streamkap read access to the objects you want to sync.

Salesforce Setup

1. Create an External Client App

1. In Salesforce Setup, use Quick Find to search for External Client Apps Manager, and select it.
2. Create a new external client app and give it a name (for example Streamkap).

2. Enable OAuth and the client-credentials flow

1. From the app’s actions dropdown, select Edit Settings.
2. In the OAuth Settings section, select Enable OAuth. The section expands.
3. Select the OAuth scope that grants API access (the api scope). Streamkap only reads — it never writes to your org.
4. Select Enable Client Credentials Flow.
5. Save.

3. Assign the run-as user

1. On the app, select Edit Policies.
2. Under Client Credentials Flow, set Run As to the user Streamkap will read your org as.
3. Save.

4. Grant the run-as user read access to your objects

Give the run-as user read access to every object you plan to select in Streamkap — through its profile, or through a permission set you assign to it. Both work; a permission set is easier to audit because it names the objects in one place.

Read access is enough. Streamkap never creates, updates, or deletes records in your org.

If you skip an object here, the source still saves — but that object fails on its first poll, and Salesforce’s error does not distinguish “missing permission” from “no such object”. Streamkap’s Test connection catches this before you save. See An object can’t be seen.

5. Copy the Consumer Key and Consumer Secret

1. Open the app’s Settings tab and expand OAuth Settings.
2. Open Consumer Key and Secret and copy both values.
3. Keep them handy for the Streamkap setup below — treat the Consumer Secret like a password.

6. Find your My Domain URL

1. In Salesforce Setup, use Quick Find to search for My Domain (under Company Settings).
2. Copy your org’s My Domain URL. It looks like https://acme.my.salesforce.com.

Streamkap Setup

Follow these steps to configure your new connector:

1. Create the Source

• Navigate to Add Connectors.
• Choose Salesforce.

2. Connection Settings (Auth tab)

• Name: A name for your connector (for example salesforce-prod).
• Authentication: How Streamkap authenticates — Service account (client credentials) (the default) or OAuth (Connect with Salesforce). See Authentication options. The rest of the form follows your choice.

Service account (client credentials)

Enter the credentials from your Salesforce Setup:

• Consumer Key: The Consumer Key from your External Client App.
• Consumer Secret: The Consumer Secret shown beside it. It is stored encrypted at rest and never shown again.

OAuth (Connect with Salesforce)

Pick the Salesforce environment — Production or Developer Edition (preselected) or Sandbox — then click Connect with Salesforce. A Salesforce window opens; sign in if you are prompted and approve Streamkap’s access. When it closes, the Auth tab shows a Connected chip — there is nothing to paste. Streamkap knows your org from the authorization, so you do not enter a My Domain URL.

3. Settings tab

• My Domain URL (service account only): Your org’s My Domain URL, for example https://acme.my.salesforce.com. Not needed with Connect with Salesforce — Streamkap already has your org from the authorization.
• Objects: The Salesforce objects to sync, picked from the eight standard objects. The default selection is Account, Contact, Opportunity and Lead. See Supported Objects, and Custom objects for syncing your own.
• Backfill start date (optional): The earliest record modification time to sync, as an ISO-8601 date or datetime — 2026-01-01, or 2026-01-01T00:00:00Z. A value with no timezone is read as UTC. Leave it empty to sync all history. See Backfill start date.

The panel beside the form lists the Kafka topics your selection will produce — one topic per object.

Optionally click Test connection. With a service account this runs a read-only check against Salesforce — nothing is created or written — and reports one of:

• Connection verified, with the Salesforce org the connection belongs to. Worth a glance: it confirms Streamkap is pointed at the org you meant.
• Connection failed — the credentials were rejected, the app does not enable the client-credentials flow, or it names no run-as user. Salesforce answers all three the same way, so check each.
• Some resources need attention — the credentials work, but the run-as user cannot read one or more of the objects you selected (or the object name is wrong). The result names each object, so you can fix the permission set without guessing.

Testing is optional. Streamkap runs the same checks again when you save, whether or not you tested.

4. Review and create

The last step of the wizard is Review. It lists everything you entered, with secrets masked. Click Create.

With a service account, Streamkap validates the credentials and probes every selected object against Salesforce before the source is created — a bad credential or an unreadable object is rejected here with an actionable message, before anything is saved.

Editing the Source

An existing Salesforce source has Status, Auth, Settings, Destinations and Config History tabs, plus a Logs link. There is no Schema tab: an API source has no table schema to include or exclude, and it does not expose a schema snapshot.

The Auth tab reflects the method the source was created with — a Reconnect Salesforce control for a Connect with Salesforce source, or the stored Consumer Secret for a service account.

Reconnecting an OAuth connection

A source created with Connect with Salesforce stays authorized on its own — Streamkap refreshes the authorization automatically, so a healthy OAuth source needs nothing from you.

If the authorization is revoked in Salesforce (Setup > Connected Apps OAuth Usage) or otherwise expires, syncing stops and the Auth tab shows a re-authenticate prompt. Pick the Salesforce environment the source connects to, click Reconnect Salesforce, and approve Streamkap’s access in the Salesforce window as you did at setup. Syncing resumes from the last cursor — no data is lost.

Rotating the Consumer Secret

The Consumer Secret is write-only. It is never displayed again, so the Auth tab shows it as stored rather than as a value. Leave it untouched and Streamkap keeps the credential it already holds; click Replace and type a new one to rotate it.

Saving a replacement secret takes effect immediately: it clears an authentication failure in one step, without waiting for the automatic retry.

Test connection works here too, and tests the stored credentials — you do not need to re-enter them just to check that they still work. This is the quickest way to confirm a Broken source is a credential problem rather than a permission one.

Adding objects

Add or remove objects on the Settings tab at any time. A newly added object is read in full on its first poll, then goes incremental like the others. Removing an object stops its topic; the data already delivered to your destination is untouched.

Sending Topics to a Destination

Salesforce topics reach a destination without you building a pipeline by hand. Streamkap creates and maintains the pipeline for you — the Pipelines list labels it Auto-managed.

You can start from whichever end you are already looking at:

• From the source — open its Destinations tab, click Send topics, pick a destination.
• From the Topics page — select the topics you want and choose Send to destination.
• From the destination — open it and click Add topics.

To stop delivering a topic, remove it from the source’s Destinations tab — Detach all clears a destination in one go. Removing the last topic removes the destination from the source entirely.

Supported Objects

Select any of the eight standard objects:

Custom objects

Streamkap syncs Salesforce custom objects too. A custom object is identified by its API name, which always ends in __c — for example Warehouse__c, or acme__Invoice__c if it comes from a managed package. Anything that is neither a standard object nor a __c name is rejected when you save.

The API name is not always the label you see in the Salesforce UI. Find it in Setup under Object Manager, on the object’s detail page.

A custom object syncs exactly like a standard one: a full first read, then incremental on SystemModstamp, and the same delete sweep — a deleted custom-object record becomes a tombstone in your destination like any other. See Deletes and tombstones, whose Recycle Bin bound applies to custom objects too.

Behavior & Limits

Incremental sync

After the initial full read of each object, every poll fetches only records whose SystemModstamp moved since the last cursor position. A poll where nothing changed in Salesforce produces zero new records — this is expected, not a fault.

Backfill start date

By default the first sync of an object reads all of its history. When you don’t want years of records you will never query, set a Backfill start date on the Settings tab: the first sync starts from that instant instead, and records whose SystemModstamp is older are never fetched.

The value bounds the first sync of each object and nothing else. Once an object has synced, the connector resumes from its own cursor and the backfill start date no longer applies to it — raising it later hides nothing, and lowering it reaches no further back. An object you add on the Settings tab afterwards is new, so its first sync uses whatever the value is at that point.

Deletes and tombstones

Streamkap detects deletes two ways, and both cover every object you sync — the eight standard objects and custom objects alike.

The delete sweep. When a record is deleted in Salesforce, a periodic sweep (roughly every 6 hours) detects it and emits a record with __deleted = true, so your destination’s tombstone/delete handling flips the row to deleted. Expect deleted records to surface within one sweep interval. The sweep reads deletes out of Salesforce’s Recycle Bin, which retains them for about 15 days.

Reconciliation. A slower reconciliation pass — about once a day — backs up the sweep for deletes that aged out of the Recycle Bin before Streamkap could read them (for example, a delete that happened while the connector was down for longer than the retention window). It re-lists the live records for each object and tombstones any that have disappeared, so the delete still surfaces once the connector is running again.

Formula and roll-up summary fields

Salesforce does not bump a record’s SystemModstamp when the computed value of a formula or roll-up summary field changes because a record it references changed. The record has changed as far as your users are concerned, but Salesforce reports it as untouched.

Any incremental sync that keys on SystemModstamp — Streamkap’s included — is therefore blind to that change. This is inherent to the Salesforce API, not something Streamkap can work around: Salesforce simply never tells us.

What to do about it:

• Sync the referenced object instead. A roll-up on an Account that sums its Opportunities does move when an Opportunity moves — so sync Opportunity and compute the roll-up in your warehouse, where it will be correct and current.
• Re-snapshot when you need the computed values to be right. Removing an object from Objects and adding it back reads it in full again, refreshing every formula value.
• Records that change for any other reason still carry their current formula values. The gap only affects records whose sole change was a formula recomputation.

Compound and binary fields

Salesforce exposes an address twice: once as a nested object (BillingAddress) and once as flat components (BillingStreet, BillingCity, BillingState, BillingPostalCode, BillingCountry). Streamkap syncs the flat components, and skips the nested object.

The components carry the same data, and they land cleanly in relational destinations that cannot store a nested object in a column. The same applies to geolocation fields, which also have flat components.

Binary (base64) fields are skipped for the same reason — they are blobs, not the flat scalars every destination expects in a column. Every other field on the object is synced, discovered from Salesforce rather than hardcoded, so your own columns come along without a Streamkap change.

New and custom fields

Because the field list is read from your org rather than hardcoded, a field you add to an object you already sync is picked up on its own — there is nothing to reconfigure in Streamkap, and no setting to turn on.

Streamkap re-reads an object’s field list periodically rather than on every poll, so a newly added field can take up to about an hour to start appearing. That is deliberate: re-reading the schema every poll would roughly double the connector’s share of your org’s API request allocation for a schema that changes monthly, not by the minute.

New fields are added to your destination table automatically when the destination evolves its schema, which is the default. If a destination is set not to evolve, its existing columns stay as they are and the new field arrives on the topic without being added to the table. See Schema Evolution.

A new field is only populated for records that change after you add it — Salesforce does not move SystemModstamp for the rest. See Incremental sync.

API request allocation

Salesforce enforces a rolling 24-hour API request allocation for the whole org — shared by Streamkap and every other integration you run. Streamkap paces its requests below what the org can serve, so a sync does not monopolize your allocation.

If the org’s allocation is exhausted anyway, the connector pauses ingestion rather than burning what is left on retries, and resumes at the start of the next UTC day. No data is lost — ingestion continues from where it paused. If you hit this regularly, reduce the number of selected objects, or reduce the load from other integrations sharing the org.

Connector status

Troubleshooting

See Also

• Sources — managing source connectors, status, and config history.
• Salesforce CDC — streaming change events with native Salesforce Change Data Capture.
• HubSpot — the other CRM API source.