Automation Safety

Automation risk model

Automation turns a vibe or Pulse from something a person opens into something that can react to events, time, webhooks, or runtime signals. That power needs explicit limits because retries, external callers, and schedules can multiply mistakes quickly.

Safe automation starts with narrow moments, Pulse State duplicate protection, bounded retries, clear grants, and logs that explain what happened without exposing secrets. For most creators, the easiest production path is moment, Pulse action, Pulse State memory, then Recent runs.

• Validate incoming webhook payloads and signatures.
• Use Run once per event for external side effects; use Run every time only when repeats are intentional.
• Use least-privilege grants and owner-controlled secrets.
• Bound retry behavior and avoid unbounded fan-out.
• Keep operational telemetry metadata-only.

Beginner automation path

Choose the moment first: schedule, webhook, manual run, filtered runtime event, Pulse event, or safe social event.

In v1, Pulse and social moments are normalized into the supported runtime_event trigger path. The product can say Pulse event or social event, while the backend still receives one safe runtime event identity.

Choose a Pulse action when Vibecodr should do backend work for you. The Pulse receives the moment payload plus a friendly Pulse State memory hint.

Use Run once per event when a Pulse writes to Discord, Notion, Stripe, GitHub, email, or another external service. Manual test runs can use Run every time when repeated tests are intentional.

Check Recent runs after setup. Already handled means the event was completed before; Could not replay safely means the result was intentionally not retained.

• Start with one moment and one Pulse action.
• Filter runtime events instead of listening to every event.
• For schedules, use the scheduled window key. For runtime, Pulse, and social moments, use the normalized safe event identity. For provider webhooks, verify first; body event ids are only hints until the caller is trusted.
• Retry only failed batch entries when a batch response is partial.

When to add automation

Add automation when it removes real manual work or enables a project behavior that cannot happen in a single viewer session. Do not add it as a shortcut around missing validation or unclear product rules.

If an automation touches money, accounts, external APIs, or user data, treat the handler as production backend code.

• Prefer explicit user action until the trigger rules are clear.
• Test failure paths, duplicate delivery, and out-of-order events.
• Document what the automation is allowed to do before expanding it.

Example and read next

Example: a scheduled Pulse sends reminders every morning. Validate the target, cap retries, keep secrets server-side, and make the operation idempotent enough that a retry cannot spam users or duplicate writes.

Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.

• Read next: Secrets & APIs (/docs/secrets)
• Read next: Calling Pulses (/docs/calling-pulses)
• Read next: Pulse Routing (/docs/pulse-routing)
• Read next: How-To Guides (/docs/how-to)