Skip to main content

​
Overview

This endpoint demonstrates KrakenD’s sequential processing capability, where the response from the first backend call is used as input for the second backend call. HTTP Method: GET
Endpoint: /sequential

​
What It Demonstrates

  • Sequential Processing: Executes backend calls in order, not in parallel
  • Response Chaining: Uses data from the first response in the second request
  • Dynamic URL Construction: Builds the second URL using values from the first response
  • Multi-step Data Fetching: Implements lookup patterns (e.g., get ID, then fetch details)

​
Request Example

curl http://localhost:8080/sequential

​
Expected Response

{
  "destination_id": 123,
  "destination_name": "Paris",
  "country": "France",
  "description": "The City of Light",
  "attractions": [
    "Eiffel Tower",
    "Louvre Museum",
    "Notre-Dame Cathedral"
  ],
  "best_time_to_visit": "April-June, September-October"
}

​
How It Works

​
Step 1: Fetch Hotel Data

First, KrakenD calls the hotels endpoint: Backend URL: http://fake_api/hotels/1.json Response: 
{
  "id": 1,
  "name": "Grand Hotel",
  "destination_id": 123,
  "rating": 4.5,
  "price": 200
}
Filtered Response (only destination_id is allowed): 
{
  "destination_id": 123
}

​
Step 2: Fetch Destination Data

Then, KrakenD uses the destination_id from Step 1 to construct the second URL: Backend URL: http://fake_api/destinations/123.json Response: 
{
  "destination_id": 123,
  "destination_name": "Paris",
  "country": "France",
  "description": "The City of Light",
  "attractions": [...]
}

​
Step 3: Merge Responses

KrakenD merges both responses: 
{
  "destination_id": 123,
  "destination_name": "Paris",
  "country": "France",
  "description": "The City of Light",
  "attractions": [...],
  "best_time_to_visit": "April-June, September-October"
}

​
Backend Services Called

​
1. Hotels Service

  • Host: http://fake_api (inherited from global config)
  • URL Pattern: /hotels/1.json
  • Allowed Fields: destination_id
  • Purpose: Fetches the hotel record to extract the destination ID

​
2. Destinations Service

  • Host: http://fake_api (inherited from global config)
  • URL Pattern: /destinations/{resp0_destination_id}.json
  • Purpose: Fetches full destination details using the ID from Step 1
  • Variable: {resp0_destination_id} is replaced with the value from the first response

​
KrakenD Configuration

{
  "@comment": "Feature: Sequential calls, using values from 1st call response into 2nd call request",
  "endpoint": "/sequential",
  "backend": [
    {
      "url_pattern": "/hotels/1.json",
      "allow": ["destination_id"]
    },
    {
      "url_pattern": "/destinations/{resp0_destination_id}.json"
    }
  ],
  "extra_config": {
    "proxy": {
      "sequential": true
    }
  }
}

​
Key Configuration Options

​
Sequential Processing

{
  "proxy": {
    "sequential": true
  }
}
  • Default Behavior: KrakenD executes backend calls in parallel
  • With sequential: true: Backends are called in order
  • Requirement: Necessary for response chaining to work

​
Response Variable Syntax

{
  "url_pattern": "/destinations/{resp0_destination_id}.json"
}
Format: {resp[N]_field_name}
  • resp[N]: References the Nth backend response (0-indexed)
  • field_name: The field to extract from that response
  • Example: {resp0_destination_id} gets destination_id from the first backend

​
Field Filtering

{
  "allow": ["destination_id"]
}
Filtering the first response is optional but recommended:
  • Reduces memory usage
  • Makes the chaining intent clear
  • Prevents field conflicts in the merged response

​
Response Merging

KrakenD merges all backend responses: First Backend: 
{"destination_id": 123}
Second Backend: 
{
  "destination_id": 123,
  "destination_name": "Paris",
  "country": "France"
}
Final Response: 
{
  "destination_id": 123,
  "destination_name": "Paris",
  "country": "France"
}
Note: If fields overlap, the later response takes precedence.

​
Use Cases

  • ID Lookup Patterns: Fetch ID from one service, details from another
  • Multi-step Workflows: Order processing, booking confirmations
  • Reference Resolution: Expand foreign keys into full objects
  • Dependent Queries: Second query depends on first query results
  • Legacy System Integration: When APIs aren’t designed for parallel access

​
Performance Considerations

​
Trade-offs

Advantages:
  • Enables complex data fetching patterns
  • Reduces client complexity
  • Allows single-request workflows
Disadvantages:
  • Higher latency (sequential, not parallel)
  • First call failure blocks second call
  • Increased gateway processing time

​
When to Use

✅ Use Sequential Calls When:
  • Second call truly depends on first response
  • Data relationships require it
  • Total calls are few (2-3)
❌ Avoid Sequential Calls When:
  • Calls are independent (use parallel aggregation instead)
  • Many steps are needed (consider async patterns)
  • Low latency is critical

​
Advanced Patterns

​
Multiple Fields

You can use multiple fields from previous responses: 
{
  "url_pattern": "/api/{resp0_user_id}/{resp1_category_id}"
}

​
Nested Fields

Access nested response fields: 
{
  "url_pattern": "/api/{resp0_data.user.id}"
}

​
More Than Two Steps

Chain multiple backends: 
{
  "backend": [
    {"url_pattern": "/step1"},
    {"url_pattern": "/step2/{resp0_id}"},
    {"url_pattern": "/step3/{resp1_code}"}
  ]
}

Build docs developers (and LLMs) love

Get started for freeTalk to us