Skip to main content
Code-native integrations let you define every aspect of a Prismatic integration in TypeScript source code. Instead of assembling flows in the low-code designer, you write integration(), flow(), and configPage() calls that compile down to the same YAML representation the designer produces — but with the full expressiveness of a typed programming language.

​
Code-native vs the low-code designer

ConcernLow-code designerCode-native
AuthoringBrowser drag-and-dropTypeScript source files
Version controlPrismatic-managedAny Git workflow
Logic complexityStep branchingArbitrary TypeScript
ReuseCopy-paste flowsImport functions and modules
Dependency managementBuilt-in componentsnpm packages + built-in components
TestingManual test runsUnit tests with createMockContextComponents()
Both approaches deploy to the same Prismatic platform and support the same config wizard, connections, endpoint types, and retry/queue options.

​
The integration() function

Every code-native integration starts with a call to integration(), which accepts an IntegrationDefinition object and returns a platform-ready integration artifact. 
import { integration } from "@prismatic-io/spectral";

export default integration({
  name: "My Integration",
  description: "Syncs data between two systems",
  flows: [...],
});

​
IntegrationDefinition fields

​
name
string
required
The unique display name for this integration.
​
description
string
A human-readable description shown in the Prismatic UI.
​
flows
Flow[]
required
One or more flow definitions. Every integration must have at least one flow.
​
configPages
ConfigPages
Config wizard pages shown when a customer deploys an instance. See Config wizard.
​
userLevelConfigPages
UserLevelConfigPages
Config wizard pages filled in by end users rather than the deploying customer. See Config wizard.
​
componentRegistry
ComponentRegistry
Existing Prismatic components whose actions you want to call from flow execution. See Existing components.
​
endpointType
'flow_specific' | 'instance_specific' | 'shared_instance'
Controls how incoming webhook requests are routed to flows. Defaults to flow_specific. See Endpoint configuration.
​
triggerPreprocessFlowConfig
PreprocessFlowConfig
When endpointType is not flow_specific, describes which fields in the trigger payload carry routing information. Cannot be set alongside a preprocess flow. See Endpoint configuration.
​
instanceProfile
string
Name of the instance profile to use. If omitted, the tenant’s default profile is applied.
​
iconPath
string
Path to the integration icon, relative to the compiled integration output.
​
category
string
Category label for the integration in the Prismatic marketplace.
​
version
string
Semantic version string for this integration.
​
labels
string[]
Arbitrary labels attached to the integration.
​
scopedConfigVars
ScopedConfigVarMap
Organization-level or customer-level connections that are managed outside the config wizard.

​
Minimal complete example

The following integration has a single flow that receives a webhook and logs the body. 
import { integration, flow, configPage, configVar } from "@prismatic-io/spectral";

export default integration({
  name: "Hello World",
  description: "A minimal code-native integration",

  configPages: {
    "Connection Settings": configPage({
      tagline: "Provide your API credentials",
      elements: {
        "API Base URL": configVar({
          stableKey: "api-base-url",
          dataType: "string",
          description: "The base URL for the external API",
          defaultValue: "https://api.example.com",
        }),
      },
    }),
  },

  flows: [
    flow({
      name: "Receive Webhook",
      stableKey: "receive-webhook",
      description: "Handles inbound webhook events",
      onExecution: async (context, params) => {
        const payload = params.onTrigger.results;
        const baseUrl = context.configVars["API Base URL"];

        console.log("Received webhook from", baseUrl, payload.body.data);

        return { data: null };
      },
    }),
  ],
});
Set DEBUG=true in your environment to print the compiled integration YAML to the console during development.

​
Project structure

A typical code-native integration project looks like this: 
<Tree>
  <Tree.Folder name="src" defaultOpen>
    <Tree.File name="index.ts" />
    <Tree.Folder name="flows" defaultOpen>
      <Tree.File name="receiveWebhook.ts" />
      <Tree.File name="syncRecords.ts" />
    </Tree.Folder>
    <Tree.Folder name="connections" defaultOpen>
      <Tree.File name="acmeConnection.ts" />
    </Tree.Folder>
  </Tree.Folder>
  <Tree.File name="package.json" />
  <Tree.File name="tsconfig.json" />
</Tree>

​
Next steps

Flows

Define flow logic, triggers, retry policies, and lifecycle hooks.

Config wizard

Build multi-page config wizards with typed variables and connections.

Connections

Configure customer and organization connections as config variables.

Endpoint configuration

Control how inbound requests are routed across flows and instances.

Existing components

Call actions from built-in Prismatic components inside your flows.

Build docs developers (and LLMs) love

Get started for freeTalk to us