Issue an API key for the appropriate environment using the Schematic app. Be sure to capture the secret key when you issue the API key; you’ll only see this key once, and this is what you’ll use with the Schematic Go library.
Using this secret key, initialize a client in your Go application:
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 an initialization option to specify the max size of the cache (in terms of number of records) and the max age of the cache (as a time.Duration):
You can also disable local caching entirely with an initialization option; 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 (see below). You can do this using an initialization option:
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:
You can define any number of company keys; these are used to address the company in the future, for example by updating the company’s traits or checking a flag for the company. You can also define any number of company traits; these can then be used as targeting parameters.
Similarly, you can upsert users using the Schematic API, as an alternative to using identify events. Because you use your own identifiers to identify users, rather than a Schematic user ID, creating and updating users are both done via the same upsert operation:
You can define any number of user keys; these are used to address the user in the future, for example by updating the user’s traits or checking a flag for the user. You can also define any number of user traits; these can then be used as targeting parameters.
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.
If you need more detail about how a flag check was resolved, including any entitlement associated with the check, use CheckFlagWithEntitlement. This returns a response object with the flag value, the reason for the evaluation result, and entitlement details such as usage, allocation, and credit balances when applicable.
When you need to evaluate several flags for the same company/user context, CheckFlags returns the full result for each requested flag in a single call. Pass nil or an empty slice for keys to retrieve every flag defined for the context.
Results are returned in the same order as the requested keys. When any requested key is a cache miss, CheckFlags refreshes the full set from the API so every returned value comes from a consistent evaluation. If DataStream is enabled and connected, keys are evaluated locally — any failure causes a transparent fallback to the API. In offline mode, each key resolves to its configured default.
The Schematic API supports many operations beyond these, accessible via client.API(). See the API submodule readme for a full list and documentation of supported operations.
In development or testing environments, you may want to avoid making network requests to the Schematic API. You can run Schematic in offline mode by not providing an API key to the client:
You can also enable offline mode by providing an empty API key:
Or, by using the offline mode option:
Offline mode works well with flag defaults:
In an automated testing context, you may also want to use offline mode and specify single flag responses for test cases:
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 Go 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. The SDK provides a simple function to verify webhook signatures:
If you want to verify a webhook signature outside of the context of a web request, you can also do that using the webhooks.VerifySignature function.
The DataStream functionality in Schematic provides real-time updates for flags, companies, and users. It uses WebSocket connections to receive updates from the Schematic backend and caches the data locally or in Redis for efficient access.
To enable the DataStream functionality, you need to pass the WithDatastream option when creating a new SchematicClient.
The DataStream functionality supports Redis for caching company and user data. You can configure it to use either a single Redis instance or a Redis cluster.
To use a single Redis instance, create a RedisCacheConfig and pass it to the DatastreamOptions.
To use a Redis cluster, create a RedisCacheClusterConfig and pass it to the DatastreamOptions.
When running the schematic-datastream-replicator service, you should configure the Schematic client to operate in Replicator Mode. In this mode, the client connects to the external replicator service instead of establishing its own WebSocket connections, and the replicator handles all data streaming and caching automatically.
To enable Replicator Mode, simply use the WithReplicatorMode() option within WithDatastream():
Important: When using Replicator Mode, you must set the SDK’s cache TTL to match the replicator’s cache TTL. The replicator defaults to an unlimited cache TTL (0). 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:
If you have configured a custom cache TTL on the replicator, use the same value here.
The client automatically configures sensible defaults for replicator mode, but you can customize the configuration if needed:
http://localhost:8090/readyWhen running in Replicator Mode, the client will:
Structured error types are returned from API calls that return non-success status codes. For example, you can check if the error was due to an unauthorized request (i.e. status code 401) with the following:
These errors are also compatible with the errors.Is and errors.As APIs, so you can access the error
like so: