Webhook Entry & HTTP Request: Turning Qilin.Cloud into an Integration Swiss Army Knife

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.