Refer to the below table to understand details to be filled.

Below the endpoint, API request configuration has three tabs:

Configure Request Body

For the POST method, you also have to configure a request body.

Personalise the request per user

Anywhere a value should differ per user like a customer ID in the URL or a SKU in the query string or a token in a header, write a Liquid placeholder like below:

https://api.brand.com/v1/products/{{ sku }}

A Parameters tab for a weather lookup might look like this:

A Headers tab can mix static and dynamic values:

🔒

Authorization is stored securely at the connection level, not on user profiles. Credentials never render in the UI, never appear in previews, and never show up in logs.

Every placeholder used anywhere in the request like URL, headers, parameters, or body, must be declared before the connection can be saved. For each one, you have to tell Netcore where the value comes from. Refer to the table below for reference.

Netcore refuses to save if any placeholder is used but not declared. This catches typos and prevents connections that would silently fail at send time.

The Test action is the gate between a draft and a usable connection. You cannot activate until the test succeeds.

1. Provide dummy values. Map each declared parameter to a static dummy value so the test is deterministic and doesn't depend on live user data:

   sku          →  "SKU-1234"
   customer_id  →  "cust_98765"
   region       →  "IN"

2. Run the test. Netcore executes the request with the dummy values and shows you exactly what was sent and returned:

   • The final resolved URL (with dummy values substituted)
   • Request headers and body
   • Response status code
   • Response body
   • Round-trip latency

3. Fix and re-test if needed. On any failure (auth error, timeout, 4xx/5xx), correct the config and run again. You want a clean 2xx before moving on.

Once the test returns successfully, map the response fields into stable internal labels. Labels are what marketers see and use in the editor.

Why labels

The raw response is your engineering schema:

{
  "data": {
    "price": 4499,
    "inventory": 12,
    "tier": "premium"
  }
}

A marketer shouldn't need to know price lives at data.price — they should just write {{ product_price }}. The label is that translation.

🔎

Needs verification

Claim under review: "Netcore parses and flattens nested JSON so deep fields are selectable." Confirm this covers array paths like recommendations[0].name from the original doc — if flattening doesn't support array indexing, the Recommendations use case above needs a caveat.

Add the mappings:

Only mapped fields are usable. Anything you don't map is not accessible in campaigns.

👍

Labels are immutable once used

Once a campaign or journey uses a label, it cannot be renamed or repurposed — this protects live campaigns from silently breaking. To change the shape of the data, add a new label instead of editing an existing one.

A connection saves only when all of these hold:

• Every placeholder is declared.
• The test passed (or was explicitly overridden by an authorised user).
• Response mapping is complete.
• There's no schema ambiguity.

Test integrity: why Activate keeps switching off

Two rules guarantee that what goes live always matches what was last tested:

1. Change the request, lose the response. Any edit to the method, URL, auth, headers, parameters, body, or declared parameters clears the fetched response and flags the mappings for re-validation.
2. Activate re-arms only on a fresh test. Activate stays disabled until a successful test exists for the current request. Any later change disables it again until you re-test.

⚠️

Note on credential rotation

Rotating a key or password counts as a request change — it triggers a re-test and re-activation. Plan for a quick re-test after rotating secrets.