Integration patterns on SGEN

In short. Every integration on SGEN fits one of four patterns: Pull (external system reads from SGEN's API surface), Push (SGEN emits a Webhooks event), Bidirectional sync (both directions), or Direct embed (third-party script runs in the browser). Name the pattern before you build — it determines which SGEN surface you work from and what breaks first when something goes wrong.

On this page: The four patterns · When pull fits · When push fits · When bidirectional sync fits · When direct embed fits · Pattern selection reference · Integration posture

This is a concept page — it gives you the map. Implementation detail for each pattern lives in the surface-specific docs: the Webhooks reference for push-side, the API surface for pull-side, Custom Codes for direct embed, and the Integration Directory for native integrations that SGEN ships out of the box.

The four integration patterns

Each pattern has a name, a data-flow direction, and a set of scenarios where it fits cleanly.

Pattern 1 — Pull (API read). An external system reads data from SGEN on a schedule or on demand. SGEN holds the data; the external system is the requester. The connection is initiated by the external system — no SGEN configuration is needed beyond an API credential and the correct endpoint.

Use pull when the external system drives the rhythm — reporting tools, analytics exports, scheduled data syncs, integration middleware that aggregates across many sources.

Pattern 2 — Push (webhook). SGEN emits an event when something happens — a page publishes, a form submits, an order status changes — and an external system receives it in real time. The SGEN Webhooks module (in SG-Modules) handles subscription, delivery, retry, and logging.

Use push when SGEN owns the event and the external system needs to react in real time — CRM updates from form submissions, email sequences triggered by content activity, alerts on order events.

Pattern 3 — Bidirectional sync (API + webhook). Data flows both ways. SGEN reads from the external system (or vice versa) via the API surface, and SGEN also emits events to the external system via webhook. The two channels are coordinated but distinct.

Use bidirectional sync when neither system is the sole authority — an ERP that holds inventory but needs order status from SGEN, a CRM that holds contacts but needs form-submission activity from SGEN.

Pattern 4 — Direct embed (third-party widget). A third-party script or iframe is placed on a SGEN page. The widget runs in the browser and communicates directly with the third-party platform without passing through SGEN's server layer. SGEN manages where the embed appears via Custom Codes; it does not manage the widget's behavior or data flows.

Use direct embed when the third-party platform provides a self-contained widget that works in a browser — live chat, payment processors, booking forms, video players, analytics widgets.

When pull fits

Pull is right when the external system drives the rhythm. The external system decides when to request data, what to request, and how often.

• Scheduled exports. A reporting tool pulls SGEN content data nightly. An analytics pipeline collects raw event data on the hour. The external system owns the schedule; SGEN responds to each request.
• On-demand lookups. A product configurator checks SGEN's catalog data when a user loads a page. The external system drives the request; SGEN returns the current state at that moment.
• Integration middleware. A platform aggregating data from SGEN, a CRM, and an ERP pulls from each on a consistent schedule and handles the merging itself.

Pull is less clean when SGEN owns the event and the external system needs to react immediately. A CRM that only pulls SGEN data every hour misses form submissions that came in at minute three. For event-driven reactions, push fits better.

When push fits

Push is right when SGEN owns the event and the external system needs to react without delay.

• Form-to-CRM flows. A visitor submits a SGEN contact form. SGEN emits a form.submission webhook event. The CRM creates a contact record within seconds — no polling, no missed submissions between windows.
• Content-triggered automations. A blog post publishes. SGEN emits a page.published event. An email platform triggers a campaign; a social scheduling tool queues the post. Multiple listeners on the same event — each handles its own reaction.
• Order and transaction alerts. An e-commerce event on SGEN emits a webhook. A fulfillment system processes the shipment; an accounting system records the transaction.

Push is less clean when the external system needs historical data or bulk data sets. Webhook events are point-in-time notifications, not data dumps. For historical reads, pull is the right pattern. For data that flows both ways, combine them into bidirectional sync.

When bidirectional sync fits

Bidirectional sync fits when neither system is the sole authority on the data.

• CRM plus forms plus content activity. The CRM owns contact records; SGEN owns the interaction layer. Pull brings CRM segment data into SGEN. Push sends form submissions and content events back to the CRM. Both sides stay current.
• ERP plus product catalog plus order status. The ERP owns inventory, pricing, and SKUs; SGEN owns the public catalog and the order form. Inventory updates sync from the ERP into SGEN via pull. Order placements and status changes sync from SGEN back to the ERP via push.
• Search platform plus content index plus query signals. A search platform indexes SGEN content via pull on a schedule. Query signals push back to the search platform; the relevance model improves over time.

Bidirectional sync carries more operational complexity than either pull or push alone — two channels to monitor, two failure modes to handle, and the risk of a sync loop if both systems react to each other's events without a loop guard.

When direct embed fits

Direct embed fits when the integration exists at the page layer, not the data layer. The third-party platform provides a self-contained widget that the user loads in their browser. SGEN manages where the embed appears; the third party manages the widget's behavior.

• Live chat. A chat widget script is embedded on every SGEN page via Custom Codes. It loads asynchronously, initializes in the browser, and communicates directly with the chat platform. SGEN only controls where the script runs.
• Payment processors. A checkout flow embeds the processor's hosted fields — a script-injected form that submits directly to the processor. Payment data never passes through SGEN's server.
• Analytics and tag managers. A tag manager script is embedded globally. The tag manager fires individual analytics, advertising, and tracking tags based on page events. SGEN manages the placement via Custom Codes; the tag manager handles the downstream tags.

Direct embed is the fastest pattern to deploy — no server-side configuration, no API credential, no SGEN data model work. The tradeoff is opacity. SGEN does not see the data flows inside a direct embed and cannot rate-limit them. Embeds also carry page-weight cost that accumulates as the embed count grows.

Pattern selection reference

Integration complexity by pattern

Pull carries the lowest SGEN-side complexity. An API credential, a set of endpoints, and a defined query rhythm — the external system owns the rest. The primary risk is rate-limit pressure from a consumer that polls too aggressively.

Push carries moderate complexity. A webhook subscription needs to be created, secured, and monitored. The primary operational risk is consumer downtime — if the external system goes offline, SGEN queues and retries, but an extended outage creates a backlog that needs to be cleared manually.

Bidirectional sync carries the highest complexity. Two channels, two failure modes, and the structural risk of a sync loop. Build it when the use case genuinely requires it, not as a default for anything that involves two systems.

Direct embed carries the lowest complexity on the SGEN side but the highest opacity. SGEN cannot audit what the embed does in the browser or rate-limit its third-party calls. Audit embeds periodically — they are easy to add and easy to forget.

The integration posture decision

Every team makes an implicit choice about their integration posture. Making it explicit early saves time later.

Native-first posture. Use SGEN's native integrations wherever they cover the use case. Only build a custom path when the native integration does not expose the control the use case requires. The benefit is low maintenance — SGEN owns the integration code and updates it when the external system changes. The tradeoff is limited control over pattern, frequency, and data shape.

Custom-first posture. Build every integration from first principles using SGEN's API surface, Webhooks module, and Custom Codes. Complete control — pattern, frequency, data transformation, error handling. The tradeoff is maintenance burden: when the external system changes, the team updates the integration code.

Hybrid posture. Use native integrations for standard categories (analytics, email, search) where the native integration covers the common case. Use custom paths where the business logic is specific to the use case. Most teams at moderate scale land here.

If the native integration covers the use case, use it. If the use case requires customization the native integration does not expose, build the custom path from the correct pattern surface. Do not build a custom version of something the native integration already does correctly.

Reference — example integration map

A sample map for a mid-size SGEN operator running a content site plus a light e-commerce layer.

The last row is a common finding at the twelve-month mark — a dormant embed added by a team member who has since left, running on every page, carrying page weight with no active benefit. The quarterly review surfaces it; the fix is one toggle in Custom Codes.

Connected pages

• Extensibility Overview — how custom logic layers on top of the four patterns. Read this when the integration requires transformation or routing that the native surfaces do not expose.
• Webhooks reference — push-side implementation surface. Every event SGEN can emit, payload schemas, delivery guarantees, and retry behavior.
• API surface — pull-side implementation surface. Every endpoint, request shape, authentication, and rate limits.
• Custom Codes documentation — direct embed implementation surface. Placement, scope, load order, and sanitizer rules.
• Integration Directory — the catalog of native integrations SGEN ships. What each covers, what pattern it uses, and what configuration it exposes.