Testing Mode lets you run pipeline logic without affecting actual pipeline execution.

That means you can validate:

• routing
• filtering
• enrichment
• merge behavior
• connector payload structure

…without accidentally pushing real updates to a marketplace or polluting production logs with “test objects”.

The results are still observable (tracked like normal executions), but they’re flagged as test runs.

Pinned Data is a mechanism that replaces the live output of a processor with fixed mock data.

In normal runs:

• a processor does its real job (HTTP call, connector sync, etc.)
• output depends on external systems, network, timing

In test runs with pinned data:

• the processor’s real work is skipped
• the output becomes deterministic
• downstream steps can be tested with certainty

This is the classic integration engineer’s dream:

> “Let me test the next steps, even if the external API is flaky today.”

1) Test the full pipeline end-to-end (with pinned entry data)

You provide pinned data for the entry processor, simulating the trigger object.

Result: the pipeline runs end-to-end on a controlled input, producing deterministic outputs.

2) Test a single processor using real historical context

You provide a previous Pipeline Execution ID.

Qilin loads the execution context from that run and re-executes only the processor you’re testing.

This is perfect when:

• you changed an enrichment rule
• you adjusted a filter predicate
• you want to replay one step against real production-like data

3) Test a processor in isolation (no historical context needed)

You provide pinned input directly for the processor.

Result: fast, isolated, great for validating configs and behavior without waiting for upstream steps.

You want to verify enrichment logic that depends on a pricing service.

But the pricing API is unstable today.

Pinned data lets you fake the pricing output so you can test:

• calculations
• mapping
• downstream connector payloads

No external dependency. No waiting. No chaos.

Agencies live and die by delivery speed and reliability.

Testing Mode enables a cleaner workflow:

• build pipeline logic
• test with pinned scenarios
• validate edge cases
• only then turn on live execution

That’s how you reduce go-live risk without multiplying custom tooling.

• deterministic tests for pipeline logic
• faster iteration loops
• easier debugging (“same input, same output”)
• safer experimentation with advanced processors (merge, switch-case, enrichment, http calls)

• fewer production incidents caused by “untested config changes”
• faster onboarding because pipelines can be validated before real data flows
• stronger platform trust: changes are intentional and verifiable

February will continue the “operational control” theme:

• expanded UI management for queue storage and credentials
• more advanced routing and processor configuration in the portal

Because once pipelines grow, operations needs knobs – not prayers.

The traditional way of testing pipelines is stressful because it mixes two activities:

• validating logic
• operating production

Testing Mode separates them.

And honestly? That’s long overdue.

A webhook is the digital version of a doorbell.

Instead of polling (“did something change yet?”), an external system rings the bell when it has something to say.

The Webhook Entry Processor gives you:

• a stable webhook entry point
• authentication via a stored credential
• a predictable way to transform incoming payload into a FlowObject

A minimal config looks like:

{
  "id": "Webhook_Entry_1",
  "type": "Qilin.WebhookEntry",
  "config": {
    "webhookId": "your-webhook-id",
    "credentialId": "credential-guid",
    "authType": "BasicAuth"
  }
}

Now your pipeline can start the moment something happens:

• price update from a repricer
• order created in a shop system
• ERP pushes a shipment status update
• a partner system signals “new catalog batch ready”

No cron job required. No polling tax.

The HTTP Request Processor is the workhorse for “call this API and use the result”.

It supports classic requirements you’d usually implement in custom code:

• method, URL, headers, query params
• retries and retry intervals
• timeouts
• expected status codes
• payload mapping from pipeline context (dynamic values)
• optional authentication via stored credentials

A simplified example:

{
  "id": "Http_Request_1",
  "type": "Qilin.HttpRequest",
  "config": {
    "processorHttpMethod": "GET",
    "url": "https://api.example.com/products/{{FlowObjectContents.entry.sku}}",
    "expectedStatusCodes": [200],
    "timeoutInSeconds": 30,
    "retryTimes": 3
  }
}

So instead of writing a custom microservice for every “call an API” step, you can keep the logic inside the pipeline – auditable, trackable, and reusable.

HTTP calls and webhooks are only as good as their authentication.

And authentication is where teams often end up doing unsafe things because it’s “just faster”.

Qilin’s Processor Credentials are meant to restore sanity:

• credentials are created once
• referenced by ID in processors
• managed with permissions (RBAC)
• reused across pipelines consistently

Credential types can represent common auth patterns, for example:

• Basic authentication
• header-based API keys
• OAuth2 client credentials
• SMTP / email provider credentials (more on that later this year)

That keeps secrets out of pipeline definitions – and makes it easier to rotate credentials without rewriting everything.

Imagine this flow:

1. repricer sends a webhook with SKU + new price
2. pipeline validates the payload
3. pipeline calls ERP via HTTP Request Processor to fetch product context
4. pipeline enriches and maps data
5. pipeline exports updated offer to a marketplace connector

In the old world, that’s:

• a webhook endpoint service
• an HTTP client service
• a mapping layer
• plus monitoring glue

In Qilin.Cloud, it becomes a pipeline.

Developers

• fewer one-off services
• consistent retry + timeout behavior across integrations
• observable steps (not “black box code”)
• credential reuse without leaking secrets into configs

Merchants + agencies

• faster delivery of custom flows
• less infrastructure to host and maintain
• easier handover because the logic is visible in the platform

Investors

This is platform extensibility. Every reusable processor reduces implementation effort per customer and increases the range of use cases Qilin can serve.

Once you can trigger flows and call APIs, you quickly need a third thing:

how to combine results reliably.

Next month we’ll explore merge strategies, retry patterns, and the reliability primitives that make complex pipelines behave like adults.

This isn’t a rejection of the old way.

It’s the old way – webhooks, HTTP calls, credentials, retries – captured as reusable building blocks.

Same wisdom. Less duct tape.