Are Zendesk booleans case sensitive? It depends where the boolean lives.

Here is a question that sounds trivial until it bites you. When you write a value into Zendesk config that is meant to be true or false, does the case matter? Is it true, True, or TRUE? It depends entirely on where the boolean sits, and the different places behave in opposite ways. In some routes, Zendesk is completely forgiving. Others reject a capital letter outright.

We did not want to guess, so I wrote a script to test every variation against a live sandbox and read back what Zendesk actually stored.

Object flags: forgiving

The first kind of boolean is an object’s own on/off flag: a trigger’s active, an automation’s active, a ticket field’s required, a group’s is_public, a brand’s active, and so on. These flags are all over the config.

For these, Zendesk simply does not care. Every one of the following stored as false:

false      (a real boolean)
"false"    (a string)
"False"
"FALSE"
0
"0"

And the corresponding true forms all stored as true. It even coerces the string "false" to the boolean false rather than treating a non-empty string as truthy, which is the failure you might expect and the one that would quietly leave something switched on. The only forms it turns away are "yes" and "no", which return a 400.

So for an object’s own flag, case is irrelevant. Write it however you like.

Checkbox field values in rules: fussy

The second kind is different, and this is where the capital letter bites. It is the value of a checkbox custom field when you reference it inside a trigger or automation, either as a condition (“is complaint is checked”) or as an action (“set is complaint to checked”).

Here Zendesk accepts only two things: a real boolean, or the lowercase strings "true" and "false". Everything else is refused with an HTTP 422:

true / false      accepted
"true" / "false"  accepted
"True" / "False"  rejected (422)
"TRUE" / "FALSE"  rejected (422)
1 / 0 / "1" / "0" rejected (422)
"yes" / "no"      rejected (422)

The same value that a trigger’s active flag would happily swallow is rejected outright when it is a checkbox field’s value in a condition. Title case is the specific trap, because True is exactly what you would type if you were being tidy.

There is one more oddity worth knowing. If you set a checkbox action’s value to the boolean false, Zendesk stores it as an empty string rather than as false. So the “off” case does not even round-trip to the same value you sent.

Why this matters

Most of the time you set these values through the admin UI, which hands you the right form and hides the problem. It surfaces when you are working with the config programmatically: an API integration, a bulk edit, a spreadsheet round-trip, or anything that reconstructs a rule from stored values. Send "True" for a checkbox condition and the write fails; send it for a trigger’s active flag and it is fine. Same word, opposite outcome, and no obvious reason from the outside why one works and the other does not.

The rule of thumb: for an object’s own flag, case does not matter. For a checkbox field’s value inside a rule, use a real boolean or lowercase "true" / "false", and never title case.

How we know

We did not read this off a help article, because there isn’t one that says it. We created the objects on a live Zendesk sandbox, wrote each variation through the API, and read back exactly what was stored. That is the only way to be sure with behaviour like this, where the documentation is silent and the two cases genuinely diverge.

It is the same reason we went and tested whether HTML in dynamic content really does fail to render in email. The Zendesk article says it doesn’t. It does, and the actual culprit turned out to be a line break inside a tag. Where the docs are old or silent, the instance is the only thing worth asking.

So what?

If you just read this and you’re already a Deltastring user, I’m sorry but I have to admit at this point that I have wasted your time.

When Deltastring users are making a change in Zendesk that swaps a true/false value (maybe you’re deactivating an object, maybe you have a new workflow that flips a boolean ticket field value) then our system ensures we send the right format to Zendesk and then checks the change held. That read-back is the point: a write that doesn’t error is not the same as a change that took, which is exactly why we put the MCP in front of Zendesk rather than pointing your AI straight at it.

If you’re not a Deltastring user, you’ve got to remember this and a couple of hundred other daft quirks when you build or rework a Zendesk. If you’re using Deltastring then we do that for you.