Automations
Automations is the org-level home for every scheduled job and inbound webhook across all the projects in your workspace. Instead of hopping between projects, you see — and control — all your background and event-driven workflows from a single place.
This page is org-level, not per-project
Automations lives at /{org}/automations (the Automations entry in your workspace portal), so it aggregates triggers from every project you own. The individual schedule and webhook triggers themselves are created inside each project's API Builder — this page is where you monitor and manage them together.
What you'll find
The page is organized into three tabs:
| Tab | What it shows |
|---|---|
| Schedules | Every endpoint that runs on a time-based rule (cron), across all projects — with its next run time and current state |
| Webhooks ("Desde otros servicios") | Every inbound webhook URL that external services call to trigger your workflows |
| History | A combined execution log of recent automation runs across the workspace |
Schedules
A schedule is an endpoint whose workflow starts from a schedule_trigger node — DYPAI runs it automatically on a time-based (cron) rule. The Schedules tab lists each one with its rule, its next scheduled run, and whether it's active or paused.
From here you can:
- Pause / resume a schedule without touching the workflow itself
- See the next run and recent activity at a glance
- Open per-item run history to inspect what happened on each execution
To create a schedule, add a Schedule trigger to an endpoint in the project's API Builder. It then shows up here automatically — this page manages existing schedules, it doesn't replace the builder.
Webhooks
A webhook is an endpoint whose workflow starts from a webhook_trigger node. DYPAI exposes a public URL that external services (Stripe, GitHub, a form tool, anything that can POST) call to kick off your workflow.
In the Webhooks tab you can:
- Copy the webhook URL to paste into the external service's settings
- Send a test request to confirm the trigger fires and the workflow runs
- Review the per-item run history for each webhook
Webhook URLs are how outside services reach your workflows — treat them like secrets. If you suspect a URL has leaked, regenerate the trigger from the project's API Builder.
Execution history
The History tab gives you a unified, recent run log for both schedules and webhooks across the whole workspace, so you can spot failures or unexpected gaps without opening each project. For deeper, per-project debugging — full log streams and error tracking — use the project's observability pages.
Automating it yourself
If you build with an AI client over MCP, you can manage these same triggers programmatically:
manage_schedules— create, pause, resume, or delete scheduled (cron) runsmanage_webhooks— create and manage inbound webhook triggers
These tools operate on the exact same schedules and webhooks you see on this page.