Skip to main content
A Remote Configuration is a named payload that the Qonversion SDK fetches at runtime. Use it to feature-flag experiments, change onboarding copy, tune paywall defaults, or deliver any server-controlled JSON to your app without a new release. Configurations can be narrowed with targeting rules, attached to experiment groups, or pinned to specific users.

​
Key concepts

  • Config ID — Stable identifier (UUID) for the configuration, used in the API path.
  • Context key — Optional key the SDK uses to look up this configuration.
  • Status — draft, active, or archived. Only active configurations are served to the SDK. Archiving is terminal; an archived configuration can only be deleted. Change it via PATCH /remote-configurations/{config_id}/status.
  • Payload values — The actual JSON object delivered to the SDK, e.g. {"button_color": "#FF0000"}. Read and replaced through the dedicated payload endpoint, and also returned read-only inline on a single-configuration GET.
  • Payload mapping — The key → type schema that tells the SDK how to interpret each payload key, e.g. {"button_color": "Color"}. Types are String, Number, Bool, Json, Color, Products, Screens. Managed through the payload-mapping endpoint. The mapping describes the shape of the payload; it is not the values themselves.
  • Targeting — segmentation_conditions narrows the configuration with attribute rules; it is set on create/update and returned on read. A user who already received the configuration keeps it after later targeting edits — the current rules apply to users without an assignment for its context key. See How targeting and assignment works.
  • User attachment — POST /remote-configurations/{config_id}/users/{user_id} pins a specific user to this configuration, overriding targeting rules; the pin is never re-evaluated and survives config edits until DELETE, archive, or delete. Both attach and detach invalidate the SDK’s in-memory config cache.
  • Priority — Read-only resolution order within a context key, null until the configuration is first activated. When a user matches several configurations, the configuration with the lowest priority number (1 = first) wins; reorder it in the dashboard, not through the API.
  • Experiments — Remote configurations can be delivered as an experiment group payload.
Payload values vs. payload mapping are two sibling concepts. The values (payload) are the JSON delivered to the SDK; the mapping (payload-mapping) is the key → type schema describing how to read that JSON. They are edited through separate endpoints.

​
Available endpoints

POST and PUT on a configuration accept the optional targeting field segmentation_conditions, which is returned on read. Only a single-configuration GET returns the read-only inline payload values ({} when unset) — list items and the create, update, and status responses omit them.
Both payload endpoints (payload and payload-mapping) are full replace: the object you send becomes the complete stored value. To change one key, read the current object, modify it, and send the whole object back. An empty object {} clears it. Payload value requests are limited to 64 KiB.

​
Authentication

All v4 endpoints require a Secret Key. See Authentication.