How do their APIs compare?

These two projects don't really have comparable "APIs" in the same sense — one is a distributed orchestration platform with a network-facing API and CLI, the other is a single UI widget library with a Java class/XML API. Let me lay out what's actually visible in the retrieved data for each.

kestra-io/kestra

Kestra exposes a REST-style HTTP API that's consumed both externally and internally (e.g., by its own CLI). A clear example: PluginSearchCommand calls Kestra's own backend over HTTP via a Micronaut HttpClient, hitting GET /v1/plugins and parsing the JSON response into PluginInfo records, then filtering by name/title/group [cli/src/main/java/io/kestra/cli/commands/plugins/PluginSearchCommand.java:L22-L61][cli/src/main/java/io/kestra/cli/commands/plugins/PluginSearchCommand.java:L62-L101]. This shows the shape of Kestra's API surface: versioned (/v1/...), JSON-based, consumed with a typed HTTP client.

Beyond the HTTP API, Kestra also has a CLI-as-API surface — commands like migrate plan are explicitly designed as a "read-only counterpart" to migrate run, letting users inspect pending DB migrations without applying them [cli/src/main/java/io/kestra/cli/commands/migrations/PlanMigrationCommand.java:L1-L29]. These migration commands run against a deliberately minimal ApplicationContext — no repositories, server services, or migration startup trigger beans are registered — so the CLI command programmatically resolves and invokes MigrationRunner/MigrationLock directly rather than relying on the full app context [cli/src/main/java/io/kestra/cli/commands/migrations/AbstractMigrationCommand.java:L1-L21].

There's also a schema-generation API internally: ConfigurationSchemaGenerator reflects over annotations (@NotNull, @Nullable, etc.) and Java types to build JSON Schema nodes, including handling of collections/generics via ParameterizedType [cli/src/main/java/io/kestra/cli/schema/ConfigurationSchemaGenerator.java:L481-L520][cli/src/main/java/io/kestra/cli/schema/ConfigurationSchemaGenerator.java:L521-L560]. This isn't a public HTTP API, but it's part of how Kestra exposes structured configuration metadata programmatically.

umano/androidslidinguppanel

This library's "API" is a custom Android View subclass, SlidingUpPanelLayout, configured through XML attributes (sothree:umanoPanelHeight, sothree:umanoShadowHeight, sothree:umanoDragView, etc.) and Java methods like setDragView, setFadeOnClickListener, setPanelState, and addPanelSlideListener [README.md:L36-L80][demo/src/main/java/com/sothree/slidinguppanel/demo/DemoActivity.java:L29-L68]. Its API contract is a callback/listener interface: PanelSlideListener exposes onPanelSlide(View, float) and onPanelStateChanged(View, PanelState, PanelState) [demo/src/main/java/com/sothree/slidinguppanel/demo/DemoActivity.java:L69-L108]. There's no network layer, no versioning scheme, no schema generation — it's a static, compile-time Java/XML API distributed as a Maven artifact (com.sothree.slidinguppanel:library:3.4.0) [README.md:L23-L35].

Comparison

• Nature: Kestra's API is a live, versioned HTTP service plus a CLI that talks to it or to internal runners directly; androidslidinguppanel's "API" is purely a compile-time Java class/attribute surface with no runtime service boundary.
• Consumers: Kestra's API is consumed by external clients and its own tooling (the CLI is literally an HTTP client against itself) [cli/src/main/java/io/kestra/cli/commands/plugins/PluginSearchCommand.java:L22-L61]; the sliding panel's API is consumed directly by app code embedding the view.
• Evolution/safety: Kestra shows deliberate API-safety patterns — read-only