Integrations

First-party integrations to external services, configured inside the platform.

Integrations is the SGEN platform layer for connecting to external services — Google Search Console, Google Business Profile, ClickUp, Google Analytics, email and SMTP providers, payment gateways. Each shipped integration is treated as first-party: configured, monitored, audited inside the platform, governed by the platform's release cadence. The result: the integration breaks the same way the rest of SGEN breaks — visibly and with bounded blast radius.

What is this for?

Read this page to understand the Integrations layer of the SGEN platform — what integrations exist, why they ship as first-party, and how to find the configuration for each.

Good use cases

• You are scoping which external services SGEN connects to before evaluating the platform.
• You are looking for the right integration to connect SGEN to a specific external tool.
• You are deciding whether to use a first-party integration or a custom workaround.
• You hit a question like "Does SGEN integrate with Google Search Console?"

What NOT to use this for

• Per-integration setup steps — open the specific integration's reference page.
• Custom integrations not on the shipped list — that's a Custom Codes module conversation.
• Migration from a different platform's integration setup — open the migration documentation.

Before you start

You should have:

• A specific external service you want to connect SGEN to, or general curiosity about the integration catalog.
• Admin credentials for the external service (most integrations need OAuth or API key authentication).

How this connects to other features

• Integrations Overview — the deeper introduction to the integration catalog.
• SG-Modules — the modules that integrations work alongside.
• SG-Admin Overview — the operator-facing surface where integrations are configured.

Where to go

Open the admin → Integrations. Each integration has its own configuration surface; authentication, scope, and operational state all live there.

How integrations work

Steps — Use first-party integrations

1. Recognize the integration catalog

The shipped integrations include:

• Google Search Console — verification, sitemap submission, indexing status surfaced inside SGEN.
• Google Business Profile — business listing data tied to local SEO and location surfaces.
• Google Analytics 4 — traffic measurement and event tracking surfaced alongside SGEN's built-in analytics.
• ClickUp — task and ticket sync for support and operations workflows.
• Email and SMTP providers — transactional email delivery for form submissions, notifications, and password recovery.
• Payment gateways — Stripe, PayPal, and other ecommerce payment processors connected for the Ecommerce module.

The catalog grows over releases. New integrations are added when the platform team identifies an external service common enough across operator workflows to warrant native support.

2. Understand why first-party integrations

A third-party plugin integration is a black-box dependency: a separate vendor maintains the code, the vendor sets the update cycle, the vendor decides what breaks and when. The integration's failure mode is independent of the platform's.

A first-party integration follows the platform's release cadence, scope rules, and audit logging. The integration's failure mode is bounded by the platform's failure mode — when the platform is healthy, the integration is healthy; when an issue arises, the platform's monitoring catches it.

The trade-off: fewer integrations available than a fully open marketplace. The catalog is curated rather than exhaustive. Operators who need an integration outside the catalog have the Custom Codes module as a fallback.

3. Find the right integration for the workflow

Most integration needs land on a specific shipped integration:

• Tracking SEO performance → Google Search Console.
• Local SEO and business listings → Google Business Profile.
• Custom analytics tracking → Google Analytics 4 (alongside SGEN's built-in analytics).
• Task and ticket workflows → ClickUp.
• Form-submission email delivery → Email and SMTP integrations.
• Ecommerce payments → Payment gateway integrations.

When the workflow doesn't fit a shipped integration, the right move is usually to revisit the workflow rather than reach for Custom Codes. Most integration needs are covered; the cases that aren't are rarer than expected.

4. Configure each integration deliberately

Each integration has its own configuration surface in the admin shell. Operators authenticate, configure scope, and verify operational state. The configuration steps vary per integration; the per-integration reference page covers them.

Configuration is one-time per integration per site. Once set up, the integration runs continuously without operator intervention until something changes (token expiry, scope adjustment, integration deprecation).

5. Monitor integration health

Integrations carry their own operational state in the admin. Operators can see whether each integration is connected, when it was last verified, and any errors that have surfaced. The platform's monitoring covers integration health alongside other platform health.

When an integration fails (token revoked, external API change, configuration drift), the admin surfaces the failure clearly. Operators see the problem and can address it; the integration doesn't fail silently.

What success looks like

• You know which integrations are available and which match your workflows.
• You configure each integration deliberately rather than as an afterthought.
• You monitor integration health alongside other platform health.
• You don't reach for Custom Codes when a shipped integration covers the case.

What to do if it does not work

An integration isn't authenticating. Most often a credential issue — expired tokens, revoked OAuth, incorrect API keys. Re-authenticate from the integration's configuration surface.

Data isn't flowing through an integration. Check the integration's operational state in the admin. The surface tells you whether data is being sent and whether the receiving service is acknowledging.

A specific feature isn't supported by an integration. Sometimes accurate; sometimes the feature is in a different integration than expected. Check sibling integrations first; if genuinely unsupported, the Custom Codes module is the fallback.

Multiple integrations seem to overlap. Common when more than one Google service is connected. The integrations cover different workflows even when they share authentication; configure each for its specific role.

An integration was deprecated. The platform notifies operators when integrations are scheduled for deprecation. The notice covers what to migrate to and when.

Best practices

• Configure each integration once, deliberately. Half-configured integrations cause more support friction than fully-configured ones.
• Use the platform's monitoring rather than building per-integration alerting.
• Watch release notes for integration additions and deprecations.
• For workflows the catalog doesn't cover, evaluate whether the workflow can be redesigned around an existing integration before reaching for Custom Codes.

Common questions

How many integrations are there? Around a dozen as of the most recent release shipped state. The catalog grows over time.

Are integrations free? The integrations themselves don't carry separate costs. The external services they connect to may have their own pricing.

Do integrations work across multi-site portfolios? Each site configures its own integrations. Multi-site teams can replicate configuration across sites; the platform supports this through per-account credential management for some integrations.

What if I need an integration that isn't on the catalog? Check the platform's roadmap for planned additions. For workflows that genuinely can't wait, the Custom Codes module is the fallback path.

Can I disable an integration after setup? Yes. Each integration's configuration surface includes a disable toggle. Disabled integrations stop sending data but preserve their configuration for re-enabling.

Categories

The shipped integrations group into a few operational categories.

Search and discoverability — Google Search Console, Google Business Profile.

Analytics and measurement — Google Analytics 4, supplementing SGEN's built-in analytics.

Operations and workflow — ClickUp, supporting task and ticket workflows.

Communication — Email and SMTP providers, transactional email delivery.

Commerce — Payment gateway integrations, supporting Ecommerce module workflows.

The categorization isn't strict. Some integrations span categories (Google Analytics is both analytics and measurement). The grouping is a navigation aid.

How integrations sit in the platform

Integrations sit alongside SG-Modules at the platform layer. Where SG-Modules covers internal workflows (forms, popups, redirects), Integrations covers external-service connections (analytics tools, search-engine reporting, payment processing).

The two layers compose. A Form (SG-Modules) submits and triggers an event that flows through Email/SMTP (Integrations) to deliver a notification. A Page's SEO frontmatter feeds into Google Search Console (Integrations) for indexing status. The integration layer extends platform reach without breaking the platform's internal coherence.

Reading order

Read this overview once. Pair with Integrations Overview for deeper introduction and SG-Modules for the internal-workflow layer.

For each integration you'll work with, follow the link from this page to the integration's reference page. The references cover authentication, scope, configuration, and operational behavior in depth.

Related reading

• Integrations Overview
• SG-Modules
• SG-Admin Overview
• Google Analytics 4
• Google Search Console

Multi-site integration management

Operators managing multiple SGEN sites face per-site integration configuration. Each site connects to integrations independently — Google Search Console for site A is configured separately from Google Search Console for site B.

For agencies and multi-site teams, the per-site configuration adds work but produces clean isolation. A token issue on one site doesn't affect the others; an integration deprecation can be rolled out per site.

The platform supports configuration replication where the integration shape allows — copying a working configuration from one site to another preserves the structural decisions even though credentials are still per-site.

For very large multi-site portfolios, integration-management workflows are usually scripted via the platform's account-level configuration tools.

Operators set up the integrations once at the account level where supported, then per-site overrides where needed.

The pattern keeps configuration burden bounded as the portfolio grows.

Most multi-site teams settle into this rhythm within their first month of platform use.

The platform's documentation covers per-integration multi-site patterns where they apply.

Integration testing patterns

When operators activate a new integration, the standard discipline is to test it before relying on it in production. The platform supports each integration with a test affordance.

For Google Search Console: submit a sitemap and verify it lands in Search Console's coverage report. For Google Analytics: trigger a test event and verify it appears in GA4's real-time view. For email/SMTP: send a test email and verify delivery. For ClickUp: create a test task and verify it appears in the configured workspace.

The test affordances catch most setup mistakes before any production traffic encounters the integration. They don't replace real-world validation but reduce the surprise rate substantially.

When to retest

Re-test an integration when its configuration changes — new authentication, new scope, new endpoint. Re-test after any external service change that might affect the integration. Re-test after any platform release that touches integration internals.

The platform release notes typically highlight integration-affecting changes. Operators who watch the notes know when retesting is worthwhile.

Privacy and data flow

Integrations move data between SGEN and external services. Each integration documents what data flows in which direction; operators should review the data-flow shape before activating an integration in production.

The platform respects visitor consent state in integrations that handle visitor data. When a visitor hasn't given tracking consent, identifying signals are stripped from data flowing to integrations like Google Analytics; the integration still operates, but with reduced visitor-identifying payload.

For sites in jurisdictions with strict data-handling rules (GDPR, CCPA, etc.), the integration configuration surface includes per-integration consent gating where applicable. Operators set the gating to match their compliance requirements; the platform honors it automatically.

Data residency

Some integrations send data to specific regions (Google Cloud regions, US-based ClickUp endpoints, etc.). The integration's reference page covers data-residency considerations; operators in regulated industries should review before activating.

Authentication patterns

Integrations use a few different authentication patterns, depending on the external service.

OAuth flow. Most Google integrations use OAuth — operators click Connect, get redirected to Google, grant permission, get redirected back. Tokens are stored encrypted; SGEN uses them to authenticate API calls without operators re-entering credentials.

API key. Some services authenticate via API keys operators paste into the integration configuration. The keys are stored encrypted; the platform doesn't display them in plain text after the initial paste.

Provider account credentials. Email and SMTP integrations sometimes require SMTP credentials (host, port, username, password). Operators configure these once; the platform handles the actual SMTP connection.

Webhook URL exchange. Some integrations work via webhooks — SGEN provides a URL the external service calls when something happens. The URL is generated per integration; operators paste it into the external service's webhook configuration.

The right pattern depends on the integration. The integration's reference page covers which pattern applies and what specific values operators need to provide.

Token rotation and re-auth

OAuth tokens expire on the external service's schedule. The platform handles token refresh automatically for most integrations; operators don't have to re-authenticate routinely. When a token can't be refreshed (the operator revoked permission, or the external service changed its policies), the integration surfaces a re-authentication prompt.

API keys generally don't expire on a schedule but can be rotated by the operator. The integration configuration surface lets operators paste a new key when they rotate.

Cross-integration coordination

When multiple integrations work together, the platform handles coordination behind the scenes. A common example: a form submission triggers email delivery via the SMTP integration, fires an Analytics event via the GA4 integration, and creates a ClickUp task via that integration. All three integrations participate in the same workflow without operator wiring.

The coordination is transparent to operators in most cases. When something goes wrong (one integration fails, another succeeds), the platform's monitoring surfaces the partial state. Operators see which integration broke and can address it without untangling the rest of the workflow.

About first-party integrations

The decision to ship integrations first-party rather than supporting an open integration marketplace shapes how integrations behave on SGEN.

A marketplace produces variety — many vendors, many connection options, many feature comparisons. Variety can be useful when the right integration depends on the operator's specific situation.

First-party integrations produce coherence — one set of behaviors, one set of failure modes, one update cadence. Coherence is more useful when reliability matters more than choice.

SGEN bets on coherence for the integrations it ships. The catalog is curated; the integrations are designed to work together; the failure modes are bounded.

About external service connections

External service connections are the data flows between SGEN and the integrated services. Each connection has its own shape.

Some are pull connections: SGEN reads data from the external service (Google Search Console reporting indexing status, Google Analytics returning aggregated metrics).

Some are push connections: SGEN writes data to the external service (sitemap submission to Search Console, transaction events to a payment gateway, task creation in ClickUp).

Some are bidirectional: data flows in both directions (form submissions push to email/SMTP and pull delivery confirmations).

The per-integration reference describes which direction(s) each integration's connection runs in.

About platform integrations

Platform integrations in this documentation refers to the first-party shipped integrations covered by this page. The phrase distinguishes platform integrations from third-party tools that operators connect through Custom Codes.

Platform integrations carry the platform's reliability, support, and integration guarantees. Custom Codes integrations carry operator-side responsibility — the operator owns the implementation, the maintenance, and the failure handling.

Most operators get more value from platform integrations than from Custom Codes integrations. The trade-off is variety for reliability.

About integration configuration

Integration configuration is the per-integration setup operators do once after connecting an integration. The configuration covers authentication credentials, scope (which permissions the integration can use), per-site settings, and any integration-specific options.

Configuration usually takes a few minutes per integration. The result persists until something changes — operators don't have to re-configure each time the integration runs.

Maintenance discipline

Update this page when:

• A new integration ships in the catalog.
• An existing integration is deprecated or replaced.
• The integration architecture shifts in a way that affects how operators configure or monitor integrations.
• A new category emerges that warrants its own grouping above.

Per-integration changes (new configuration options, new operational behaviors) belong in the integration's specific reference page rather than here.

Scope

This Reference covers the platform-level shape of integrations: what the surface is responsible for, how it relates to neighboring surfaces, and the structural boundaries that hold across releases. Operator how-to and per-release change land on the linked operator-facing or changelog surfaces, not here.

Examples

• A SGEN operator opens this surface to confirm the structural shape before scoping a configuration change.
• A new team member reads end-to-end to build a mental model of the layer before touching any per-feature settings.
• An integrator references the relationship list to confirm which neighboring surface owns a specific behavior.

Fields