How do their APIs compare?

Kestra and android-spinkit are fundamentally different kinds of projects, so their "APIs" aren't really comparable in a like-for-like way — but I can describe what each exposes based on what's in the retrieved data.

kestra-io/kestra Kestra is a server-side orchestration platform, so its primary "API" surface is:

• CLI commands — Java classes like PluginSearchCommand that expose subcommands for interacting with the platform, e.g. searching installed plugins by name/title/group and printing formatted results [cli/src/main/java/io/kestra/cli/commands/plugins/PluginSearchCommand.java:L62-L96]. Another example is LocalCommand, which configures a standalone server (H2 repository, H2 queue, local storage) via property overrides rather than exposing a callable API directly [cli/src/main/java/io/kestra/cli/commands/servers/LocalCommand.java:L19-L46].
• Micronaut-based service bootstrapping — Kestra.java filters which beans get context-scoped based on @Requires stereotypes, which is part of how the application wires up its runtime "API" of services rather than a public HTTP contract [cli/src/main/java/io/kestra/cli/Kestra.java:L293-L303].
• Kestra's actual developer-facing interface (per the README) is largely declarative YAML for defining workflows, plus a REST API and UI — not shown in the retrieved chunks, but the README emphasizes "Declarative YAML Interface" and API-driven UI sync [README.md:L61-L64, L67].
• The Helm chart templates (ingress.yaml, extra-manifests.yaml) show how the platform's HTTP API is exposed at the infrastructure level via Kubernetes Ingress rather than defining the API contract itself [charts/kestra/templates/ingress.yaml:L1-L40].

ybq/android-spinkit This is a UI animation library, not a service — its "API" is a set of Java classes meant to be used programmatically inside an Android app:

• SpinKitView, SpriteFactory, and Style form the primary public API surface for consumers, as seen used in the sample app [sample/src/main/java/com/github/ybq/android/loading/DetailActivity.java:L11-L14].
• Supporting internal APIs include animation utility classes like FloatProperty and IntProperty, which extend Android's Property type to avoid autoboxing overhead for animating float/int fields [library/src/main/java/com/github/ybq/android/spinkit/animation/FloatProperty.java:L1-L28, library/src/main/java/com/github/ybq/android/spinkit/animation/IntProperty.java:L1-L28].
• Interpolators (PathInterpolatorCompat, PathInterpolatorCompatApi21, PathInterpolatorCompatBase, PathInterpolatorDonut) form a compatibility API that picks platform-native or custom fallback implementations depending on API level, giving callers a single stable interface (PathInterpolatorCompat) regardless of Android version [library/src/main/java/com/github/ybq/android/spinkit/animation/interpolator/PathInterpolatorCompat.java:L1-L27, library/src/main/java/com/github/ybq/android/spinkit/animation/interpolator/PathInterpolatorCompatApi21.java:L1-L27, library/src/main/java/com/github/ybq/android/spinkit/animation/interpolator/PathInterpolatorCompatBase.java:L1-L24, library/src/main/java/com/github/ybq/android/spinkit/animation/interpolator/PathInterpolatorDonut.java:L1-L24].

Key contrast

• Kestra's API is oriented around orchestration control (CLI commands, server configuration, REST/UI, plugin ecosystem) — it's a networked, multi-process system.
• android-spinkit's API is a local, in-process UI library — classes instantiated and composed directly inside an Android Activity, with no network or CLI surface at all.

I don't have enough retrieved data here to characterize Kestra's REST/gRPC/webserver API contracts in detail (e.g., specific endpoint definitions), and the android-spinkit data doesn't include its full public SpinKitView/Style class definitions — only usage and supporting internals. I can search further if you