Short answer: Drop the "GitLab → List GitLab Merge Requests" action anywhere in your workflow, map the inputs from upstream nodes, and publish.
Every field can be mapped from an upstream trigger, AI step, table row, or hard-coded literal.
| Field | Type | Required | Description |
|---|---|---|---|
Project ID or Path project_id | string | Required | Project ID or Path. Example: 123 |
State state | options | Optional | State. Options: Open, Merged, Closed, All |
Order By order_by | options | Optional | Order By. Options: Created, Updated |
Labels labels | string | Optional | Comma-separated label names |
Per Page per_page | string | Optional | Per Page. e.g. "20" |
{"project_id": "e.g. 123","state": "{{trigger.state}}","order_by": "{{trigger.order_by}}","labels": "e.g. review, frontend","per_page": "20"}
[{"iid": 1,"state": "opened","title": "Fix login redirect","author": {"username": "johndoe"},"web_url": "https://gitlab.com/group/project/-/merge_requests/1","source_branch": "fix/login","target_branch": "main"}]
Use these fields in downstream nodes for routing, logging, or error handling.
Any of these apps can fire this action as part of a workflow.
Triggered by anything in the catalog. Free tier available. No credit card.