Block

In CE.SDK, everything in a design is a block. Images, text, shapes, video clips, audio tracks, stickers, backgrounds, and even pages and the scene itself. The Block API works the same way on all of them: select a block, read its properties, change them, save.

This shared foundation is what gives CE.SDK its consistency. Scopes, role-based permissions, effects, and export behavior all apply to whatever block is selected, regardless of the content it holds. The same surface works inside the editor (where users interact through the canvas) and in headless workflows (where code performs the equivalent operations programmatically).

Every block has a type assigned at creation that determines what it fundamentally is and which APIs apply.

• graphic is the unified type for any visual content (images, videos, shapes, stickers, backgrounds). A graphic block is built from a shape that defines its outline and a fill that defines what renders inside.
• text is editable text with font, color, alignment, and effects. Supports variable tokens for dynamic content.
• page is a canvas inside a scene. Pages hold the blocks that make up the design. In video mode, each page also has duration and a timeline.
• audio is an audio clip with volume, speed, and trim.
• group is a container with no fill or shape of its own. Wraps multiple child blocks so they move and transform together.
• track is a video-specific container that sequences clips in time on the timeline.
• cutout defines a masked or cut-out area within a composition, also used for die-cut print paths.
• stack arranges its children in a line along an axis with optional spacing.

Within a running session, the engine refers to blocks by numeric handle. Across sessions (save, load, serialize), the stable identifier is the UUID. That is the right anchor for stored references like “the headline placeholder on this template.”

Templates depend on per-block configuration. A Creator locks the logo block, marks the headline as a placeholder, ties a text variable to an address line. Each of these is a setting on a specific block, configured once and saved with the scene. When the Adopter opens the same scene later, the engine reads those per-block settings to decide what is editable and how.

Headless workflows use the same surface from code. Finding the right block by Kind, by UUID, or by type is what turns “load template, inject data, export” into a few lines per pipeline rather than a custom script per template. Postbuddy uses this pattern for direct-mail campaigns where the same postcard template generates thousands of personalized variants, each produced by populating variables on text blocks and replacing image fills on graphic blocks from CSV data.

Inside the editor, the engine manages block lifecycle automatically. Blocks are created when a user adds an element, updated as they edit it, and destroyed when they delete it. No manual cleanup needed.

In headless workflows, your code creates and destroys blocks explicitly. The engine does not garbage-collect blocks that fall out of use. For long-running batch processes that load many templates in sequence, destroying temporary blocks between iterations is what keeps memory bounded.

Blocks are the foundation that block-hierarchy, scope, placeholder, and template all sit on top of. The hierarchy describes how blocks nest under pages and the scene. Scopes are the per-block permissions. Placeholders are blocks designated as editable slots. Templates are scene files configured by setting properties on individual blocks.