Skip to main content

Create a new rule

POST 
/v2/endpoints/:endpoint/rules

Creates a new mock rule and appends it to the end of the rule list (lowest priority). The rule will be evaluated last in the execution order.

Purpose: A mock rule encapsulates conditions (request matching criteria) and actions (response behavior). Rules are the core building blocks that define how your mock server responds to incoming requests.

How It Works:

  1. Rule Structure: Each rule consists of:

    • enabled: Boolean flag to activate/deactivate the rule
    • method: HTTP method to match (GET, POST, PUT, DELETE, etc., or '*' for any)
    • conditions: Array of 1-5 matching criteria (ALL must match for the rule to trigger)
    • action: The behavior to execute when conditions match (mock response, proxy, CRUD, etc.)
    • description: Optional human-readable label for rule management

  2. Condition Matching (AND Logic):

    • All conditions in a rule must match for the rule to qualify
    • Supported condition types: equals, starts_with, contains, regex, template, header, body, body_param, state, graphql, soap_action
    • Conditions can match against request data or state store variables
    • Path conditions support regex with named groups for extracting path parameters

  3. Rule Execution Order:

    • Rules are evaluated top-to-bottom (first match wins)
    • New rules created via this API are inserted at the bottom (lowest priority)
    • To change priority, use the reorder endpoint or drag-and-drop in the UI
    • Once a rule matches, its action executes and no further rules are evaluated

  4. Action Types:

    • mock: Return a predefined HTTP response (static or templated)
    • weighted: Randomly select from multiple responses based on probability weights
    • callout: Forward request to external API (sync proxy or async webhook)
    • crud: Enable automatic CRUD operations for a resource
    • grpc: Mock gRPC responses (unary or streaming)

Limitations:

  • Maximum 5 conditions per rule
  • For OR logic, create multiple rules with different conditions
  • Rule IDs are auto-generated and cannot be specified
  • Rules cannot be inserted at a specific position (always appended to the end)

Best Practices:

  • Place specific/narrow rules at the top (higher priority)
  • Place broad/catch-all rules at the bottom (lower priority)
  • Use descriptive names in the description field for easier management
  • Test rule matching using the dashboard's request history API
  • Use state conditions for stateful mock scenarios (e.g., login flows)

Response: Returns the created rule with its auto-generated id field.

Request​

Responses​

Rule created