canonical: https://jentic.com/apis/apache.org

# Apache APIs

The Apache Software Foundation stewards open-source infrastructure projects, several of which expose HTTP APIs for programmatic control. On Jentic, Apache is represented by two of these: the Airflow stable REST API for workflow orchestration, and Qakka, the lightweight queue system from the Apache Usergrid project. Airflow lets external systems trigger and inspect DAG runs and manage connections, variables, datasets, and pools without the web UI. Qakka provides a small queue surface for service-to-service messaging where a full broker would be excessive. Both are self-hosted: the deployment host, auth backend, and base URL are set per installation rather than by a shared vendor endpoint.

## For AI agents

An agent can trigger and monitor Apache Airflow DAG runs, inspect task instances, and manage Airflow connections and variables, and can create queues, enqueue and dequeue messages, and acknowledge processed work on a self-hosted Qakka deployment.

## Scope

Use for: Operating self-hosted Apache infrastructure from automation: triggering and inspecting Airflow DAG runs and task instances, managing Airflow connections and variables, and creating queues plus enqueuing, dequeuing, and acknowledging Qakka messages.

Not supported:
- DAG authoring
- code deployment
- web UI
- pub-sub topics
- stream processing
- exactly-once delivery

## APIs

| API | Category | Endpoints | Description |
| --- | --- | --- | --- |
| Airflow API (Stable) | developer-tools | 89 | Trigger DAG runs, inspect task instances, and manage Airflow connections, variables, and datasets across an Apache Airflow deployment. |
| Qakka | developer-tools | 10 | Create and configure queues, send and receive messages, and acknowledge processed messages on a self-hosted Qakka deployment. |

## Which API to use

| Need | API | Why |
| --- | --- | --- |
| Schedule and monitor a multi-step data or ETL pipeline | airflow | Airflow orchestrates DAGs, tracks per-task state, and manages the connections and variables those pipelines depend on. |
| Hand off individual jobs between services with a lightweight queue | qakka | Qakka offers a small enqueue, dequeue, and acknowledge surface for at-least-once messaging without a full broker like Kafka. |

## Cross-API use cases

### Queue-backed pipeline with orchestrated workers

Use Qakka as the transport that carries jobs between services and Airflow to schedule the producers and consumers that drain those queues. An agent enqueues work items into Qakka, then triggers an Airflow DAG whose tasks pull and process the queued messages, giving a decoupled pipeline where Airflow owns scheduling and state while Qakka owns handoff.

Example prompt: POST job payloads to /queues/etl-jobs/messages on Qakka, then trigger the consumer DAG via POST /dags/etl_worker/dagRuns on Airflow and poll the DAG run for completion

### Health and state dashboard across orchestration and queueing

Build a single operations view that reports both pipeline health and messaging health for a self-hosted Apache stack. The agent aggregates Airflow DAG and task run state and checks Qakka reachability and queue presence, surfacing failures from either layer in one digest.

Example prompt: GET /dags then /dags/{dag_id}/dagRuns on Airflow to count failed runs, and GET /status plus /queues on Qakka to confirm queues exist, then post a combined health summary

## Why Jentic

- **Setup:** Wiring these Apache APIs by hand means pointing at each of your own deployments, picking Airflow's auth backend among basic, OpenID Connect, and Kerberos, handling Qakka's deployment-level protection, and mapping the run, task, metadata, and queue routes yourself. Through Jentic you install once, import Airflow and Qakka from the Jentic API Directory, store each credential once, and your agent calls them.
- **Permission scoping:** Both APIs put the target in the URL path, Airflow with /dags/{dag_id} and Qakka with /queues/{queueName}, so your own rules can pin the agent to a single DAG or a single queue. You also choose which operations each API exposes, so destructive ones like clearing task instances or deleting queues are available only if you add them.
- **Credential handling:** Each deployment credential, whether an Airflow basic or OIDC secret or a Qakka proxy token, is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'trigger an Airflow DAG' or 'send a message to a queue', and Jentic returns the matching Apache operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related vendors

- **Prefect** — Alternative workflow orchestration with a hosted control plane, an option to Airflow for scheduling pipelines.
- **Temporal** — Durable workflow execution for long-running stateful workflows, an alternative to both Airflow scheduling and Qakka handoff.
- **GitHub** — Hosts the DAG and worker source code and CI that feeds these deployments.

## FAQ

### Which Apache APIs are available through Jentic?

Two: the Apache Airflow stable REST API for workflow orchestration, and Qakka, the lightweight queue system from the Apache Usergrid project. Airflow covers DAGs, runs, task instances, connections, variables, datasets, and pools; Qakka covers queue lifecycle, message enqueue and dequeue, and acknowledgement.

### Do Airflow and Qakka share one set of credentials?

No. They are separate projects with independent auth. Airflow supports HTTP basic, Google OpenID Connect, or Kerberos depending on the deployment's configuration, while Qakka declares no security scheme and is protected by whatever network control or reverse proxy sits in front of it. Each is configured with its own credential.

### Are these Apache APIs hosted by Apache or self-hosted?

Self-hosted. Both Airflow and Qakka run on infrastructure you operate, so the base URL, host, and auth backend are set by your deployment rather than by a shared Apache endpoint. Through Jentic your agent operates your own running instances.

### When should an agent use Airflow versus Qakka?

Use Airflow to schedule and monitor multi-step pipelines where each task has state you want to track and recover. Use Qakka to move individual messages between services when a lightweight at-least-once queue is enough and a full broker would be excessive. They also work together, with Airflow scheduling workers that drain Qakka queues.

### Are these APIs free to use?

Both Airflow and Qakka are open source under the Apache 2.0 license, so the APIs themselves are free. The cost is the infrastructure that runs them, or a managed Airflow offering such as Astronomer or AWS MWAA if you choose one.

### Can I limit what my agent is allowed to do across these APIs?

Yes. Because you run Jentic One yourself, your own rules decide which operations and credentials the agent may use for each API. Both APIs put the target in the URL path, so a rule can pin the agent to a single DAG on Airflow or a single queue on Qakka, and you choose which operations are exposed so destructive ones like clearing task instances or deleting queues stay off unless you add them.