How do their APIs compare?

This question spans two very different domains, so the "API comparison" is really about design philosophy and usage patterns rather than overlapping functionality.

dromara/sa-token — declarative, static-utility permission API

Sa-Token's API is built around static utility classes and annotations for auth/session/permission checks, designed to be usable from anywhere in code (not just web contexts):

• One-liners for common operations, e.g. kicking a session offline via StpUtil.kickout(10077), or checking permission with StpUtil.checkPermission("user") [README_en.md:L76-L100].
• Annotation-based declarative checks, e.g. @SaCheckPermission("user:add") on a method, which the framework intercepts via AOP [README_en.md:L88-L94].
• Router-style interception API — SaRouter.match("/user/**", r -> StpUtil.checkPermission("user")) lets you compose path-based auth rules imperatively [README_en.md:L98-L106].
• A context abstraction layer: SaRequest/SaResponse interfaces abstract away the underlying web container, with default methods like hasParam, getParamNotNull, isPath, isMethod providing convenience on top of the raw getters [sa-token-core/.../SaRequest.java:L72-L111, L152-L191]. There are also "Mock" implementations (SaRequestForMock, SaResponseForMock) for non-web contexts [sa-token-core/.../SaRequestForMock.java:L1-L30, SaResponseForMock.java:L1-L28], with a dedicated NotWebContextException when APIs requiring a web context are called outside one [sa-token-core/.../NotWebContextException.java:L1-L23].
• Configuration objects like SaCookieConfig/SaCookie use a fluent builder style (addExtraAttr, removeExtraAttr, chained .builder()) [sa-token-core/.../SaCookieConfig.java:L187-L218, SaCookie.java:L275-L314].

Overall, sa-token's API surface is oriented toward server-side, synchronous, imperative security checks integrated deeply into request-handling pipelines (Spring MVC, WebFlux, gRPC, etc., per its module list), with heavy use of default interface methods for ergonomics.

karumi/dexter — callback/listener-based permission-request API

Dexter's API is a fluent builder + listener callback pattern specifically for Android runtime permissions:

• Entry point is a fluent chain: Dexter.withContext(this).withPermissions(...).withListener(...).check() [README.md:L102-L114].
• Single permission requests use a PermissionListener; multiple permission requests use a MultiplePermissionsListener with a MultiplePermissionsReport result object exposing areAllPermissionsGranted() / isAnyPermissionPermanentlyDenied() [README.md:L102-L117].
• Composability via helper listener implementations: DialogOnAnyDeniedMultiplePermissionsListener, SnackbarOnAnyDeniedMultiplePermissionsListener, and CompositeMultiplePermissionsListener to combine several listeners [README.md:L120-L162].
• Token-based flow control: when a rationale must be shown, Dexter calls onPermissionRationaleShouldBeShown(PermissionRequest, PermissionToken) and pauses until you call token.continuePermissionRequest() — the request just won't proceed (or won't show the OS dialog again) until you explicitly resume it [README.md:L174-L186, L205-L232].
• Core types are simple wrappers, e.g. PermissionRequest [dexter/src/main/java/com/karumi/dexter/listener/PermissionRequest.java:L1-L23].

Dexter's API is inherently asynchronous/event-driven since Android permission prompts are non-blocking UI dialogs — the caller registers callbacks rather than getting an immediate boolean back.

Key contrasts

Aspect	sa-token	dexter
Style	Static utility calls + annotations	Fluent builder + callback listeners
Execution model	Synchronous (checks throw/return immediately)	Asynchronous (results delivered via listener callbacks)