Skip to main content
Question

Storage accepts objects but stores "[object Object]": the strings-only limitation from 2020 is still undocumented

  • September 18, 2026
  • 0 replies
  • 6 views

Looks like this is a known limitation, but the docs and types still say otherwise

A monday team member confirmed in 2020 that storage supports only strings and numbers, and that objects need to be serialized first [Save objects using storage API]. That thread was about the client-side `monday.storage`. The backend `Storage` class from `@mondaycom/apps-sdk` behaves the same way.

Six years later, the backend docs and types still suggest non-string values work:

- The [Storage reference] lists `value` as "Any serializable object".
- The SDK types `set` as `set<T extends JsonValue>(key, value, options)`, so TypeScript accepts an object without complaint.
- The [apps-sdk README] says the value "can be any type (object, number, string, etc.)".

Numbers don't keep their type either. `42` comes back as `"42"`, so in practice only strings round-trip.

The success response makes this easy to miss. Nothing signals that the data was lost until the key is read back, and by then the original value is gone.

## Suggested fixes

1. Document the limitation. The Storage reference should say values are stored as strings, and the `set` type should accept `string` instead of `JsonValue`. This matches what team said in 2020 and costs the least.
2. Reject non-string values with a 4xx instead of returning 200, so the data loss can't happen silently.
3. Nice to have: store JSON values natively, as the current docs describe.