The official Schematic Java library.
Java version requirements:
Enabling datastream on a JVM older than 11 will throw a DataStreamException with a clear message at Schematic build time, rather than a cryptic UnsupportedClassVersionError at runtime.
Using Gradle in build.gradle:
Using Maven in pom.xml:
Issue an API key for the appropriate environment using the Schematic app.
Using this secret key, initialize a client in your application:
A number of these examples use keys to identify companies and users. Learn more about keys here.
Create or update users and companies using identify events.
This call is non-blocking and there is no response to check.
Track activity in your application using track events; these events can later be used to produce metrics for targeting.
This call is non-blocking and there is no response to check.
If you want to record large numbers of the same event at once, or perhaps measure usage in terms of a unit like tokens or memory, you can optionally specify a quantity for your event:
Although it is faster to create companies and users via identify events, if you need to handle a response, you can use the companies API to upsert companies. Because you use your own identifiers to identify companies, rather than a Schematic company ID, creating and updating companies are both done via the same upsert operation:
When checking a flag, you’ll provide keys for a company and/or keys for a user. You can also provide no keys at all, in which case you’ll get the default value for the flag.
Schematic can send webhooks to notify your application of events. To ensure the security of these webhooks, Schematic signs each request using HMAC-SHA256. The Java SDK provides utility functions to verify these signatures.
When your application receives a webhook request from Schematic, you should verify its signature to ensure it’s authentic:
If you need to verify a webhook signature outside of the context of a servlet request, you can use the verifySignature method:
There are a number of configuration options that can be specified using the builder when instantiating the Schematic client.
By default, the client will do some local caching for flag checks. If you would like to change this behavior, you can do so using initialization options to specify the cache providers:
You can also disable local caching entirely; bear in mind that, in this case, every flag check will result in a network request:
You may want to specify default flag values for your application, which will be used if there is a service interruption or if the client is running in offline mode:
In development or testing environments, you may want to avoid making network requests when checking flags or submitting events. You can run Schematic in offline mode:
When in offline mode:
This is especially useful for development, testing, or when running unit tests that shouldn’t depend on the Schematic API.
Offline mode works well with flag defaults:
Schematic API uses an Event Buffer to batch Identify and Track requests and avoid multiple API calls. You can set the event buffer flush period:
When the API returns a non-success status code (4xx or 5xx response), a subclass of SchematicException
will be thrown.
The SDK also supports error handling for first class exceptions with strongly typed body fields.
The SDK is instrumented with automatic retries with exponential backoff. A request will be retried as long as the request is deemed retriable and the number of retry attempts has not grown larger than the configured retry limit (default: 2).
A request is deemed retriable when any of the following HTTP status codes is returned:
DataStream enables local flag evaluation by maintaining a WebSocket connection to Schematic and caching flag rules, company, and user data locally. This reduces latency and network calls for flag checks.
DataStream supports Redis for caching, which is required for Replicator Mode. Pass a RedisCacheConfig and the SDK will create and manage the Redis connection internally:
Replicator mode is designed for environments where a separate process (the schematic-datastream-replicator) manages the WebSocket connection and populates a shared Redis cache. The SDK reads from that cache and evaluates flags locally without establishing its own WebSocket connection.
Replicator mode requires Redis as a shared cache so the SDK can read data written by the external replicator process. An in-memory cache will not work since the replicator and SDK run in separate processes.
Important: When using Replicator Mode, you should set the SDK’s cache TTL to match the replicator’s cache TTL. The replicator defaults to an unlimited cache TTL. If the SDK uses a shorter TTL (the default is 24 hours), locally updated cache entries (e.g. after track events) will be written back with the shorter TTL and eventually evicted from the shared Redis cache, even though the replicator originally set them with no expiration.
To match the replicator’s default unlimited TTL:
When running in Replicator Mode, the client will:
While we value open-source contributions to this SDK, this library is generated programmatically. Additions made directly to this library would have to be moved over to our generation code, otherwise they would be overwritten upon the next generated release. Feel free to open a PR as a proof of concept, but know that we will not be able to merge it as-is. We suggest opening an issue first to discuss with us!
On the other hand, contributions to the README are always very welcome!