How do their APIs compare?

These two projects aren't really comparable at the "API" level in the same sense — they serve completely different purposes and audiences.

binarywang/wxjava is a backend Java SDK exposing a large set of remote-service-oriented APIs that wrap WeChat's HTTP interfaces. Based on what's retrievable here:

• Its APIs are organized by WeChat product module (公众号/official accounts, 小程序/mini-programs, 企业微信/WeCom, 支付/Pay, 开放平台/open platform, 视频号/channels), each with its own Service interfaces and property/config classes. For example, WxMaMessageHandler implementations show the mini-program messaging API surface — handlers receive (wxMessage, context, service, sessionManager) and call into services like service.getMsgService().sendKefuMsg(...), service.getMediaService().uploadMedia(...), and service.getQrcodeService().createQrcode(...) [others/weixin-java-config/README.md:L207-L263].
• Configuration is done via Spring-style @ConfigurationProperties classes, e.g. WxCpProperties with a wechat.cp prefix for WeCom [others/weixin-java-config/README.md:L268-L280].
• The project's own contributor guidance stresses that API contracts must mirror WeChat's official interface definitions exactly — matching path, method, field names, required params, and response structure — and reusing existing HTTP executors, exceptions, and Gson/Jackson/XStream mappings rather than inventing new patterns [skills/wxjava-api-contributor/references/contribution.md:L1-L6]. Review guidance likewise emphasizes WeChat interface contracts, Java 8 compatibility, public API compatibility, and serialization fields as top concerns [AGENTS.md:L118-L119].
• This makes the wxjava "API" surface essentially a large, faithful mapping of WeChat's REST/callback contracts into Java service interfaces, with config-driven multi-account support and starter-based initialization (with a documented pitfall: mixing Starter auto-configuration and manual Demo-style initialization causes null-key/injection errors, referenced via issue #2177) [skills/wxjava-integration-guide/references/integration.md:L12].

naman14/timber is a local Android music player app, not an SDK — so it doesn't expose a public "API" for consumers in the same way. Instead it has internal data-access and service classes:

• SongLoader, AlbumLoader, FolderLoader provide static query methods over Android's MediaStore content provider, e.g. AlbumLoader.getAllAlbums(Context), getAlbum(Context, long id), getAlbums(Context, String, int limit) [app/src/main/java/com/naman14/timber/dataloaders/AlbumLoader.java:L53-L67], and analogous SongLoader.getAllSongs, getSongForID, searchSongs methods [app/src/main/java/com/naman14/timber/dataloaders/SongLoader.java:L117-L130].
• MusicService (an Android Service) exposes internal notification/broadcast behavior like notifyChange(String what), which builds an Intent with playback metadata and sends sticky broadcasts for other components/apps to observe [app/src/main/java/com/naman14/timber/MusicService.java:L1105-L1129].
• There's also a small external-facing REST client, LastFmRestService, using Retrofit annotations (@GET, @Headers, @Query) to call the Last.fm API for artist/album metadata [app/src/main/java/com/naman14/timber/lastfmapi/LastFmRestService.java:L14-L24], with query/response models like ArtistQuery and AlbumQuery [app/src/main/java/com/naman14/timber/lastfmapi/models/ArtistQuery.java:L1-L18], [app/src/main/java/com/naman14/timber/lastfmapi/models/AlbumQuery.java:L1-L18].

Summary of the contrast:

• wxjava's "API" is a broad, config-driven, multi-module server-side SDK wrapping a third-party (WeChat) HTTP API surface for other developers to integrate against.
• timber's internal "API" is a set of Android-local data loaders and a background service for in-app music playback, plus one small