Migrate from changelog destination

changelogDestination deprecation - deadline July 13, 2026

Support for changelogDestination is being removed from production on July 13, 2026. Blueprints and integrations that use changelogDestination must be migrated to Automations before this date.

Overview

The changelogDestination field on blueprints was used to forward catalog change events to external destinations. It supported two delivery patterns:

• Webhook - Port sent event payloads to a customer-configured URL.
• Kafka - Events were published to an org-scoped Kafka topic for downstream consumption.

Port's Automations feature is the direct replacement. Automations provide event-driven delivery with greater flexibility, including conditions, multiple trigger types, and a range of invocation backends.

How to identify if you're using changelogDestination

Before migrating, audit your blueprints for any existing changelogDestination configuration:

• Open a blueprint in the Port UI and switch to the JSON editor - look for a changelogDestination key.
• Or, call the API and inspect all blueprints at once:

  curl -X GET "https://api.port.io/v1/blueprints" \
    -H "Authorization: Bearer <your_token>"

  Search the response for any blueprint that contains changelogDestination.
• For each result, note:
  • Whether the destination type is WEBHOOK or KAFKA.
  • What the flow is for (notification, sync, approval, etc.).
  • Whether the flow is still active.

Migration steps

1. Map each flow to an Automation trigger. Common entity trigger types: ENTITY_CREATED, ENTITY_UPDATED, ENTITY_DELETED, ANY_ENTITY_CHANGE. For approval and post-run flows, use action-run triggers (RUN_CREATED, RUN_UPDATED, ANY_RUN_CHANGE).
2. Recreate the logic in Automations. Configure conditions and invocation methods to match the original behavior.
3. Test in staging with realistic events to confirm the Automation fires as expected.
4. Cut over - remove the changelogDestination field from the blueprint and monitor your Automation runs.

Common use cases and equivalents

changelogDestination use case	Migration path
Notify on blueprint update	Blueprint definition change triggers are not supported in Automations. If you need to react to data changes on entities of a blueprint, use an entity change trigger (ENTITY_UPDATED or ANY_ENTITY_CHANGE) on that blueprint.
Sync data on resource creation	Use the ENTITY_CREATED trigger, then invoke a webhook or action.
Approval flows	Use a self-service action combined with an automation chain.

Migration examples

Example 1: Notify when a catalog entity changes (was webhook on changelog) (Click to expand)

Before - blueprint with a webhook changelogDestination:

{
  "identifier": "your_blueprint",
  "changelogDestination": {
    "type": "WEBHOOK",
    "url": "https://customer.example.com/port-catalog-events"
  }
}

Some blueprints also include "agent": true to route requests through the Port execution agent.

After - Automation with ANY_ENTITY_CHANGE trigger:

{
  "identifier": "notify_on_service_catalog_change",
  "title": "Notify on service catalog change",
  "trigger": {
    "type": "automation",
    "event": {
      "type": "ANY_ENTITY_CHANGE",
      "blueprintIdentifier": "your_blueprint"
    }
  },
  "invocationMethod": {
    "type": "WEBHOOK",
    "url": "https://customer.example.com/port-catalog-events",
    "method": "POST"
  },
  "publish": true
}

Use ENTITY_UPDATED instead of ANY_ENTITY_CHANGE to exclude creation and deletion events. Add an optional condition block to filter on specific fields.

Blueprint definition change

Automations do not support triggering on a blueprint definition change (for example, when a property is added to the schema). If your original webhook was reacting to entity data changes, entity triggers are the correct replacement.

Example 2: Create a ticket when a new entity appears (was Kafka or webhook on create) (Click to expand)

Before - blueprint with a Kafka changelogDestination:

{
  "identifier": "your_blueprint",
  "changelogDestination": {
    "type": "KAFKA"
  }
}

Before - blueprint with a webhook changelogDestination:

{
  "identifier": "your_blueprint",
  "changelogDestination": {
    "type": "WEBHOOK",
    "url": "https://customer.example.com/port-entity-created"
  }
}

After - Automation with ENTITY_CREATED trigger:

{
  "identifier": "ticket_on_new_entity",
  "title": "Open ticket when entity is created",
  "trigger": {
    "type": "automation",
    "event": {
      "type": "ENTITY_CREATED",
      "blueprintIdentifier": "your_blueprint"
    }
  },
  "invocationMethod": {
    "type": "WEBHOOK",
    "url": "https://customer.example.com/port-entity-created",
    "method": "POST"
  },
  "publish": true
}

Example 3: Notify when a self-service action runs (Click to expand)

For action-run notifications, use an action-run trigger rather than an entity changelog destination.

After - Automation with RUN_CREATED trigger:

{
  "identifier": "after_self_service_run_created",
  "title": "Notify when self-service action runs",
  "trigger": {
    "type": "automation",
    "event": {
      "type": "RUN_CREATED",
      "actionIdentifier": "your_self_service_action_identifier"
    }
  },
  "invocationMethod": {
    "type": "WEBHOOK",
    "url": "https://customer.example.com/port-action-run",
    "method": "POST"
  },
  "publish": true
}

The actionIdentifier can also point to another Automation, enabling automation chaining. See available triggers for the full list of action-run trigger types.

Action run logs

Sending logs to an action run does not count as a RUN_UPDATED trigger event.

Example 4: Trigger only when a property reaches a specific value (Click to expand)

Before - blueprint with a webhook changelogDestination (filtering was done in the customer endpoint):

{
  "identifier": "your_blueprint",
  "changelogDestination": {
    "type": "WEBHOOK",
    "url": "https://customer.example.com/port-status-change"
  }
}

After - Automation with ENTITY_UPDATED and a JQ condition:

{
  "identifier": "notify_when_status_becomes_production",
  "title": "Notify when status becomes Production",
  "trigger": {
    "type": "automation",
    "event": {
      "type": "ENTITY_UPDATED",
      "blueprintIdentifier": "your_blueprint"
    },
    "condition": {
      "type": "JQ",
      "expressions": [
        ".diff.after.properties.status == \"Production\"",
        ".diff.before.properties.status != \"Production\""
      ],
      "combinator": "and"
    }
  },
  "invocationMethod": {
    "type": "WEBHOOK",
    "url": "https://customer.example.com/port-status-change",
    "method": "POST"
  },
  "publish": true
}

Adjust the property path (.diff.after.properties.status) to match the actual field name on your blueprint.

Limitations

• Automations cannot fire when a blueprint definition changes (for example, when a new property is added to the schema). Triggers are available for entity-level changes within a blueprint, but not for changes to the blueprint schema itself.

Resources

• Available automation triggers.
• Define automations overview.