Feature · Embedded Integration

Integrations that live inside the CRM, not next to it.

Teams who need Gmail, Microsoft 365, Slack, Salesforce, HubSpot, Stripe, or a hundred other systems connected to the CRM should not have to open a separate iPaaS console to wire them up. Strkr embeds the OAuth consent, the field mapping UI, the sync monitoring, and the error retry inside the Integrations surface itself. One admin page lists every connection, its health, its last sync, and the records it has written. No tab-switching, no Zapier metering, no second vendor to pay.

Start free trial See pricing
The embedded difference

Why integrations should live inside the application that uses them.

A typical mid-market CRM stack has twelve to twenty connected systems. Email, calendar, chat, support, billing, data enrichment, dialer, VoIP, document signing, warehouse, product analytics, event tracking. In most CRMs, each connection lives in a different vendor console: the Gmail link in a Google admin page, the Slack link in a Slack admin page, the Stripe webhook in Stripe. The CRM admin has to tab-switch to debug a broken sync. Strkr embeds the full lifecycle (connect, map, monitor, repair) inside the CRM Integrations tab, so a single page is the operational surface for the whole stack. The six items below are what the embedded model unlocks that a bolt-on iPaaS cannot.

One console

Every connection on one admin page.

The Integrations tab lists every connected system, its OAuth status, the account it is connected under, the last sync timestamp, the number of records written in the trailing 24 hours, and any current error state. One place to look when something is broken, one place to click when something needs reconnecting.

Field mapping inline

Map once, visible on the record forever.

Field mapping between the connected system and the Strkr schema lives inline on each integration page. See which Strkr field receives which upstream field, run a dry-run with a sample payload before saving, and the mapping diff carries into the audit log so the ops lead knows exactly when a mapping changed.

Sync monitoring

Per-integration health, not an iPaaS dashboard.

Each connection carries its own health panel: successful writes, failed writes, pending retries, rate-limit backoff state, and the latest error payload. Click an error row and the raw request and response render inline, so the admin can diagnose a 400 without opening a separate observability tool.

Native OAuth

Consent in the CRM, token in the vault.

Starting a connection launches the upstream OAuth flow in a popup, lands the token in the Strkr secrets vault (encrypted at rest, scoped per-tenant), and binds it to the Strkr workspace. No service-account workaround, no shared credential sprayed across the team.

Error replay

A failed sync is one click to retry.

When a write fails (rate limit, transient 5xx, token expiry), the event lands in a DLQ and renders on the integration page with the full payload. Click Retry and Strkr re-runs the write; click Edit, Retry and Strkr re-runs with an adjusted payload. The replay story matches the primary flow retry story in the engine.

No metered middleman

Volume is yours, not an iPaaS line item.

Zapier and Make charge per task, Workato charges per recipe, and even native platforms meter after a certain volume. Strkr embedded integrations do not meter sync volume. A one-million-record initial import runs under the same seat price as a hundred-record ongoing sync.

What the embedded surface actually ships

The six things every embedded integration needs to do.

The embedded integration surface is not one feature; it is six subsystems that compose into a working integration lifecycle. Any one of them missing and the embedded promise fails. The six subsystems below are what Strkr ships for every connected system in the Integrations tab, from Gmail to Salesforce. The engineering effort to build these subsystems from scratch for a single integration is weeks; Strkr absorbs that effort once in the platform and amortizes it across every connector.

OAuth lifecycle

Connect, refresh, rotate, revoke.

OAuth 2.0 authorization code flow with PKCE, token refresh on expiry, scope upgrade when the integration adds a feature, and clean revoke when the admin disconnects. Tokens live in a KMS-encrypted secrets vault per-tenant. The admin never sees a token; the system never asks the admin to paste one.

Field mapper

Upstream schema to Strkr schema.

A declarative mapping UI that reads the upstream object schema (via each integration's metadata API), lists every available field, and lets the admin pick a target Strkr field with type coercion. Required field warnings, enum validation, and a diff view against the current mapping all render in the UI.

Sync engine

Batch, event, and polling patterns.

Three sync patterns ship: initial bulk import for the first connection, incremental poll for systems without webhooks, and event-driven for systems with webhooks. Each sync carries a watermark, a retry policy, a backoff schedule, and a dedupe key. The admin picks the pattern; the engine runs it.

Observability

Timeline + logs + metrics on one page.

The integration page shows a timeline of the last 24 hours of sync events, a log view with filterable error payloads, and a metrics panel with success rate, average latency, and record throughput. Everything is scoped per-connection and visible to the admin without a BI tool.

Idempotency

Replays and retries do not duplicate.

Every write carries an idempotency key composed of the upstream event ID plus the Strkr target record ID. A retry or a replay of a successful event is a no-op; a retry of a failed event re-runs cleanly. The idempotency guarantee is a platform contract, not a per-connector promise.

Permission scope

Connections respect tenant and workspace boundaries.

A connection authorized by one workspace is isolated from another workspace in the same tenant. Multi-tenant teams can run per-business-unit Gmail connections, per-region Salesforce connections, per-brand Stripe connections, without the ops team having to coordinate shared credentials.

What this replaces in the stack

Embedded integrations retire the iPaaS line item.

The pattern an embedded-integration CRM replaces is a bolt-on iPaaS: Zapier, Workato, Tray, Mulesoft, Boomi, or a self-hosted integration layer running on Node or Kafka. Each of those is a vendor to pay, a vendor to monitor, a vendor to secure, and a vendor to debug when a sync breaks. For a team of fifty people, the fully loaded cost of a mid-market iPaaS deployment is $12,000 to $40,000 per year on licenses alone, before counting the integration engineer who maintains it. The six specific line items the embedded surface replaces are listed below.

Zapier

$600 to $5,000 per year on tasks.

Zapier bills per task, which means every webhook delivery, every polled record, every retry counts against the quota. A mid-market team running fifteen Zaps across the stack typically burns through the Team plan ($69 per month per 2,000 tasks) and bumps to Company. The embedded surface runs the same work with no task metering.

Workato / Tray

$10,000 to $25,000 per year baseline.

Workato and Tray are the enterprise iPaaS defaults, with annual contracts in the $10,000 to $25,000 range before per-connector or per-recipe fees. The embedded surface removes the standalone iPaaS line entirely; the integration budget collapses into the CRM seat price.

Mulesoft

$80,000 and up for enterprise.

Mulesoft runs $80,000 per year minimum for enterprise iPaaS deployments, and the AppExchange ecosystem assumes Salesforce as the anchor. The embedded surface retires Mulesoft for CRM-anchored integrations and shifts the enterprise budget to use cases that genuinely need a dedicated iPaaS.

Self-hosted integration layer

One or two integration engineers.

The alternative to a vendor iPaaS is a self-hosted Node service that catches webhooks, transforms payloads, and writes to downstream APIs. Fully loaded cost of one integration engineer is $140,000 to $180,000 per year. The embedded surface eliminates the self-hosted layer for anything the connector catalog covers.

Observability stack

Datadog or Honeycomb for integration logs.

Teams running their own integration layer typically pay $500 to $2,500 per month for the observability tooling that tells them when a sync fails. The embedded surface renders the same telemetry inside the CRM at no additional cost.

Credential vault

HashiCorp Vault or AWS Secrets Manager.

A production integration layer needs a credential vault; running one costs between $100 and $500 per month at the mid-market scale. The embedded surface carries a per-tenant KMS-encrypted vault inline with no additional spend.

Connector catalog

What ships embedded, what ships via open API.

Not every integration is a first-class embedded connector; the long tail of SaaS tools is served by the open API and the Flows webhook surface. The split below is deliberate. The embedded catalog covers the twenty connectors a mid-market B2B revenue team uses every day. The open API covers the remaining long tail. Teams who need a custom embedded connector can request it on the roadmap, and the connector SDK is available for partners who want to build on top of Strkr.

Communication

Gmail, Microsoft 365, Slack, Teams.

Full embedded OAuth, bidirectional email sync with the contact timeline, calendar sync for availability and meeting creation, Slack/Teams notification routing with per-channel permission scoping. The daily tools every rep uses, with no second console to administer.

Billing + payments

Stripe, Chargebee, QuickBooks.

Stripe customer and subscription sync, Chargebee for billing complexity, QuickBooks for revenue recognition handoff. Payment events post into the CRM, invoice state renders on the contact and account record, dunning events trigger flows for the revenue team.

CRM-to-CRM

Salesforce, HubSpot, Pipedrive, Zoho.

Full embedded sync with the big-four horizontal CRMs, for teams running Strkr alongside an incumbent during a migration, or for teams who use Strkr for one business unit and Salesforce for another. Bidirectional, with conflict resolution and audit log.

Marketing

Google Ads, Meta, LinkedIn, Mailchimp.

Ad platform lead sync (bidirectional for Google Ads and Meta Lead Ads), audience push for retargeting, email platform sync for teams who keep an incumbent ESP during migration. Full attribution writes back to the CRM so campaign ROI is visible on the record.

Support + ticketing

Zendesk, Freshdesk, Jira.

Support ticket sync into the CRM so the AE sees open issues on the account record, Jira sync for product escalations tied to specific accounts, bidirectional comment writeback. The account team never has to open a support console to see the status.

Data + warehouse

Snowflake, BigQuery, Redshift, S3.

Push CRM records to the warehouse on a schedule or an event, land warehouse-computed fields back on CRM records for scoring and segmentation. The data team runs their analytics on the warehouse; the revenue team keeps everything live in the CRM.

Everything else

Open API + webhooks for the long tail.

For connectors not in the embedded catalog, the open API covers every object with full CRUD, and the webhook surface fires on every event. The ops lead configures a flow that catches the webhook, transforms the payload, and writes to the target system. The pattern that would be a Zap or a Workato recipe is a Strkr flow.

What the admin experience looks like

One page, five minutes, every connection.

Connect

OAuth popup, token in the vault.

Click Connect, the upstream consent page opens in a popup, the user grants scopes, the popup closes, the Strkr admin page refreshes with the connection live. Average time from click to connected state is under thirty seconds for standard OAuth providers.

Map

Field picker with type coercion.

The mapping UI reads the upstream schema and lists every available field. For each field, pick a target Strkr field, select a transform if needed (date format, enum remap, string split), and run a dry-run with a sample upstream record before saving.

Monitor

Health, throughput, errors inline.

The monitoring panel renders the last 24 hours of sync activity: success count, failure count, average latency, and current error state. Click a failure to see the raw request and response payload. Filter by time range, by event type, or by target record.

Repair

Replay a failed event in one click.

A failed event sits in the DLQ with its full payload rendered. The admin can Retry (re-run the event unchanged), Edit then Retry (modify the payload and re-run), or Skip (dismiss the event and clear the DLQ entry). Every repair action lands in the audit log.

Scope

Per-workspace, per-business-unit.

A connection is scoped to the workspace where it was authorized. Multi-tenant and multi-business-unit teams can run isolated connections per unit without coordinating shared credentials. The scope renders on every integration page as a chip next to the connection name.

Audit

Every connect, map, write, revoke logged.

The audit log carries the acting user, the acting system, the action, and the payload digest for every integration event. Required for SOC 2 Type II and HIPAA attestations; useful every day for the ops lead who needs to answer "who changed this mapping on Tuesday."

Every integration inside the CRM, on the base seat price.

Connect Gmail, Slack, Stripe, Salesforce, HubSpot, Zendesk, and the rest from one admin page. No iPaaS line item, no per-task Zapier metering, no second console to administer.

Start free trial See integrations
Common questions

What buyers ask about this feature.

What does embedded integration mean specifically?

The full integration lifecycle (OAuth consent, field mapping, sync monitoring, error replay, credential storage) lives inside the Strkr Integrations tab, not in a separate iPaaS vendor console. One admin page lists every connected system, its health, its last sync, and the records it has written. The admin never tab-switches to a second vendor to diagnose a broken sync, and the organization never pays a second billing line for the integration layer.

Does Strkr replace Zapier, Workato, and Mulesoft?

For CRM-anchored integrations, yes. The embedded connector catalog covers the twenty systems a mid-market B2B revenue team uses every day (Gmail, Microsoft 365, Slack, Teams, Stripe, Salesforce, HubSpot, Zendesk, Jira, Snowflake, and more). The open API and webhook surface cover the long tail. For integrations that have nothing to do with the CRM (two SaaS tools talking to each other on their own schedule), a dedicated iPaaS may still earn a line, but the CRM-anchored portion of the integration bill collapses into the Strkr seat price.

How are OAuth tokens stored?

In a KMS-encrypted secrets vault scoped per-tenant. The admin never sees a token, the system never asks the admin to paste one, and tokens never leave the vault into logs or into third-party systems. Token refresh runs on expiry, scope upgrades run when a new feature in the integration needs them, and revoke runs cleanly when the admin disconnects a connection. All token lifecycle events land in the audit log.

What happens when an integration sync fails?

The failed event lands in a DLQ scoped to the integration, with the full request and response payload available on the integration page. The admin can retry the event unchanged, edit the payload and retry, or skip the event. Transient failures (5xx, rate-limit 429) retry automatically with exponential backoff. Permanent failures (4xx, missing field, enum mismatch) hold in the DLQ until the admin acts. Every retry and every repair lands in the audit log.

Is there any task or volume metering on embedded integrations?

No. The embedded surface does not meter sync volume, task count, or recipe count. A one-million-record initial import runs under the same seat price as a hundred-record ongoing sync, and a team that doubles its integration volume quarter over quarter does not see a quarter-over-quarter bill bump. The only billing dimension is the Strkr seat count.

Can teams build their own embedded connector?

The connector SDK is available for teams and partners who need a custom embedded connector not in the main catalog. The SDK handles OAuth, field mapping, sync patterns, DLQ, and audit log inheritance so the custom connector gets the same embedded surface the catalog connectors do. For most teams, the open API plus the webhook surface are the faster path; the SDK is reserved for cases where a reusable embedded surface is the right level of abstraction.

Related features

Pair this with...

API and Webhooks Email Integration AI CRM Integration Services CRM Automation

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing