DSL Schema

Blueprint DSL v0.1 - JSON Schema definition for automation blueprints

Overview

The Blueprint DSL (Domain-Specific Language) is a standardized JSON format for defining automation workflows. It provides a platform-agnostic way to describe triggers, actions, data transformations, and integrations.

Schema ID
https://automation-blueprints.dev/schema/v0.1
Current Version
v0.1
Schema Standard
JSON Schema Draft-07

Required Fields

id (string)

Unique identifier for the blueprint. Must contain only alphanumeric characters, hyphens, and underscores.

Pattern: ^[a-zA-Z0-9-_]+$

name (string)

Human-readable name for the blueprint. Minimum 3 characters.

version (string)

Semantic version number (e.g., "1.0.0").

Pattern: ^\d+\.\d+\.\d+$

apps (array)

Array of application identifiers used in the blueprint. Must contain at least one app.

Example: ["salesforce", "slack"]

trigger (object)

The event that initiates the automation workflow.

app (string, required) - Source application
event (string, required) - Event type
filters (array, optional) - Filter conditions

steps (array)

Array of action steps to execute. Must contain at least one step.

id (string, required) - Unique step identifier
app (string, required) - Application to use
action (string, required) - Action to perform
condition (string, optional) - Execution condition
inputs (object, optional) - Input parameters
outputs (array, optional) - Output fields
transforms (array, optional) - Data transformations

Optional Fields

scopes (array)

Categorization tags for the blueprint (e.g., "crm", "messaging", "automation").

retry (object)

Retry configuration for failed executions.

attempts (integer) - Number of retry attempts (minimum 1)
delayMs (integer) - Delay between retries in milliseconds

policies (object)

Custom policy definitions for advanced workflows.

fixtures (object)

Test data fixtures for validation and testing.

tests (array)

Test cases with expected outcomes for automated testing.

compatibility (object)

Platform compatibility metadata (e.g., minimum versions for Zapier, Make, n8n).

Example Blueprint

{
  "id": "hubspot-slack-simple",
  "name": "HubSpot to Slack Notifications",
  "version": "1.0.0",
  "apps": ["hubspot", "slack"],
  "scopes": ["crm", "messaging"],
  "trigger": {
    "app": "hubspot",
    "event": "contact.created",
    "filters": [
      {
        "field": "lifecycle_stage",
        "operator": "equals",
        "value": "lead"
      }
    ]
  },
  "retry": {
    "attempts": 3,
    "delayMs": 1000
  },
  "steps": [
    {
      "id": "send-notification",
      "app": "slack",
      "action": "send_message",
      "inputs": {
        "channel": "#sales",
        "text": "New lead: {{trigger.contact.firstname}}"
      }
    }
  ],
  "fixtures": {
    "trigger": {
      "contact": {
        "id": "12345",
        "email": "test@example.com",
        "firstname": "Test",
        "lifecycle_stage": "lead"
      }
    }
  },
  "compatibility": {
    "zapier": ">=8.0.0",
    "make": ">=1.5.0",
    "n8n": ">=0.150.0"
  }
}

Schema Validation

All blueprints are validated against the DSL schema before publication. The validation checks:

Required Fields
All mandatory fields are present
Data Types
Field values match expected types
Format Patterns
IDs and versions match required patterns
Array Constraints
Minimum item requirements are met

Schema Versioning

The DSL schema follows semantic versioning. Breaking changes will result in a major version bump. Current version: v0.1