Automation Safety

Automation Safety (Creator-Safe Defaults)

Runtime-event automations can be triggered by any viewer who can run your vibe. This is intentional: you can share a link and have automations work immediately.

What this means

• Public: anyone can view and can trigger your runtime-event automations.
• Unlisted is link-accessible: anyone with the link can trigger runtime-event automations.
• Private: not link-accessible (only you and moderators/admins can access).

Threat model (what to protect against)

Treat viewer-triggered automations like a public integration surface. The main risks are cost and spam, not cross-tenant data access.

• Spam automation events to burn your webhook/pulse quotas.
• Replay the same event repeatedly to cause duplicate side effects.
• Send unexpected payload shapes to break fragile code paths.
• Use high-cardinality event types to create noisy logs/alerts.

Platform safety rails (already enforced)

Rate limits

• Per-IP and per-owner limits on grant minting and event emission.
• Invocation limits are aligned with plan trigger rates.

Scoped execution

• Automation events can trigger only capabilities owned by the post author.
• Event types are constrained to safe characters and blocked from internal namespaces.

Short-lived grants

• Grants expire quickly (about 180 seconds) and are tied to a specific post.
• Grants are issued from a no-store endpoint (never embedded in cached public responses).

Audit telemetry

• Grant mints and automation event outcomes are recorded as operator telemetry (IP is hashed).

Beginner Path: Moment To Pulse

The simplest production automation is: choose a moment, wake a Pulse, choose Pulse State memory, then check recent runs. The Pulse receives the moment payload and can send a message, call an API, or update Pulse State without exposing secrets to the browser.

1. Choose the moment

Start with a schedule, webhook, manual run, filtered runtime event, Pulse event, or safe social event. In v1, Pulse and social moments use the runtime-event trigger path with a normalized safe event identity.

2. Wake a Pulse

Pick a saved Pulse action when Vibecodr should do the backend work for you.

3. Choose memory

Use Run every time for intentional repeats, or Run once per event with runOnce().

4. Review runs

Use Recent runs to see what ran, what failed, what was Already handled, and what Could not replay safely.

Batch and retry behavior

Batched runtime events return a result for each submitted event. If one event is rejected, the response still shows which index failed, why it failed, and which entries were accepted. Retry only the failed entries after fixing the reason.

Batch result shape

{
  "ok": true,
  "accepted": 1,
  "failed": 1,
  "partial": true,
  "results": [
    { "index": 0, "ok": true, "status": 202, "eventType": "vibe.view" },
    { "index": 1, "ok": false, "status": 400, "error": "eventType is invalid" }
  ]
}

Creator-safe defaults (recommended checklist)

Do this for every public or unlisted automation

• Filter events: specify the exact runtime event types you need (avoid "all events" in production).
• Duplicate protection: for side effects, use Pulse State Run once per event with the scheduled window key, verified webhook event id, or safe runtime/social event identity. This makes repeated wakes safe; it is not an exactly-once guarantee for third-party side effects.
• Rate limit side effects: protect downstream APIs (email/SMS/Discord/Stripe/etc.).
• Validate payloads: treat all fields as untrusted; ignore unknown fields instead of crashing.
• Let Pulses do the work: keep the moment narrow and put provider calls, secrets, and Pulse State memory inside the Pulse.
• Webhook secrets: when using webhook actions, set a secret and verify X-Vibecodr-Signature on your receiver.

Example: verify a Stripe webhook before parsing

env.webhooks.verify("stripe",...) is the first certified provider helper, not the whole webhook model. Other signed providers can use env.secrets.verifyHmac(...) in advanced/manual handlers until their provider helpers have fixture-backed conformance.

Pulse webhook receiver

import { definePulse } from "@vibecodr/pulse";

// Pseudocode: persist dedupe keys for 1-10 minutes in a short-lived store you control
async function seenRecently(dedupeKey: string): Promise<boolean> {
  return false;
}

export default definePulse(async (_input, env) => {
  const event = await env.webhooks.verify("stripe", {
    secret: "STRIPE_WEBHOOK_SECRET",
  });

  const dedupeKey = "stripe:" + event.id;
  if (await seenRecently(dedupeKey)) return new Response("ok", { status: 200 });

  // Perform your side effect (send email, write DB row, call 3rd party, etc.)
  // Handle event.type and event.data here.
  return new Response("ok", { status: 200 });
});

Example: verify a signed webhook manually

Generic HMAC webhook receiver

import { definePulse } from "@vibecodr/pulse";

export default definePulse(async (_input, env) => {
  const rawBody = await env.request.raw.arrayBuffer({ maxBytes: 1024 * 1024 });
  const verified = await env.secrets.verifyHmac("GITHUB_WEBHOOK_SECRET", {
    format: "github-sha256",
    message: rawBody,
    signatureHeader: env.request.headers.get("x-hub-signature-256"),
    maxBytes: 1024 * 1024,
  });
  if (!verified.ok) return new Response("unauthorized", { status: 401 });

  const text = new TextDecoder("utf-8", { fatal: true }).decode(rawBody);
  const payload = JSON.parse(text);

  return Response.json({ accepted: true, event: payload.action ?? "unknown" });
});