Check if a given key exists in a JSON REST API payload

Working with REST APIs almost always means parsing JSON, and a recurring task is checking whether a specific key is present in the payload before you act on it. A classic example is pagination: a Twitter (X) API response includes a next_token field only when more pages remain, so your flow needs to detect that key reliably to decide whether to keep fetching. This blueprint shows three idiomatic ways to test for a key in a JSON object using Kestra expressions, so you can pick the style that reads best for your pipeline and branch on the result.

How it works

The flow defines a single json input of type JSON whose default payload mimics a paginated API response with a meta object containing next_token, oldest_id, newest_id, and result_count. Four tasks then evaluate that payload:

• jq_filter is an io.kestra.plugin.core.log.Log task that runs the jq filter .meta | has("next_token") and logs whether the key exists.
• contains is an io.kestra.plugin.core.debug.Return task that uses the Pebble contains operator: {{ inputs.json["meta"] contains "next_token" }}.
• contains_if_else_operator is another io.kestra.plugin.core.debug.Return task that wraps contains in an {% if %} / {% else %} block to return an explicit true or false.
• is_not_null_operator is a final io.kestra.plugin.core.debug.Return task that checks {% if inputs.json["meta"]["next_token"] is not null %} for a value-based test.

What you get

• Three proven patterns for key presence checks: a jq filter, the contains operator, and an is not null test.
• A ready-to-run payload you can swap for your own API response.
• A template for conditional branching on pagination tokens or optional fields.

Who it's for

• Data engineers integrating paginated or optional-field REST APIs.
• Platform teams standardizing how flows parse and validate JSON.
• Anyone learning Kestra Pebble expressions and jq filtering.

Why orchestrate this with Kestra

A raw API or a cron scheduler can fetch JSON but cannot express conditional logic over the response. Kestra lets you parse payloads inline with declarative YAML, branch on the result, and chain follow-up tasks (loop until next_token is absent, fan out per record, or alert on missing fields). You gain event triggers, automatic retries on transient API failures, and full execution lineage over every parse, none of which the API itself provides.

Prerequisites

• A running Kestra instance.

Secrets

This flow references no secrets. When you point it at a live API behind authentication, store the token as a secret (for example {{ secret('API_TOKEN') }}) rather than hardcoding it.

Quick start

1. Add the flow to your Kestra instance.
2. Execute it with the default json payload to see all three checks return true.
3. Edit the payload to remove next_token and re-run to watch the checks flip to false.

How to extend

• Replace the default input with an io.kestra.plugin.core.http.Request task that fetches a live API response.
• Wrap the flow in a loop that keeps paginating while next_token is present.
• Use the boolean result in an if condition to skip or trigger downstream tasks.

Links

• Plugin docs: https://kestra.io/plugins/plugin-core
• Expressions documentation: https://kestra.io/docs/concepts/expression