Troubleshooting n8n Workflow Issues with Pageless Document Rendering in Gamma

Gregory L. · 2026-01-27T17:05:35.072Z

I've created an n8n workflow that is intended to send a pageless document with one card that is probably the equivalent of about 50 pages. I've run into issues with this actually rendering and creating the document in Gamma. I am a pro subscriber currently. I could use some help understanding why this is not rendering. I've tried twice so far. Neither time has rendered. I am using a custom theme that was sent as well. I will try chunking this up into one card for each section of this long document and see if that helps. Is this a known issue? Is this the right approach to get around it? Any other suggestions would be welcomed. Quick chat or direct messages with the technical team would also be welcomed to help here.

11 comments

· Sorted by Oldest

Gregory L.
·
·
Just as a follow-up here, I did run it again, split it, split the cards across the 12 sections of the document, and it has finally rendered.
✅1
Max J.
·
·
Hi Gregory! Great news that splitting into 12 cards worked! That's exactly the right approach. What likely happened: A single card with ~50 pages of content is a lot for our system to chew through all at once. Even with Pro (which gives you higher limits), really large single cards can still run into issues. Why your fix worked: Spreading content across multiple cards lets each one process on its own, which keeps everything running smoothly. This is actually the recommended way to handle long-form content. A few tips:
Card limits: As a Pro user, you can generate up to 60 cards per request, so feel free to split into more sections if needed
Text mode: If you're using the API directly, try textMode: "condense" for long documents - it's built for condensing large inputs
Pageless format: Works great for document-style output, but still benefits from logical card breaks
Best practice: For really long documents (~50+ pages), splitting into logical sections like you did is the way to go. One card per major section keeps things running well and honestly makes for a better reading experience too. Glad you got it sorted! Let us know if anything else comes up.
Gregory L.
·
·
Hi Max J. thanks for the tips there. You're suggesting splitting it into more cards, but the idea was this was supposed to emulate a PDF and just be one big long document. I've learned a lot doing it here. Not sure what you mean about condense, I actually want this to be a long document. This is ultimately a report that should probably be about 50 pages long. One other note may be a good best practice or thought process: my final card in this report is a data appendix that includes the tabular data for all the charts and graphs that could and will be created in the document. The data is also being added in line for Gamma to render. Including this data appendix at the end allows me to use other data in certain sections as needed and reach back for data that was not included in the cards. Then, Gamma's agent can render it as I need. So lots of interesting things coming up here....
Max J.
·
·
Good catch on the textMode clarification let me explain that better. About textMode options:
condense - Summarizes and shortens your input (not what you want)
preserve - Keeps your structure intact, just enhances formatting (probably what you want for a report)
generate - Uses your input as a prompt to create new content
For a 50-page report where you want to keep the full content, preserve is your best bet. "Condense" would actually try to shorten everything, which is the opposite of what you're going for. API limitations for your use case:
Input text: Up to 400,000 characters
Card limits: Pro gets you up to 60 cards per request
Single card processing: There's no hard character limit per card, but really dense single cards can time out during rendering. The system processes each card individually, so spreading content across multiple cards is more reliable.
Best practices for long documents:
pageless dimension is correct for continuous-scroll reports
Splitting into logical sections (like you did with 12 cards) is the recommended approach for reliability AND readability
Your data appendix approach is clever - having the tabular data available for Gamma's agent to reference is a solid pattern for chart generation
Why splitting works better: Even though you want one long scrollable doc, splitting into cards doesn't break the reading experience with pageless format. It just lets each section render independently, which avoids the timeout issues you hit with that massive single card. Your 12-section approach is exactly right. Let me know if you have questions about the data appendix rendering or anything else!
Gregory L.
·
·
Thanks, Max J.. Working with Gamma Agent a little bit, it provided an idea of instead of putting my data appendix in how I have been doing so, instead putting it in as a hidden card in JSON or CSV format. I'm playing with that right now to see if it works. The idea was that the Gamma Agent suggested making the data more programmatically available would allow it to use it better. This also makes me wonder: when I am providing data inline within my document sections, would it make more sense to present it in a code block as JSON or CSV? Does that allow Gamma to use it better? The new charting looks beautiful (by the way), but there are still challenges. I'm wondering if this would help.
Max J.
·
·
Great question, Gregory. Short answer: JSON/CSV format in code blocks doesn't give you a technical advantage over well-structured plain text tables. Here's why: How Gamma processes chart data: Our AI parses your input (whatever format) and converts it to our internal markup format. Whether you provide JSON arrays, CSV, markdown tables, or plain text, the AI extracts the data and transforms it the same way. There's no special "programmatic" parser that treats JSON/CSV differently. What actually helps with chart generation:
Clean numeric values (avoid currency symbols or text in data cells, we handle formatting separately)
Clear structure: first column = labels, additional columns = numeric data
Reasonable data sizes: 5-10 rows for pie/donut charts, 1-3 data columns for bar/line charts
About the hidden card approach: The AI processes what's in context. A "hidden" card with JSON data isn't treated differently than a visible card with a markdown table. If you're finding that the data appendix approach works well, it's likely because having all the data available in context helps, not because of the JSON/CSV format specifically. My recommendation: Use whatever format is clearest and easiest for you to generate. A well-formatted markdown table works just as well as JSON. The key is making sure the data structure is clear (labels vs. numeric columns) and the values are clean numbers. That said, if you're generating data programmatically from n8n, JSON might be more convenient for you on the automation side. Just know it's not giving the AI any special parsing advantage. Thanks for sharing these patterns. The data appendix approach for long reports is creative. Let me know how it continues to work for you.
Gregory L.
·
·
Your agent says different :)
Max J.
·
·
Thats good feedback! Thank you Gregory
Max J.
·
·
Our agent is designed to help work on your Gammas more than API documentation. Support Sal from our support site or going to our documentation is the best source of truth.
Gregory L.
·
·
Hoe csn i Access Support Sal?
Max J.
·
·

Gregory L.
·
·
Just as a follow-up here, I did run it again, split it, split the cards across the 12 sections of the document, and it has finally rendered.
✅1
Max J.
·
·
Hi Gregory! Great news that splitting into 12 cards worked! That's exactly the right approach. What likely happened: A single card with ~50 pages of content is a lot for our system to chew through all at once. Even with Pro (which gives you higher limits), really large single cards can still run into issues. Why your fix worked: Spreading content across multiple cards lets each one process on its own, which keeps everything running smoothly. This is actually the recommended way to handle long-form content. A few tips:
Card limits: As a Pro user, you can generate up to 60 cards per request, so feel free to split into more sections if needed
Text mode: If you're using the API directly, try textMode: "condense" for long documents - it's built for condensing large inputs
Pageless format: Works great for document-style output, but still benefits from logical card breaks
Best practice: For really long documents (~50+ pages), splitting into logical sections like you did is the way to go. One card per major section keeps things running well and honestly makes for a better reading experience too. Glad you got it sorted! Let us know if anything else comes up.
Gregory L.
·
·
Hi Max J. thanks for the tips there. You're suggesting splitting it into more cards, but the idea was this was supposed to emulate a PDF and just be one big long document. I've learned a lot doing it here. Not sure what you mean about condense, I actually want this to be a long document. This is ultimately a report that should probably be about 50 pages long. One other note may be a good best practice or thought process: my final card in this report is a data appendix that includes the tabular data for all the charts and graphs that could and will be created in the document. The data is also being added in line for Gamma to render. Including this data appendix at the end allows me to use other data in certain sections as needed and reach back for data that was not included in the cards. Then, Gamma's agent can render it as I need. So lots of interesting things coming up here....
Max J.
·
·
Good catch on the textMode clarification let me explain that better. About textMode options:
condense - Summarizes and shortens your input (not what you want)
preserve - Keeps your structure intact, just enhances formatting (probably what you want for a report)
generate - Uses your input as a prompt to create new content
For a 50-page report where you want to keep the full content, preserve is your best bet. "Condense" would actually try to shorten everything, which is the opposite of what you're going for. API limitations for your use case:
Input text: Up to 400,000 characters
Card limits: Pro gets you up to 60 cards per request
Single card processing: There's no hard character limit per card, but really dense single cards can time out during rendering. The system processes each card individually, so spreading content across multiple cards is more reliable.
Best practices for long documents:
pageless dimension is correct for continuous-scroll reports
Splitting into logical sections (like you did with 12 cards) is the recommended approach for reliability AND readability
Your data appendix approach is clever - having the tabular data available for Gamma's agent to reference is a solid pattern for chart generation
Why splitting works better: Even though you want one long scrollable doc, splitting into cards doesn't break the reading experience with pageless format. It just lets each section render independently, which avoids the timeout issues you hit with that massive single card. Your 12-section approach is exactly right. Let me know if you have questions about the data appendix rendering or anything else!
Gregory L.
·
·
Thanks, Max J.. Working with Gamma Agent a little bit, it provided an idea of instead of putting my data appendix in how I have been doing so, instead putting it in as a hidden card in JSON or CSV format. I'm playing with that right now to see if it works. The idea was that the Gamma Agent suggested making the data more programmatically available would allow it to use it better. This also makes me wonder: when I am providing data inline within my document sections, would it make more sense to present it in a code block as JSON or CSV? Does that allow Gamma to use it better? The new charting looks beautiful (by the way), but there are still challenges. I'm wondering if this would help.
Max J.
·
·
Great question, Gregory. Short answer: JSON/CSV format in code blocks doesn't give you a technical advantage over well-structured plain text tables. Here's why: How Gamma processes chart data: Our AI parses your input (whatever format) and converts it to our internal markup format. Whether you provide JSON arrays, CSV, markdown tables, or plain text, the AI extracts the data and transforms it the same way. There's no special "programmatic" parser that treats JSON/CSV differently. What actually helps with chart generation:
Clean numeric values (avoid currency symbols or text in data cells, we handle formatting separately)
Clear structure: first column = labels, additional columns = numeric data
Reasonable data sizes: 5-10 rows for pie/donut charts, 1-3 data columns for bar/line charts
About the hidden card approach: The AI processes what's in context. A "hidden" card with JSON data isn't treated differently than a visible card with a markdown table. If you're finding that the data appendix approach works well, it's likely because having all the data available in context helps, not because of the JSON/CSV format specifically. My recommendation: Use whatever format is clearest and easiest for you to generate. A well-formatted markdown table works just as well as JSON. The key is making sure the data structure is clear (labels vs. numeric columns) and the values are clean numbers. That said, if you're generating data programmatically from n8n, JSON might be more convenient for you on the automation side. Just know it's not giving the AI any special parsing advantage. Thanks for sharing these patterns. The data appendix approach for long reports is creative. Let me know how it continues to work for you.
Gregory L.
·
·
Your agent says different :)
Max J.
·
·
Thats good feedback! Thank you Gregory
Max J.
·
·
Our agent is designed to help work on your Gammas more than API documentation. Support Sal from our support site or going to our documentation is the best source of truth.
Gregory L.
·
·
Hoe csn i Access Support Sal?
Max J.
·
·