> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flowripple.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Creating Events
> Step-by-step guide to creating and configuring events in Flowripple.
# 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.
In your project dashboard, go to the **Events** section in the sidebar navigation.
Click the **"Create Event"** button to open the event creation form.
Provide a descriptive name for your event (e.g., "User Signup", "Order Created"). This name helps identify the event in the dashboard.
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.
Specify the JSON structure your event will receive. This helps Flowripple extract variables and provides documentation for your team.
```json theme={null}
{
"userId": "usr_123",
"email": "user@example.com",
"profile": {
"firstName": "John",
"lastName": "Doe"
},
"createdAt": "2024-01-15T10:30:00Z"
}
```
Click **"Create Event"** to save. Your event is now available for use in workflows and ready to receive triggers.
## 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.
```typescript theme={null}
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
});
```
```bash theme={null}
curl -X POST https://api.flowripple.com/api/v1/trigger \
-H "Content-Type: application/json" \
-H "x-api-key: YOUR_API_KEY" \
-d '{
"identifier": "subscription.renewed",
"data": {
"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:
| Rule | Example | Invalid Example |
| ------------------------------ | ----------------------------- | ------------------- |
| Lowercase only | `user.signup` | `User.SignUp` |
| Letters, numbers, dots, dashes | `order-v2.created` | `order_created` |
| No spaces | `payment.completed` | `payment completed` |
| No leading/trailing dots | `user.signup` | `.user.signup.` |
| Unique per project | One `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
| Identifier | Description |
| ---------------------- | ---------------------- |
| `user.signup` | User signed up |
| `user.login` | User logged in |
| `order.created` | Order was created |
| `order.item.added` | Item added to order |
| `payment.completed` | Payment was successful |
| `subscription.renewed` | Subscription 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:
```json theme={null}
{
"userId": "usr_123",
"orderId": "ord_456"
}
```
Flowripple automatically detects ISO 8601 dates and provides date-specific functionality:
```json theme={null}
{
"createdAt": "2024-01-15T10:30:00Z",
"expiresAt": "2024-02-15T10:30:00Z"
}
```
Group related fields under nested objects for clarity:
```json theme={null}
{
"user": {
"id": "usr_123",
"email": "user@example.com"
},
"order": {
"id": "ord_456",
"total": 99.99
}
}
```
Include only data needed by your workflows. Avoid sending entire database records:
```json theme={null}
// Good - focused data
{
"userId": "usr_123",
"email": "user@example.com",
"plan": "premium"
}
// Avoid - too much data
{
"user": { /* entire user record */ }
}
```
## What's Next?
Learn more about payload structure and variable extraction.
Start triggering events from your application.