New to SuperDocs: Stickers in Comments

[Ruggy-Joesten]

Hey everyone!

We know there are a lot of feature requests y’all have been patiently waiting on. Some will be game changers for workflowmaxxing, but very few of them will be this fun. Because what we’re launching today isn’t just useful. It’s delightful. It’s ANIMATED STICKERS!

We know you are very, very good at doing the work. But now, you can do said work with flair, pizazz, and maybe even a sprinkle of je ne sais quoi. For the first time ever, you can add animated stickers to comments, not just emoji and text.

Here’s how to use them

Open the sticker picker right from the comment toolbar (just like the emoji picker you already use), browse three curated Sticker packs from real artists, and drop a sticker straight into your comment, mixed with text however you like.

When can I start using these?!

The first release features 29 stickers across three artist-curated Sticker packs and goes live today. Huge thanks to the artists who made these:

• Jay Daniel Wright
• Henri Campea
• Aran Quinn

Step by step

• Click the new sticker icon between emoji and attachment in the comment toolbar.
• Browse by Sticker pack, or jump straight to your Frequently Used stickers.
• Stickers animate wherever you read them in the app. On surfaces that can’t run animation (print, exports), they still show as an image so they don’t get lost.

Go find your new favorite sticker, and let us know what you think. If there’s a Sticker pack or artist you’d love to see next, drop it in the comments below.

[Samuel_Langford]

This is cute! I love whimsy. Is there a way to take these comments and put them into a row’s column?

[Todd_Girgus]

This is what you are excited to announce, STICKERS? When do we get conditional logic on forms. Infinitely more important to businesses than stickers. Can somebody please address if conditional logic is actually on the roadmap and when we should anticipate it rather than just telling me, “I will pass the request on to the developers”? All of your competition has this basic feature.

[Pashmina_De_Shon]

Stickers in comments is a weird feature to work on and a waste of development time. Do you think we’re in third grade?

Why aren’t you fixing critical issues like API timeouts?

Coda’s API is incredibly frustrating and limiting: basic reads and writes frequently time out, mutations are asynchronous and inconsistently reported, and we have to build layers of polling, retries, and verification just to make routine operations reliable. I genuinely don’t understand why such fundamental reliability issues still haven’t been fixed, especially when customers are using Coda for real operational systems, not just lightweight documents!

A ton of tokens and time spent just to work around your API issues, hoping that you’re going to fix them, because WHY WOULDN’T YOU?? But no, instead I get this feature launch of stickers. Wow, that’s so useful. WTAF!!

[Ruggy-Joesten]

@Pashmina_De_Shon @Todd_Girgus I hear where you’re coming from, and I understand that this update may not be the feature that resonates.

Of course, there are bigger things the team is working on, including work that addresses a lot of the feature requests and product needs members of this community have raised. Those things are not being ignored, and launching something fun does not mean the team has stopped investing in the core workflows people depend on.

At the same time, not every improvement has to serve the exact same purpose. Some work is focused on power, reliability, and scale. Some work is focused on collaboration, expression, and making the product feel a little more enjoyable to use. There’s room for both.

On conditional logic for forms: yes, improvements there are on the roadmap, though I don’t have a date to share yet. I don’t want to give you a generic “we’ll pass this to the developers” answer, because that’s not really how this community works. The team is here, reading and listening, and we do our best to share updates when there’s something concrete we can say publicly.

Related to that, I’m also actively working on a thread that provides more visibility into feature requests that have come directly from this community, including roadmap updates, what has shipped, and what we’re still tracking. I know that kind of transparency matters, especially when people are trying to understand whether their feedback is actually shaping the product.

On API timeouts and reliability, I also hear you. That’s very different feedback from “I don’t like stickers,” and I understand why it matters so much if you’re using SuperDocs for operational systems. I’ll make sure that specific context is visible to the right folks internally.

So yes, I get why a playful launch might not be what everyone was looking for. But I don’t think it’s an either/or. We can keep investing in the bigger workflow and reliability improvements people have been asking for while also making space for smaller, lighter touches that make collaboration a little more fun.

[Ruggy-Joesten]

Do you have a specific instance you can share? Any screen shots? Want to be able to narrow this down as I share with the team. Docs API? MCP? Docs AI? Coda API?

[Pashmina_De_Shon]

I will vehemently disagree with you that “there’s room for both.” That framing ignores opportunity cost. Product, engineering, design, QA, release, and communications capacity are finite. Every feature reflects a decision about what deserves attention now. Stickers deserves ZERO attention.

The issue isn’t that a product may never include anything playful. It’s sequencing. Foundational capabilities like API reliability have remained severely inadequate for years. Basic reads and writes timing out is mission-critical product debt.

If those problems were being fixed at a consistent cadence, then yes, there would be room for both. But “the team is working on bigger things” is not evidence of that. We need concrete progress and there has been none.

Even if different teams worked on these features, staffing and roadmap allocation are still company decisions. And if stickers required very little effort, presenting them as a major launch while longstanding operational problems remain unresolved is still profoundly tone-deaf.

The first-principles priority should be: make the product dependable for the serious business systems customers have built on it, then spend discretionary capacity on novelty. Until that foundation is reliable, NO there isn’t room to prioritize and celebrate stickers as though the critical backlog does not exist.

[Pashmina_De_Shon]

Coda API specifically, not MCP or Docs AI.

Here are concrete problems we have encountered in production:

1. A row update was accepted and returned a request ID, but polling GET /mutationStatus/{requestId} subsequently returned: “No request was found with the given id, or it has expired.” The write may already have succeeded, leaving the caller unable to distinguish success from failure.

2. In another case, Coda did not confirm an accepted row update within 120 seconds. Again, the client could not safely determine whether the update failed, remained queued, or had already been applied.

3. We have received HTTP 504 responses from asynchronous writes. Because a timed-out write may later be applied, retrying it can produce duplicate or unintended changes.

4. Filtered row searches have returned zero results for records that demonstrably existed in the table. In one case, the record was still missing from filtered API results more than two minutes after creation. We had to perform a complete paginated scan to locate it.

5. Broad filtered reads of a table containing approximately 2,900 rows have taken more than two minutes.

6. In another real workflow, retrieving and assembling Coda data for only 13 records took approximately 42 seconds. The non-Coda processing took less than a tenth of a second.

7. We have had small-table reads stall production requests for several minutes. Changing the method used to retrieve the same data reduced individual reads to approximately 0.5–1.6 seconds, showing that the business logic was not the bottleneck.

8. Rich-value reads have timed out where simple-value reads of the same underlying data succeeded. Consumers should not have to sacrifice the richer response format merely to complete a routine read reliably.

9. Routine reconciliation and status-reporting writes have received HTTP 429 responses, forcing us to distinguish whether the underlying operation failed or merely its final status update failed.

10. Relation values are returned in inconsistent representations depending on context: plain strings, reference objects, arrays of objects, or markdown-style links. Every serious integration must build its own normalization layer.

11. Editable relation columns and calculated lookup columns can expose similar metadata. Consumers must infer whether a column is writable from several properties rather than receiving one clear, authoritative writability field.

12. A single invalid column can reject an entire batch operation, making large writes brittle and requiring clients to validate the complete live schema before every write.

13. The REST API exposes metadata for some controls but not the underlying action formulas. That makes it impossible to fully inspect, diagnose, or maintain important document behavior through the API.

14. The API provides no apparent idempotency key for ordinary insert requests. That makes safely retrying a timed-out insert impossible: the original request may already have been applied.

15. Comments remain largely unavailable as an API surface. Customers cannot properly retrieve, audit, or automate comment workflows, while development attention is being spent adding animated stickers to those comments.

[Ruggy-Joesten]

Ok, that’s what I thought when you mentioned asynchronous mutations, so thank you for this level of detail. I’m going to chase the team and try to get some answers for you so I can share any updates on these specific fixes on our end. I appreciate you spelling out the use case so clearly.

On the broader point you raise, I understand your concerns, and I agree that API reliability is much more important than things like stickers, so I apologize if my original reply made it sound as if that wasn’t the case. You make a good point about opportunity cost. Like a lot of orgs, our resources across product, engineering, design, QA, release, and communications are limited. I get why it can be frustrating to see a fun launch when you’ve faced real issues using the product for important work.

I also agree that API reliability is a big deal. If basic reads and writes are timing out, and you have to add extra steps like polling, retries, and checks just to get routine work done, that’s a real product problem. I won’t argue with that.

Where I may see it a little differently is that I don’t think every smaller or more playful improvement means core product work has been deprioritized. Healthy product and engineering teams often have different streams of work happening at once, and sometimes smaller, more delightful projects can exist alongside the larger, harder, longer-running work that matters most to people. That does not erase the need for concrete progress on foundational issues, but I do think there can be room for both over time.

On the API side specifically, we often suggest using MCP where it fits, since that may be the better path for some workflows. That said, your examples make it clear there are still cases where people need the API directly, and where reliability, observability, and safe retries matter a lot. That context is useful, and I’ll make sure it is included when I bring this back internally.

I also know it’s important to show real progress, and just saying “the team is working on it” doesn’t answer your need to know how close we are to solving a problem. That’s why I’m putting together the community thread I mentioned earlier and generally trying to share as many updates as I can on requests from this community, including what’s shipped, what’s on the roadmap, and what we’re still tracking.

I know that may not satisfy the very fair desire for more concrete updates on API reliability right now. But I do want to be clear that your feedback is being heard. The underlying point is about dependability for real business systems, and that is a serious concern we want to get right.

[Max_OBrien]

plus one on this.
the API has languished.
the MCP capabilities should have been reflected in the API.
the code was being written and tested anyway.
a major opportunity has been missed here.

animated stickers are totally frivolous.
not even nice to have.
we are not 6 year olds.