🚧
Only available in versions 2026-04 and later

Feature-level lifecycle event subscriptions let app developers receive webhook notifications when users interact with specific app feature instances (for example, when a board view is duplicated, an object is created, or a column extension is deleted). These subscriptions give developers fine-grained control over how and where events are delivered.

Feature-level subscriptions: Subscribe only to the feature-level events you care about
Per-event routing: Route different event types to different webhook endpoints
Sync/async handling: Choose synchronous or asynchronous handling per event
Clear identifiers: Manage subscriptions using clear feature identifiers

Supported Event Types

Event Type	Description
AppFeatureBoardColumnExtension:delete	When a column extension is deleted
AppFeatureBoardColumnExtension:duplicate	When a column extension is duplicated
AppFeatureBoardColumnExtension:export	When a column extension is exported
AppFeatureBoardView:delete	When a board view containing your app feature is deleted
AppFeatureBoardView:duplicate	When a board view containing your app feature is duplicated
AppFeatureBoardView:restore	When a board view containing your app feature is restored
AppFeatureColumn:create	When a custom column is created
AppFeatureColumn:delete	When a custom column is deleted
AppFeatureObject:archive	When a custom object instance is archived
AppFeatureObject:create	When a custom object instance is created
AppFeatureObject:delete	When a custom object instance is deleted
AppFeatureObject:duplicate	When a custom object instance is duplicated
AppFeatureObject:import	When custom objects are imported
AppFeatureObject:publish	When a custom object is published
AppFeatureObject:restore	When a custom object instance is restored from the archive
AppFeatureObject:unpublish	When a custom object is unpublished
AppFeatureObject:update_attributes	When a custom object's attributes are updated

Queries

You can use the get_app_lifecycle_subscriptions query to retrieve app lifecycle subscription data via the API.

Only works for app collaborators
Returns an array containing metadata about an app's feature-level lifecycle event subscriptions
Can only be queried directly at the root; can't be nested within another query

query {
  get_app_lifecycle_subscriptions(app_id: "123", version_id: "456") {
    id
    entity_id
    event_type
    webhook_url
    is_sync
  }
}

Arguments

You can use the following arguments to reduce the number of results returned in your get_app_lifecycle_subscriptions query.

Argument	Description
app_id `ID!`	The app's unique identifier.
version_id `ID`	The app version's unique identifier. If not provided, the active version will be returned.

Fields

You can use the following fields to specify what information your get_app_lifecycle_subscriptions query will return.

Field	Description
created_at `Date`	The subscription's creation date.
entity_id `ID`	The entity's unique identifier (e.g., app feature ID).
entity_type `String`	The type of entity (e.g., "appFeature").
event_type `String`	The lifecycle event type (e.g., "AppFeatureColumn:create"). View the full list of supported event types above.
id `ID`	The subscription's unique identifier.
is_sync `Boolean`	Whether the app’s handling of the event is synchronous.
updated_at `Date`	The subscription's last updated date.
webhook_url `String`	The webhook URL for notifications.

Mutations

The API allows you to update and delete feature-level lifecycle event subscriptions using the following mutations.

🚧
Event types must match the app feature type. For example, you cannot subscribe to AppFeatureObject:create events on a board view app feature.

Update app lifecycle subscription

The update_app_lifecycle_subscription mutation updates all existing subscriptions' configurations via the API. You can specify which fields to return in the mutation response.

🚧 You can't update subscriptions for live app versions.

mutation {
  update_app_lifecycle_subscription(
    entity_identifier: "my-app::my-object-feature"
    entity_type: "appFeature"
    input: {
      lifecycle_events: [
        {
          event_type: "AppFeatureObject:create"
          webhook_url: "https://myapp.com/webhooks/lifecycle"
          is_sync: false
        }
        {
          event_type: "AppFeatureObject:delete"
          webhook_url: "https://myapp.com/webhooks/lifecycle"
          is_sync: false
        }
        {
          event_type: "AppFeatureObject:update_attributes"
          webhook_url: "https://myapp.com/webhooks/lifecycle"
          is_sync: true
        }
      ]
    }
  ) {
    id
    event_type
    webhook_url
    is_sync
  }
}

Arguments

You can use the following arguments to define the updated app lifecycle subscription.

Argument	Description	Supported Fields
entity_identifier `ID!`	The entity's unique identifier or complete slug (e.g., `app_slug::feature_slug`). If using the slug, the request is applied to the app’s active version.
entity_type `String!`	The entity's type. Currently only supports `appFeature`.
input `UpdateLifecycleSubscriptionsInput!`	The entity's lifecycle event configuration input.	lifecycle_events `[LifecycleEventInput!]`

💡
When using a full app slug, the API automatically determines which app version the request applies to.

If the active version is a draft, the request is applied to that draft version.

If the active version is not opted in (i.e., not draft-enabled), the request is applied to the live version.

If there is no live version, the request is applied to the latest draft version.

Delete app lifecycle subscription

The delete_app_lifecycle_subscription mutation deletes all app lifecycle subscriptions via the API. It returns a Boolean indicating if the deletion was successful or if no subscriptions exist.

🚧 You can't delete subscriptions for live app versions.

mutation {
  delete_app_lifecycle_subscription(
    entity_identifier: "my-app::my-object-feature"
    entity_type: "appFeature"
  )
}

Arguments

You can use the following arguments to specify which app lifecycle subscription to delete.

Argument	Description
entity_identifier `String`	The entity's unique identifier or complete slug (e.g., `app_slug::feature_slug`). If using the slug, the active version will be deleted.
entity_type `String`	The entity's type. Currently only supports `appFeature`.

Event flow

Once a feature-level lifecycle subscription is configured via the API, the following flow occurs whenever a subscribed event is triggered.

sequenceDiagram
    participant MondayPlatform as monday platform
    participant MondayAppsService as monday app service
    participant YourApp as Your app

    MondayPlatform->>MondayAppsService: Lifecycle event triggered
    MondayAppsService->>MondayAppsService: Look up subscription
    MondayAppsService->>YourApp: POST to webhook URL

    alt Sync Mode (is_sync: true)
        YourApp-->>MondayAppsService: HTTP 200 (success) or 4XX (failure)
        MondayAppsService->>MondayPlatform: Notify result
        Note right of MondayPlatform: Update UI
    else Async Mode (is_sync: false)
        YourApp-->>MondayAppsService: HTTP 202 (acknowledged)
        Note right of YourApp: Process event...
        YourApp->>MondayAppsService: POST to back_to_url with result
        MondayAppsService->>MondayPlatform: Notify result
        Note right of MondayPlatform: Update UI
    end

Webhook security

All feature-level lifecycle webhook requests are authenticated using a JWT signed with your app’s signing secret.

Your server must verify the JWT in each request to confirm it was sent by monday.com. Receiving a payload without verifying the signature doesn't guarantee that the request is authentic.

Webhook request

When a subscribed feature-level event is triggered, monday.com sends a POST request to the configured webhook URL.

Authorization: JWT signed with your app’s signing secret (used to verify the request came from monday)
Content-Type: application/json
X-Apps-Event-Id: Unique event ID for tracking

Verifying the webhook request

To ensure the request was sent by monday.com:

Retrieve the JWT from the Authorization header.
Verify the JWT signature using your app’s signing secret.
Reject the request if verification fails.

Read more about the Authorization header here.

Synchronous vs asynchronous mode

Each feature-level lifecycle event can be handled independently, either synchronously or asynchronously.

Respond with HTTP 202 to acknowledge receipt
Process the event in the background
Call back_to_url when processing is complete

Async Response Example

curl -X POST "{back_to_url}" \
  -H "Content-Type: application/json" \
  -d '{"success": true}'

Best for: Complex calculations, external API calls, database operations, file processing

Respond with HTTP 202 to acknowledge receipt
Process the event in the background
Call back_to_url when processing is complete

Async Response Example

curl -X POST "{back_to_url}" \
  -H "Content-Type: application/json" \
  -d '{"success": true}'

Best for: Complex calculations, external API calls, database operations, file processing