Jetstack exposes a versioned REST API for authentication, collection access, command execution, filtering, ordering, paging, field selection, and file-aware operations.
The REST API is the main external integration surface for many conventional system-to-system scenarios.
The API supports:
This makes API access an explicitly permissioned tenant capability rather than an always-on anonymous interface.
The API can:
The API also supports command-style paths, which means the surface is not limited to static collection retrieval.
The runtime accounts for file uploads and file-oriented field handling where needed.
GET and SEARCH requests against the generic collection API are served from a transparent server-side cache. The cache stores fully-projected JSON payloads — the same bytes the API would otherwise produce — and is consulted before any database work happens.
Three request shapes are cached:
The cache is per user: every entry's lookup key includes the authenticated user's identity and effective permission scope, so two users never see each other's filtered view.
Two invalidation strategies cooperate:
Every cached response also carries an ETag. Clients that send If-None-Match on a subsequent request receive 304 Not Modified and an empty body, saving bandwidth. Setting an ETag does not require the client to support conditional requests — it is opportunistic.
Caching is bypassed for:
Cache-Control: no-cache or ?_noCache=1Operators can monitor and purge the cache from the Application Management screen.
REST access depends on system permissions such as:
useApiThis means the REST API must be part of the tenant's security design, not treated as a side channel.
Use REST API Reference when you need concrete routes, request parameters, response shapes, and module-specific endpoint details.
REST API access is user-bound. An API key authenticates as the User that owns the key, and the platform then evaluates permissions through that user identity.
This has several important consequences:
Because of that, the recommended pattern is to create a dedicated application user for each important integration.
Application CRM Connector.Application access.In the normal administrative API-key flow, the key primarily inherits the owning user’s identity and permissions. In other words, the usual security boundary is the user account and its roles, not a large independent per-key permission model.
API consumers need to understand:
Some of that behavior is further influenced by application settings.
Application accessIf-None-Match in clients that handle a lot of polling traffic; conditional 304 responses reduce bandwidth without changing the caching guarantees