Endpoint Configuration

Each endpoint in a connector requires specific configuration. This guide covers all endpoint settings.

Basic Settings

Field	Description	Example
`path`	API endpoint path	`/users/{user_id}/messages`
`method`	HTTP method	`GET`, `POST`
`friendlyName`	Human-readable name	"List User Messages"
`category`	Logical grouping	users, messages, files
`description`	What this endpoint collects	"Retrieves all messages for a user"
`order`	Execution order (lower runs first)	1, 2, 3
`enabled`	Whether to include in collections	true/false

Path Templates

Use curly braces for dynamic path segments:

/repos/{owner}/{repo}/commits
/users/{user_id}/channels/{channel_id}/messages

Template values are populated from:

Dependency mappings (from other endpoints)
Reusable variables
Collection parameters
Credential metadata

Custom Headers

Add endpoint-specific headers that override connector defaults:

{
  "headers": {
    "Accept": "application/json",
    "X-Custom-Header": "value"
  }
}

These are per-endpoint overrides — they supplement or replace headers defined at the connector level.

Query Parameters

Add static query parameters:

{
  "queryParams": {
    "include_deleted": "true",
    "types": "public_channel,private_channel"
  }
}

Body Parameters

For POST, PUT, and PATCH endpoints, configure the request body:

Body Types

Type	Description
none	No request body
json	JSON body (most common)
form-data	Multipart form data
urlencoded	URL-encoded form
raw	Raw text body

Configuring Body Content

Select the endpoint
Open the Config tab in the endpoint editor
Choose body type (json, form-data, etc.)
Enter the body content template (the JSON editor supports {param} placeholders for dependency values)

For JSON bodies, you can include dynamic values from dependency mappings:

{
  "query": "search term",
  "filter": {
    "status": "active"
  }
}

Body parameters can also be targets for dependency mappings — set targetParameterLocation to body when creating a mapping.

Recursion Configuration

For endpoints that traverse hierarchical data (e.g., file trees, nested pages), enable recursive collection:

When to Use

APIs with parent-child relationships (e.g., Notion blocks, file system folders)
Endpoints where calling with a parent ID returns children that may themselves have children

Configuration Fields

Field	Description	Example
ID Path	JSON path to extract child IDs from the response	`results[*].id`
URL Parameter	Which path parameter receives the child ID	`id` in `/blocks/{id}/children`
Condition Path	(Optional) Boolean field to filter which items to recurse into	`results[*].has_children`
Condition Value	Whether to recurse when condition is `true` or `false`	`true`
Max Depth	Maximum recursion depth (1–10, default 5)	`5`

How It Works

The endpoint is called normally (root call)
Response is checked for child IDs using ID Path
If Condition Path is set, only items matching the condition are recursed
For each child ID, the same endpoint is called with the ID substituted into URL Parameter
This repeats up to Max Depth levels

Testing Recursion

Use the Test button next to the ID Path field to preview extracted values from the current response. This shows how many child IDs would be found without actually making recursive calls.

Example: Notion Blocks

Endpoint: GET /blocks/{block_id}/children
ID Path: results[*].id
URL Parameter: block_id
Condition Path: results[*].has_children
Condition Value: true
Max Depth: 5

Flow:
  1. GET /blocks/page-123/children → finds 3 child blocks
  2. For children with has_children=true:
     GET /blocks/child-1/children → finds 2 grandchildren
     GET /blocks/child-2/children → finds 0 grandchildren
  3. Continues until max depth or no more children

Conditional Execution

Endpoints can have execution conditions that determine whether they run based on runtime data. This is useful for skipping endpoints when their data source is empty or when certain conditions aren't met.

Condition Types

Type	Description
Endpoint condition	Check if a preceding endpoint returned data at a specific path
Variable condition	Check the number of values in a variable

Logic Modes

All (AND): Every condition must pass for the endpoint to execute
Any (OR): At least one condition must pass

Live Evaluation

Conditions are evaluated against current test data and show per-condition pass/fail indicators, making it easy to verify your conditions work correctly before running a collection.

See Endpoint Conditions for the full guide.

Response Transformations

Apply a chain of post-processing transformations to endpoint responses before variable extraction. This is useful for normalizing nested API responses.

Available Transformations

Operation	Description
Flatten	Flatten nested objects into a single level
Rename	Rename fields in the response
Filter	Filter array items by condition
Map	Extract specific fields from array items
Pick	Keep only specified top-level fields
Omit	Remove specified top-level fields
Combine	Combine multiple fields into one

Transformations are applied in order, and each step can be individually enabled or disabled. The editor shows a live preview comparing original vs transformed data.

See Response Transformations for the full guide.

Forensic Relevance

Mark endpoints as forensically relevant when they contain:

User activity data
Communication records
Access logs
File metadata
Timestamps and audit trails

Non-relevant endpoints (like configuration) can still be collected but may be deprioritized.

Rate Limiting

Override global rate limit for specific endpoints:

{
  "rateLimit": {
    "requests": 10,
    "windowSeconds": 60
  }
}

Use lower limits for:

Heavy endpoints
Endpoints with stricter platform limits
Endpoints that return large responses

Data Extraction

Configure how data is extracted from responses:

{
  "dataExtraction": {
    "path": "$.data.items",
    "fileNaming": "users_{cursor}.json"
  }
}

JSON Path

Path	Matches
`$`	Root object
`$.data`	Property named "data"
`$.items[*]`	All items in array
`$.data.users[*].id`	All user IDs

File Naming

Templates support:

{cursor} - Current cursor value
{page} - Current page number
{offset} - Current offset
{timestamp} - ISO timestamp
{endpoint_id} - Endpoint identifier
Any path parameter (e.g., {user_id})

Execution Order

The order field determines execution sequence:

order: 1  →  order: 2  →  order: 3
users.list    channels.list    messages.history

Endpoints with dependencies always wait for source endpoints regardless of order.

Enabling/Disabling

Toggle endpoints without deleting:

Enabled: Included in collections
Disabled: Skipped during collection

Reasons to disable:

Endpoint not needed for current use case
Platform deprecated the endpoint
Data not forensically relevant
Temporary issues with endpoint

Analyst Notes

Add notes for future reference:

Why endpoint was enabled/disabled
Platform-specific quirks
Configuration decisions
Known issues

Notes are visible to all analysts. Unacknowledged notes show an amber indicator in the Execution Order panel.

Best Practices

Use descriptive names - "List Team Members" not "GET /teams/members"
Group by category - Consistent categorization aids review
Document decisions - Use notes for non-obvious choices
Set appropriate order - Dependencies should run first
Configure rate limits - Respect platform limits
Use conditions - Skip endpoints when their prerequisites aren't met
Use transformations - Normalize responses before extraction when APIs return inconsistent structures

Basic Settings​

Path Templates​

Custom Headers​

Query Parameters​

Body Parameters​

Body Types​

Configuring Body Content​

Recursion Configuration​

When to Use​

Configuration Fields​

How It Works​

Testing Recursion​

Example: Notion Blocks​

Conditional Execution​

Condition Types​

Logic Modes​

Live Evaluation​

Response Transformations​

Available Transformations​

Forensic Relevance​

Rate Limiting​

Data Extraction​

JSON Path​

File Naming​

Execution Order​

Enabling/Disabling​

Analyst Notes​

Best Practices​

Next Steps​