Skip to main content

Creating Events

Events can be created in two ways: manually through the dashboard or automatically when first triggered. This guide covers both methods and best practices for event configuration.
Prerequisites: You need a Flowripple account and at least one project to create events.

Manual Creation

Create events through the dashboard when you want to pre-define the event structure before triggering.
1

Navigate to Events

In your project dashboard, go to the Events section in the sidebar navigation.
2

Click Create Event

Click the “Create Event” button to open the event creation form.
3

Enter Event Name

Provide a descriptive name for your event (e.g., “User Signup”, “Order Created”). This name helps identify the event in the dashboard.
4

Configure Identifier

The Event Identifier is auto-generated from the name using dot notation (e.g., user.signup). You can customize it, but it must follow the identifier rules below.
5

Define Expected Payload (Optional)

Specify the JSON structure your event will receive. This helps Flowripple extract variables and provides documentation for your team.
{
  "userId": "usr_123",
  "email": "[email protected]",
  "profile": {
    "firstName": "John",
    "lastName": "Doe"
  },
  "createdAt": "2024-01-15T10:30:00Z"
}
6

Save the Event

Click “Create Event” to save. Your event is now available for use in workflows and ready to receive triggers.
Animation showing the process of creating a new event: navigating to Events section, clicking Create Event button, entering event name and identifier, defining expected payload

Auto-Detection

Events are automatically created when you trigger an identifier that doesn’t exist yet. This is useful during development when you’re iterating quickly.
import { FlowrippleClient } from '@flowripple/sdk';

const flowripple = new FlowrippleClient({
  apiKey: process.env.FLOWRIPPLE_API_KEY
});

// This creates the event if it doesn't exist
await flowripple.trigger('subscription.renewed', {
  subscriptionId: 'sub_456',
  plan: 'premium',
  amount: 99.99
});
When an event is auto-created:
  • The identifier becomes the event name
  • Variables are extracted from the payload automatically
  • The event appears in your dashboard for further configuration
Auto-detection is great for prototyping, but consider manually creating events for production to ensure consistent payload structures and clear naming.

Identifier Rules

Event identifiers must follow these rules:
RuleExampleInvalid Example
Lowercase onlyuser.signupUser.SignUp
Letters, numbers, dots, dashesorder-v2.createdorder_created
No spacespayment.completedpayment completed
No leading/trailing dotsuser.signup.user.signup.
Unique per projectOne user.signup per project
Identifiers are immutable once created. Choose your identifiers carefully—you cannot change them later without creating a new event.

Naming Conventions

Use dot notation to organize events by domain and action:
{domain}.{action}
{domain}.{subdomain}.{action}

Good Examples

IdentifierDescription
user.signupUser signed up
user.loginUser logged in
order.createdOrder was created
order.item.addedItem added to order
payment.completedPayment was successful
subscription.renewedSubscription renewed

Naming Tips

  • Be specific: order.created is better than order
  • Use past tense for completed actions: payment.completed not payment.complete
  • Group by domain: All user events start with user.*
  • Avoid abbreviations: subscription.cancelled not sub.can

Expected Payload Schema

Defining an expected payload helps with:
  • Variable extraction: Flowripple knows what data to expect
  • Documentation: Team members understand the event structure
  • Validation: Catch payload mismatches early

Payload Best Practices

Always include relevant IDs so workflows can reference specific entities:
{
  "userId": "usr_123",
  "orderId": "ord_456"
}
Flowripple automatically detects ISO 8601 dates and provides date-specific functionality:
{
  "createdAt": "2024-01-15T10:30:00Z",
  "expiresAt": "2024-02-15T10:30:00Z"
}
Include only data needed by your workflows. Avoid sending entire database records:
// Good - focused data
{
  "userId": "usr_123",
  "email": "[email protected]",
  "plan": "premium"
}

// Avoid - too much data
{
  "user": { /* entire user record */ }
}

What’s Next?