create_mock
Create a new mock API endpoint in a project. IMPORTANT: Always use the 'rules' field to set up conditional response logic (the Rule Engine). The Rule Engine allows ONE mock endpoint to return DIFFERENT responses based on request content — this is the primary way to simulate multiple scenarios (success, error, validation failure, auth failure, etc.) without creating separate mocks. Rules are evaluated in ascending 'priority' order; the FIRST rule whose conditions match wins. If NO rule matches, the mock's top-level responseBody/responseStatus is used as the default fallback. Use the 'stateLookupExpr' and 'stateCaptureExpr' fields to enable stateful simulation (e.g., simulate a database that persists data across calls). If collectionName is provided but doesn't exist, it will be auto-created.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | A descriptive name for this mock endpoint (e.g. 'GET User by ID', 'POST Create Payment') | |
| path | Yes | HTTP resource path. Use curly braces for path variables, e.g. /v1/users/{id} or /orders/{orderId}/items/{itemId} | |
| tags | No | Tags for categorization and search, e.g. ['payment', 'checkout', 'transaction'] | |
| rules | No | RULE ENGINE: Array of conditional response rules. Each rule defines conditions to match and a different response to return. Rules are evaluated in ascending 'priority' order (1 = highest priority). The FIRST matching rule wins — subsequent rules are skipped. If NO rule matches, the mock's top-level responseBody/responseStatus is returned as fallback. This enables one mock to simulate: success, validation error, auth failure, rate limit, etc. — all in one endpoint. ALWAYS add rules when the endpoint has multiple response scenarios. | |
| method | Yes | HTTP method: GET, POST, PUT, DELETE, PATCH, etc. | |
| delayMs | No | Default simulated latency delay in milliseconds. Useful for testing timeout handling. | |
| projectId | Yes | Database ID of the project | |
| webhookUrl | No | Optional: URL to call as outbound webhook after each request hits this mock. Supports dynamic expressions. LOCAL RELAY OPTION: If developing locally, instead of a public URL, you can use the 'simceptor://local/<path>' scheme (e.g. 'simceptor://local/api/payment/callback') to route webhook payloads through an active Local Relay WebSocket tunnel to your local server. ALWAYS call 'check_relay_status' first to verify if a relay session is active. | |
| description | No | Optional detailed description of what this mock simulates. Visible in the dashboard UI. Helps team members understand the purpose. | |
| soapEnabled | No | Set to true to enable SOAP / WSDL mode for this mock. Auto-detected if responseHeaders contains 'xml' or responseBody starts with '<'. Set explicitly to true for SOAP services so the UI switches to WSDL / XML editor view. | |
| wsdlContent | No | Optional raw WSDL XML content definition for SOAP service discovery (?wsdl). | |
| responseBody | No | Default response body payload (used when no rule matches). Supports dynamic expressions: - {{path.id}} → path variable - {{query.page}} → URL query param - {{header.X-Token}} → request header value - {{body.user.name}} → JSON body field - {{random_uuid}} → generated UUID - {{faker.name_id}} → Indonesian fake name - {{faker.name_global}} → English fake name - {{state.fieldName}} → value from stateful session (requires stateLookupExpr) IMPORTANT: In JSON payloads, ALL placeholder expressions MUST be enclosed in double quotes (e.g. "amount": "{{body.amount:100000}}") to ensure valid JSON syntax for UI linters and parsers. Do NOT leave placeholders unquoted. Do NOT include raw newline characters (\n) in the JSON payload. NOTE: the tool response includes a `responseBodyWarning` field if responseBody doesn't look like valid JSON (checked structurally, ignoring placeholder values) — if present, fix the body and call test_mock to confirm before assuming the mock works. | |
| webhookMethod | No | HTTP method for the webhook. Default: POST. | |
| collectionName | No | Collection folder name to organize this mock (default: 'Default Collection'). Collections are like folders. | |
| responseStatus | No | Default HTTP status code (used when no rule matches). E.g. 200, 201. | |
| webhookDelayMs | No | Milliseconds to wait before firing the webhook after the response is sent. | |
| webhookHeaders | No | JSON string of headers for the webhook request. | |
| webhookPayload | No | Webhook request body. Supports dynamic expressions to forward request data. | |
| responseHeaders | No | Default response headers as JSON string, e.g. '{"Content-Type":"application/json","X-Custom":"value"}' | |
| stateLookupExpr | No | STATEFUL SIMULATION: Expression to look up a saved session state by key before evaluating rules. The resolved key is used to load state data previously saved by stateCaptureExpr. Once loaded, state fields become available in rule conditions as 'state.<fieldName>' and in responseBody as {{state.fieldName}}. E.g. 'request.body.user_id' → loads state for the given user_id. E.g. 'request.header.Authorization' → loads state by auth token. | |
| stateCaptureExpr | No | STATEFUL SIMULATION: Expression that determines the key under which to save session state AFTER this request is processed. The request body, response body, and any custom variables (stateCaptureVariables) are saved under this key in Redis (TTL: 15 minutes). Can reference: 'request.body.id', 'request.path.userId', 'response.body.token', etc. Pair with stateLookupExpr on other mocks to build stateful multi-step flows (e.g. register → login → get profile). | |
| stateCaptureVariables | No | STATEFUL SIMULATION: JSON object string mapping variable names to expressions. These named variables are extracted and saved alongside the full request/response snapshot. E.g. '{"balance":"request.body.amount","userId":"request.body.id"}' → saved as state.balance and state.userId, accessible on subsequent calls via stateLookupExpr. Each value MUST be an expression starting with one of: request./response./body./query./header./path./state./item./random./faker. Any value that does NOT start with one of those prefixes is stored as a literal string as-is (e.g. '{"status":"pending"}' saves the literal text "pending") — it is NOT evaluated as an expression. |