What is the best approach for dynamic style that is coming from API?

[semet]

Dear Tailwind friends.
I am currently working on a project using tailwind v3 where the style is pre defined in the backend. The backend will return the style in the following formats:

{
"mobile_v2_header_transaction_deposit": {
      "background_color": "rgba(19, 219, 219, 1)",
      "background_image": "https://domain.com/someimage.png",
      "border_color": "rgba(246, 244, 251, 1)",
      "button_color": "rgba(15, 168, 168, 1)",
      "icon_color": "rgba(163, 11, 105, 1)",
      "style_type": "color",
      "text_color": "rgba(163, 11, 105, 1)"
    },
    "mobile_v2_header_transaction_recall": {
      "background_color": "rgba(14, 163, 11, 1)",
       "background_image": "https://domain.com/someimage.png",
      "border_color": "rgba(229, 228, 237, 1)",
      "button_color": "rgba(20, 248, 16, 1)",
      "icon_color": "rgba(237, 235, 248, 1)",
      "style_type": "color",
      "text_color": "rgba(200, 198, 209, 1)"
    }
}

the style_type is set based on user preference, it is either color or image. When the value is color, the background_color will take place, and if the value is image, the background_color will take place..

My current solution is to generate bunch of css variables for these pre-defined styles using a utility functions that generate something like:

--mobile-bg-color: rgba(19, 219, 219, 1)
--mobile-bg-image: url(https://domain.com/someimage.png)
and so on

and then create a custom class like:

.header-transaction-deposit {
     background-color: var(--mobile-bg-color)
     background-image: var(--mobile-bg-image)
}

as you can see, this works fine. But the down side is, there is over 200+ predefined styles that i have to turn into css variables.
I need a more tailwind way where i can consume the predefined style directly into tailwind utility class...

is this possible in tailwind v3? or is there any plugins that can help me out with this?

[benitoalba]

Hi! You can reuse the same six CSS variable names on each header, so the 200+ themes don't each need their own variables or custom class.

Keep the Tailwind classes fixed:

<header class="border bg-[color:var(--header-bg)] bg-[image:var(--header-image)] border-[color:var(--header-border)] text-[color:var(--header-text)]">
  <button class="bg-[color:var(--button-bg)]">Deposit</button>
  <span class="text-[color:var(--icon-color)]">Icon</span>
</header>

Then assign the API values to that header element:

function applyHeaderTheme(element, theme) {
  const variables = {
    '--header-bg': theme.background_color,
    '--header-image': theme.style_type === 'image'
      ? `url("${theme.background_image}")`
      : 'none',
    '--header-border': theme.border_color,
    '--header-text': theme.text_color,
    '--button-bg': theme.button_color,
    '--icon-color': theme.icon_color,
  };

  for (const [name, value] of Object.entries(variables)) {
    element.style.setProperty(name, value);
  }
}

Pass the header element and its theme object, such as mobile_v2_header_transaction_deposit, to applyHeaderTheme(). The button and icon inherit the variables from that header. Another header can use the same names with different values.

This works in Tailwind v3 without a plugin. Tailwind generates the utilities once, the API values can change at runtime. Keep these complete class strings in a file covered by your content configuration. Building class names from API values won't generate the corresponding CSS, as the content configuration guide explains. The color: and image: hints distinguish the background utilities, following the custom styles guide.

[mujtbabbas]

The key constraint: Tailwind generates utilities by scanning your source for complete class names, so it can never invent classes for values that only exist at runtime. For API-driven styles you have three solid options, roughly in order of fit:

1. CSS variables as the bridge (best fit for 200+ objects).
You don't hand-write 200 variables — you generate them from the payload. Take each style object from the API, convert its keys to custom properties on the element (or emit one generated <style> block), and reference them with arbitrary values:

<div style="--s-bg:#0f766e; --s-bg-img:url(...); --s-radius:12px"
     class="bg-[var(--s-bg)] bg-[image:var(--s-bg-img)] rounded-[var(--s-radius)]">

Or register them once in your theme (colors: { apiBg: 'var(--s-bg)' }) so you can write bg-apiBg. The class strings stay static, only the variable values change at runtime — and variants still work (hover:bg-[var(--s-bg-hover)]).

2. Inline styles for truly dynamic one-off values.
Not a failure of approach — a React style prop exists exactly for values only known at runtime (an API-provided backgroundImage is the classic case). Use it where no variant/responsive behaviour is needed.

3. Complete-class lookup for fixed sets.
If the API values come from a known set, keep a map of complete class names and index into it:

const presets = { primary: 'bg-blue-600 text-white', danger: 'bg-red-600 text-white' }

Tailwind sees the full strings in your source and generates them all. Just never interpolate fragments like `bg-${color}-600` — that string never appears in your source, so the class won't exist.

For server-defined presets at your scale I'd go with option 1: one small component that takes the API style object, turns it into CSS variables, and renders children with a fixed set of arbitrary-value utilities. The payload stays data, not code.