Starts With
Checks if a string value starts with a specified prefix.
Overview
The starts_with condition evaluates whether a field's string value begins with a specified prefix. This is useful for matching URL paths, ID prefixes, namespace patterns, and other cases where the beginning of a string is significant.
Use Cases
- URL Path Routing: Route based on URL path prefixes
- ID Namespace Matching: Match IDs with specific prefixes
- Environment Detection: Identify environments by hostname prefixes
- Log Source Routing: Route logs based on source prefixes
Configuration
| Setting | Type | Required | Description |
|---|---|---|---|
key | string | Yes | The field path to check. Supports dot notation for nested fields. Use * to check all keys. |
value | string | Yes | The prefix to check for. |
case_insensitive | boolean | No | If true, performs case-insensitive comparison. |
not | boolean | No | If true, inverts the condition (matches if value does NOT start with prefix). |
Examples
URL Path Routing
Route API requests:
Code
Matches:
Code
Does not match:
Code
ID Prefix Matching
Match IDs with specific prefixes:
Code
Matches:
Code
Does not match:
Code
Case-Insensitive Prefix
Match protocols regardless of case:
Code
Matches:
Code
Environment Detection
Identify production hosts:
Code
Matches:
Code
Does not match:
Code
Exclusion Check
Match records that do NOT start with a prefix:
Code
Matches:
Code
Does not match:
Code
Nested Field Check
Check prefixes in nested fields:
Code
Matches:
Code
Log Source Routing
Route logs by source prefix:
Code
Matches:
Code
Common Patterns
API Version Routing
Route different API versions:
V2 API:
Code
V1 API (legacy):
Code
Multiple Prefix Matching
Route based on any of several prefixes:
Code
Public vs Internal Routes
Separate public and internal traffic:
Public routes:
Code
Internal routes:
Code
Exclude Static Assets
Filter out static asset requests:
Code
Combined Prefix and Suffix
Match both beginning and end:
Code
Matches:
Code
Service Namespace Routing
Route by service namespace:
Code
Best Practices
-
Include delimiters: Include trailing slashes or dots (e.g.,
/api/not/api) to avoid partial matches. -
Use
case_insensitivefor URLs: URLs may have inconsistent casing. -
Combine with
ends_with: For matching both prefix and suffix patterns. -
Consider URL encoding: URL paths may contain encoded characters.
-
Be specific: Longer prefixes are more precise and reduce false matches.
Type Handling
- Strings: Direct prefix comparison
- Numbers: Converted to strings first (e.g.,
123starts with"1") - Booleans: Converted to "true" or "false" strings
- Arrays/Objects: Not supported for direct comparison
- Missing fields: Returns
false(ortrueifnotis set)
Limitations
- Simple prefix matching only (no patterns or wildcards)
- Single prefix per condition (use
orfor multiple prefixes) - No support for matching multiple prefixes in one condition
Troubleshooting
Not matching expected values:
- Check for leading whitespace or special characters
- Verify case sensitivity settings
- Ensure the full prefix is specified
Unexpected matches:
- The prefix might be too short
- Add delimiters to make prefix more specific
Case sensitivity issues:
- Enable
case_insensitivefor user-generated content - URLs and paths may have mixed casing