Testing Endpoint

Testing your decision flow endpoints is crucial to ensure they work correctly before deployment. This guide covers various methods and tools you can use to test your endpoints effectively.

Important: The API response always includes your complete original input data, enriched with additional fields created during decision execution. Your input is never discarded - it forms the base of the response with decision outputs added to it.

Prerequisites

Before testing your endpoint, ensure you have:

• Endpoint URL - Available in the decision management portal
• API Key - Required for authentication
• Sample JSON data - Test data that matches your decision flow's expected input structure

Authentication Methods

The API supports two authentication methods:

1. X-API-KEY Header (recommended) - Include X-API-KEY: your-api-key in request headers
2. Basic Authentication - Use endpoint name as username and API key as password

Quick Connectivity Test

To verify endpoint availability without executing the decision flow, include the X-Test: true header. The endpoint will respond with 200 OK if reachable.

Testing Process Overview

1. Verify endpoint availability and gather necessary credentials
2. Prepare test data in valid JSON format
3. Send test requests using your preferred tool
4. Analyze responses to validate decision flow behavior
5. Iterate and refine based on test results

Testing with cURL

cURL is a command-line tool perfect for quick endpoint testing:

curl -X POST \
  https://your-endpoint.decisimo.com/v1/execute/your-endpoint-name \
  -H 'X-API-KEY: your-api-key' \
  -H 'Content-Type: application/json' \
  -d '{
    "personal_info": {
      "name": "John Doe",
      "age": 35,
      "salary": 50000,
      "num_children": 2,
      "address": {
        "street": "123 Main Street",
        "city": "Anytown",
        "state": "CA",
        "zip": "12345"
      }
    }
  }'

Key Points:

• Replace your-endpoint-name with your actual endpoint name (visible in the deployment portal)
• Replace your-api-key with your valid API key
• Modify the JSON data to match your specific use case
• Use proper JSON formatting (no trailing commas)

Testing with Postman

Postman provides a user-friendly interface for API testing:

Setup Steps

1. Create New Request

   • Method: POST
   • URL: https://your-endpoint.decisimo.com/v1/execute/your-endpoint-name

2. Configure Headers

   • Add header: X-API-KEY with your API key value
   • Add header: Content-Type with value application/json

3. Set Request Body

   • Select "raw" format
   • Choose "JSON" from dropdown
   • Enter your test data:

{
  "personal_info": {
    "name": "John Doe",
    "age": 35,
    "salary": 50000,
    "num_children": 2,
    "address": {
      "street": "123 Main Street",
      "city": "Anytown",
      "state": "CA",
      "zip": "12345"
    }
  }
}

4. Send Request and review the response

Postman Advanced Features

• Collections - Save and organize test requests
• Environment Variables - Manage different API keys and endpoints
• Test Scripts - Automate response validation
• Mock Services - Simulate endpoint responses during development

Response Validation

When testing endpoints, verify:

Status Codes

• 200 OK - Successful execution
• 400 Bad Request - Invalid JSON format or empty request body
• 401 Unauthorized - Missing API key
• 404 Not Found - Endpoint not found or invalid API key
• 500 Internal Server Error - Server-side execution error
• 501 Not Implemented - Non-POST request method used

Error Response Format

When an error occurs, the response contains an error field with the error message:

{
  "error": "Malformed JSON"
}

Common error messages:

• "No content" - Request body is empty
• "Malformed JSON" - Invalid JSON syntax
• "Missing API Key" - No API key provided

Response Structure

The response always contains your complete original input data. The API does not discard your input - instead, it returns your original request JSON enriched with additional fields set during decision making. This "pass-through" behavior means:

1. All input fields are automatically included - Every field you send is returned in the response
2. Decision outputs are added - New fields created by rules, decision tables, scorecards, or models are added to the response
3. No configuration needed - You do not need to configure your decision flow to "output" input fields; they are always preserved automatically

For example, if you send this request:

{
  "personal_info": {
    "name": "John Doe",
    "age": 35,
    "salary": 50000,
    "num_children": 2
  }
}

A typical successful response would include:

{
  "personal_info": {
    "name": "John Doe",
    "age": 35,
    "salary": 50000,
    "num_children": 2
  },
  "decision": "approved",
  "risk_score": 0.15,
  "credit_limit": 25000,
  "reasons": ["income_sufficient", "good_credit_score"],
  "__request_code": "a1b2c3d4e5f6...",
  "__release_name": "Loan Approval v1.2"
}

Key points about the response:

• All input fields are automatically preserved - Your complete original request data is always included in the response. You do NOT need to configure anything to include input in the output.
• Decision output fields are added - New fields created by rules, decision tables, or models are added alongside your input
• Input and output coexist - The response merges your input with the decision outputs into a single JSON object
• Technical fields - Fields prefixed with __ provide execution metadata:
  • __request_code - Unique identifier for this request execution
  • __release_name - Name of the decision flow version that was executed
  • __executed_steps - Array of steps that were executed (add ?record_steps=1 or ?record_steps=2 to URL for more detail)
  • __executed_steps_count - Count of executed steps (when record_steps is enabled)
  • __lineage - Tracking of data transformations (add ?record_lineage=1 for basic lineage with step/state/delta, or ?record_lineage=2 for enhanced lineage including step_type)

Common Testing Scenarios

Edge Cases

• Empty JSON object - Test with {} (valid request, decision flow runs with no input data)
• Empty request body - Returns 400 Bad Request with "No content" error
• Missing required fields - Remove key data points to verify decision flow handles missing data
• Invalid data types - Send strings where numbers expected
• Large payloads - Test payload size limits

Data Variations

• Boundary values - Test minimum/maximum acceptable values
• Special characters - Include unicode, symbols, emojis
• Different formats - Various date formats, currency representations

Load Testing

• Concurrent requests - Multiple simultaneous calls
• Rate limiting - Test API throttling behavior
• Timeout scenarios - Very large or complex decision flows

Best Practices

Data Preparation

• Use realistic test data that represents actual use cases
• Include edge cases in your test dataset
• Validate JSON format before sending requests
• Test with currency handling if applicable

Security Testing

• Test without API key to verify authentication
• Use invalid API keys to test error handling
• Test with different user permissions if applicable

Performance Testing

• Measure response times under various loads
• Test with different payload sizes
• Monitor resource usage during testing

Documentation

• Record test cases and expected outcomes
• Document any issues found during testing
• Maintain test data sets for regression testing

Troubleshooting Common Issues

Frequently Asked Questions

Is my input included in the response?

Yes, always. The complete input you send is automatically included in the response. The API uses a "pass-through enrichment" model where your original request JSON forms the base of the response, and decision outputs are added as additional fields. You do not need to configure anything to include input data in the output - this happens automatically.

Note that input fields may be modified during decision flow execution if your rules explicitly update them. In such cases, the response contains the final (modified) values. To track how values changed throughout execution, use the lineage feature (?record_lineage=1 or ?record_lineage=2) which preserves the state at each step.

Do I need to configure outputs to return input fields?

No. Unlike some decision engines that require you to explicitly map inputs to outputs, Decisimo automatically preserves all input fields. Your decision flow only needs to define the new fields it creates (like decision, score, risk_level, etc.). The input fields are passed through automatically (unless modified by decision logic).

Can I track changes to input fields?

Yes, using lineage. If your decision flow modifies input fields during execution, you can track these changes by enabling lineage recording. Add ?record_lineage=1 to your request URL to see the state and delta at each step, allowing you to trace exactly when and where a field was changed.

Can I exclude input fields from the response?

The API always returns the complete enriched object. If you need to filter the response, you would do so in your application code after receiving the response.

Related Topics:

• API Endpoint Integration - Complete API integration guide
• Webhook Endpoint Integration - Asynchronous endpoint testing
• Currency Handling Guide - Testing with monetary values
• Decision Flow - Understanding decision flow logic