Hi there,

Abyssale now speaks MCP. Connect it to Claude.ai, Claude Code CLI, ChatGPT/Codex, or Cursor, and your AI assistant can work directly in your Abyssale workspace, no API integration required.

What it can actually do

• Browse and search your designs and projects, look up fonts, and check remaining credits — all from a normal conversation.
• Read a design's full structure before touching it: layers, overridable attributes, formats, even animation tweens and print bleed settings.
• Generate on command a single static image back instantly, or go async for video, GIF, HTML5 banners, multi-format batches, print PDFs, multi-page PDFs, and AI actions like Text-to-Image and Remove Background.
• Create brand-new designs from scratch. import_design_from_json builds a fully editable, multi-format design directly from a JSON payload, meaning an assistant can go from a brief to a real Abyssale design without anyone opening the editor first.

Ask Claude to "generate this banner in every format for our Q4 campaign" or "build me an editable product design from this brief," and it can just do it, reading the design first so it never guesses at layer names, then rendering straight to a file URL.

Why it's worth connecting

• Nothing to build. Connect once, and the tools are available in every conversation from then on.
• Your workspace stays yours. Credits, designs, and formats never leave Abyssale, every generation still spends your workspace's credits, and access is scoped to your Abyssale role.
• A couple of minutes to set up, whichever client you use: Claude.ai (Settings → Connectors), Claude Code CLI (one command), ChatGPT/Codex (Developer mode + a plugin), or Cursor (an entry in mcp.json).

Hi there,

AI Translation in the Spreadsheet has been one of the quickest ways to localize a batch of creatives: select your text, pick a language, and Abyssale translates it while preserving context and meaning, optionally duplicating your rows so the originals stay intact.

It had one limitation that anyone running multilingual campaigns felt immediately: one target language per operation. Localizing a campaign into six markets meant selecting the same content, opening AI Actions, and running the translation six separate times. It worked, but it was repetitive in exactly the way automation is supposed to eliminate.

That limitation is gone. You can now select up to 10 target languages at once, and Abyssale translates your content into all of them in a single operation.

What changed

The flow is the same one you already know, with one difference at the language step:

1. Select your text content in the spreadsheet: a single cell, a text column, or a row
2. Click AI Actions in the toolbar
3. Select your target languages up to 10 instead of just one
4. Keep Duplicate rows & add translations toggled on to create a new row per language, or untoggle it to replace the selected text
5. Click Make it

One click, and every selected language is handled. With duplication enabled, a single source row becomes one row per target language, ready to generate a full multilingual variant set without a single repeated action.

The language column fills itself

There's a second improvement bundled in. If your spreadsheet has a language column (the one you can add via the Manage columns button), Abyssale now fills it in automatically for each translated row with the corresponding language.

Before, that column was something you had to fill by hand after translating, or leave empty. Now every duplicated row arrives already labeled with its language, so you can see at a glance which row belongs to which market, sort or filter by language, and, if you're using that column as a dynamic variable in your design, drive language-specific content or formats straight from the spreadsheet without any manual tagging.

Why it matters

The time saving is obvious, but the bigger shift is that the structure of your spreadsheet now matches how localization work actually happens. Campaigns aren't translated into one language; they're translated into a market list. Selecting that list in one go means:

• Fewer steps, fewer mistakes. No risk of missing a language because you lost track of which ones were already done.
• Cleaner spreadsheets. All translations of a row are created together, so they land next to each other rather than being appended in whatever order you got to them, and each one is already tagged with its language.
• A faster path from one master to a full multilingual batch. Write your copy once, translate it into your ten markets in one action, and send the whole set to generation.

What hasn't changed

• AI Translation is still available in the Spreadsheet generation method
• The 45+ supported languages are the same, covering Latin, Cyrillic, Arabic, Chinese, Japanese, Korean, Hebrew, Thai, Devanagari, and other writing systems
• Translation still preserves context and meaning rather than doing a literal word-for-word swap
• Each translation consumes AI credits as before; selecting multiple languages runs the corresponding number of translations

Hi there,

The in-app API console has always been the fastest way to see what a generation request for a given design looks like: open it, and it hands you a ready-to-run JSON payload built from that design's configuration. Until now, though, that payload was always a synchronous request, which meant the console couldn't show you, or let you test the parts of the API that only exist in asynchronous generation.

That's changed. A new Query mode selector in the console lets you switch between Sync and Async, and the payload, the available options, and the result behavior all update to match.

Two modes, two payloads

The two modes correspond to the two generation paths in the API, and the console now generates the correct payload for whichever one you pick:

• Sync : Return one static image directly. A single format, a single result, returned in the response. The payload uses template_format_name (a single string).
• Async : Queue generation and return an ID. One or many formats in a single call, processed in the background. The payload uses template_format_names (an array), and the API returns a generation request ID immediately.

Switching modes isn't just a cosmetic toggle: it changes which AI parameters the console includes, because the two paths don't support the same set.

Why some AI parameters only appear in async

If you've enabled Remove Background or Text-to-Image on a design and wondered why the console's sync payload didn't reflect it, this is the reason. Those actions are only supported on asynchronous generation. Background removal can take longer than the synchronous path's 10-second limit, so it's deprecated in sync and not recommended there; Text-to-Image behaves similarly. Surfacing those parameters in a sync payload would produce a request that looks correct but fails at runtime — so the console deliberately filters them out.

Concretely, when the console builds a payload for a design:

• Sync includes Auto Focus (auto_focus and auto_focus_properties)
• Async includes Auto Focus, Remove Background (remove_bg and remove_bg_properties), and Text-to-Image

Before, the only way to test a Remove Background request from the console was to add those fields by hand. Now you switch to Async and they're generated from the design's configuration, the same way Auto Focus always has been.

A helper block below the console in sync mode explains this and links straight to the asynchronous generation docs, so anyone landing on the console for the first time understands why a design's AI settings don't all show up in the sync payload.

File type is now available in both modes

The File type selector (Auto, PNG, JPEG, WEBP, AVIF) previously only appeared in some contexts. It's now available in both modes, sitting right next to the Query mode selector, so a static design gets the same output-format control the other design types already had, and it's a visible reminder that the API supports several export types, not just one.

Testing async without leaving the console

Async generation in production means receiving results via webhook or polling the request ID. In the console, you don't have to do either: run an async query and the result still appears below, exactly as it does for animated, print, and multi-page designs, which were already async-only. The console handles the polling for you, so you can iterate on an async payload with the same fast feedback loop you're used to from sync.

What this fixes in practice

• No more hand-editing payloads to test Remove Background or Text-to-Image from the console
• No more confusion about why a design's AI settings don't all appear in the generated request
• A clear on-ramp to async generation for anyone whose integration needs multi-format output or the async-only AI actions

Hi there,

Background removal is one of the most-used AI actions in Abyssale, and one of the most common ways to waste credits on it is running it on an image that doesn't need it. If a batch mixes already cut-out PNGs with regular photos, every image gets processed the same way, including the ones that already have no background to remove.

A new Skip if Already Transparent option fixes that. Turn it on, and Abyssale checks each image for existing transparency before deciding whether to run background removal at all.

How it works

When the option is enabled, Abyssale first checks whether the image already contains a significant amount of transparency:

• If it does, background removal is skipped and the image is used as-is. You're charged only for the check: 1 AI credit.
• If it doesn't, background removal runs normally. The cost is the selected model's credit cost plus 1 AI credit for the check.

Trim Transparent Pixels still applies either way. If you have both options enabled, an already-transparent image isn't re-processed by the removal model, but it's still cropped down to its subject, so the result stays compact and centered.

One thing to be aware of: the transparency check always costs 1 AI credit when the option is on, even when removal ends up running afterwards. If you know none of your source images are transparent, leave it off, there's nothing to save in that case.

Where to find it

You can enable it in two places:

• In the Remove Background toolbar, at the moment you generate, alongside the model picker and the Trim Transparent Pixels option
• Later, in the Style panel, under the AI generation section for the selected layer, next to Trim Transparent Pixels, without needing to launch a new generation

Saved for future generations

Like the other Remove Background settings, this one can be saved as part of the layer's AI action, so it carries over automatically to every future variation of the design, whether generated through Quick Generation, a spreadsheet, or the API.

It's worth noting that Skip if Already Transparent is a design-level setting, not an API parameter. There's no API property for it: when the toggle is enabled on the layer, it applies to every generation of that design, including ones triggered via the API, and the API payload can't set or override it. That means once you've configured it in the editor, you don't need to think about it again in your integration.

Where this matters most

The payoff is biggest in batch work. If you're running background removal across a product catalog, a set of user-uploaded images, or any source where some assets are already cut out and some aren't, this stops you from paying full model cost on images that would have come out unchanged anyway, and does it without you having to sort the images by hand first.

Hi there,

AI settings in Abyssale used to be a single on/off switch: AI features were either available to a workspace or they weren't.

That's still true, but it's no longer the whole picture. Administrators can now go a level deeper and control which specific AI models their team is allowed to use for each AI feature, and set which one is used by default.

Why this exists

As Abyssale has added more AI models across features like Text-to-Image and Remove Background, teams have ended up with real decisions to make about which models they actually want in play, not because every model isn't useful, but because "useful" depends on the team. A model might be excellent and still be the wrong choice for a given workspace: too expensive to run at volume, not aligned with a client's content policy, or simply inconsistent with the quality bar the team has settled on.

Until now, there was no way to express that at the workspace level, every enabled AI feature meant every model behind it was fair game, and standardizing on one meant trusting each person to pick the right one every time.

Where to find it

The new controls live in workspace AI settings, in a Models preferences section. For each AI feature, Text to Image, Remove Background, and so on, you'll see the full list of available models, along with:
​

• The model's provider (Google Gemini, OpenAI, Alibaba Cloud, and others)
• Supported resolution and aspect ratio tags
• Minimum Credit cost per generation
• A toggle to enable or disable it

Turning models "on" or "off"

Each model has a simple toggle. ON means it's available for the team to select when generating content. OFF hides it from selection entirely, team members won't be able to use it, even if their subscription plan technically includes it.

This is the mechanism for restricting usage: disable anything that doesn't meet your organization's cost, quality, or compliance bar, and it disappears from the picker for everyone in the workspace.

Setting a default model

For any enabled model, the ⋯ (more options) menu includes Set model as default. That model is then pre-selected automatically whenever someone on the team starts a new AI generation, so the team defaults to whatever you've decided is the right choice, instead of relying on each person to remember and pick it manually every time.

Two rules keep this consistent: a model has to be enabled before it can be set as default, and disabling the current default forces you to choose a new one.

What this unlocks

Put together, enabling/disabling models and setting a default give admins three concrete levers:

• Compliance : keep models that don't meet internal content or data standards out of reach entirely
• Consistency : make sure the whole team defaults to one approved model instead of drifting across whichever one each person happens to pick
• Cost control : disable higher-cost models when they're not needed, without having to police usage manually after the fact

This sits alongside the existing workspace-wide AI Features Access toggle and the AI Model Training setting (which controls whether anonymized workspace data can be used to improve Abyssale's models), both still available in the same settings area, for admins who want to manage AI access at that broader level too.

→ Read the full guide: Control AI Features and Content Training in Abyssale

→ Go to workspace AI settings

Hi there,

Webhook deliveries can now be signed, so anything receiving them can verify a payload actually came from Abyssale and hasn't been tampered with in transit. It's opt-in: nothing changes for existing integrations until a workspace fetches its signing secret for the first time.

How it works

Signing is controlled through three endpoints:

• GET /signing-secret : fetches the workspace's signing secret, minting one if it doesn't exist yet. This is the action that turns signing on for a workspace. Until it's called, deliveries go out unsigned exactly as before.
• POST /signing-secret/rotate : generates a new secret. The previous one stays valid for 24 hours, so you can roll the new secret out to your receiver on your own schedule instead of everything needing to happen atomically.
• POST /signing-secret/revoke : ends that overlap early, if you don't want to wait out the full 24 hours. Takes effect within 60 seconds.

Once a workspace has a secret, every webhook delivery carries two headers:

• X-Abyssale-Signature: t=…,v1=… : an HMAC-SHA256 signature computed over the raw request body, along with the timestamp it was signed at
• X-Abyssale-Delivery-Id : a unique ID per delivery, meant for deduplication on the receiving end

Verifying a signature is standard HMAC verification: recompute the HMAC-SHA256 over the raw body using your signing secret, compare it against the v1 value, and check the t timestamp is recent enough to reject replayed deliveries.

SDK support

Both official SDKs support signing as of this release:

• @abyssale/sdk 1.3.0 (Node.js/TypeScript) — signing secret management plus a signature verifier, importable on its own from @abyssale/sdk/webhooks so a receiver can verify incoming payloads without an API key configured at all.
• abyssale 1.1.0 (Python) — the same secret management methods and a verifier, available via abyssale.webhooks.

In both cases, verification is pure local cryptography it doesn't call the Abyssale API, so it works even in a minimal webhook receiver that has no other reason to hold credentials.

Why it matters

Without signing, any endpoint receiving Abyssale webhooks has to trust that a POST claiming to be from Abyssale actually is there's no way to distinguish a real delivery from a forged one. Signing closes that gap: verify the header, know the payload is genuine, and use the delivery ID to safely ignore duplicates if a delivery gets retried.

Because it's opt-in, there's no migration required to keep existing integrations working. Turning it on is a single call to GET /signing-secret whenever you're ready.

→ developers.abyssale.com/webhooks/signature-verification

Hi there,

Building on top of the Abyssale API has meant hand-rolling HTTP requests since day one — right auth headers, right payload shape, your own retry logic if a request timed out. That's no longer the only option. Abyssale just shipped its first official SDKs:

• @abyssale/sdk for Node.js/TypeScript (now at 1.3.0),
• and abyssale for Python (now at 1.1.0).

Both SDKs wrap the core REST API — designs, generation, projects, workspace templates, exports, and, as of this release, webhook signing — in a typed, idiomatic client for their respective language, so integrating Abyssale into a codebase looks like using any other well-maintained SDK, not stitching together fetch calls.

@abyssale/sdk for Node.js / TypeScript

Install it with:

npm install @abyssale/sdk

Node.js 20.3 or later is required — not just Node 20. The retry middleware relies on AbortSignal.any, which only landed in 20.3.0, so installing on 20.0–20.2 succeeds but fails at runtime.

Configuration is entirely environment-variable driven — no constructor, no setup step beyond setting ABYSSALE_API_KEY. Note that the SDK throws at import time if that variable isn't set, which occasionally surprises people in test environments:

import abyssale from '@abyssale/sdk';

const { data, error } = await abyssale.generateImage('your-design-id', {
  elements: {
    title: { payload: 'Hello World' },
    background: { background_color: '#FF0000' },
  },
  template_format_name: 'facebook-post',
});

console.log(data?.file.cdn_url);

A few things worth knowing:

• Never throws on HTTP errors. Every method returns { data, error, response }, so error handling stays explicit instead of relying on try/catch around network calls.
• Automatic retries, deliberately narrow. 5xx is retried on reads only — a generation POST is never repeated, since a timeout doesn't mean the render didn't happen, and retrying it could bill you twice. A 429 carrying a Retry-After header gets the full retry ladder; a bare 429 gets a single one-second probe, since that status alone can mean either "out of credits" or "hit the gateway's per-second ceiling." feature_not_in_plan is never retried. Retry count is configurable via ABYSSALE_MAX_RETRIES.
• Built-in polling helpers. waitForGenerationRequest and waitForDuplicationRequest handle the poll loop for async jobs (multi-format generation, multi-page PDFs, workspace template duplication) so you don't have to write your own polling logic.
• Fully typed. Every request and response type is generated directly from the OpenAPI spec, so IDEs get full autocomplete on every field.
• Webhook signing, new in this release. Three methods for managing your webhook signing secret (list, create, delete), plus a signature verifier importable on its own from @abyssale/sdk/webhooks — it needs no API key at all, since verifying a signature is pure local cryptography, not an API call.

One caveat: the design-import surface is deliberately left out of the SDK for now, since it's still in Alpha and the format may change — the OpenAPI spec used to generate the client strips those endpoints so a routine regeneration can't accidentally reintroduce them before things stabilize.

→ npmjs.com/package/@abyssale/sdk

→ github.com/getabyssale/abyssale-sdk

→ developers.abyssale.com/sdks/nodejs

Abyssale for Python

The same core coverage is now available for Python teams, published to PyPI as abyssale, at 1.1.0.

pip install abyssale

from abyssale import abyssale, AbyssaleAPIError

try:
    banner = abyssale.generate_image(
        "your-design-id",
        elements={
            "title": {"payload": "Hello World"},
            "background": {"background_color": "#FF0000"},
        },
        template_format_name="facebook-post",
    )
    print(banner.file.cdn_url)
except AbyssaleAPIError as e:
    print("API error:", e.id)

The two SDKs are built on the same underlying API, but they don't handle errors the same way. Where the Node SDK returns { data, error } and never throws, the Python SDK raises AbyssaleAPIError on failure, carrying a machine-readable id you can match against. Worth keeping in mind if you're used to one and picking up the other.

Request bodies in Python are plain dicts by design rather than generated model classes — the elements schema is an anyOf with no discriminator, so a strict model would risk mis-coercing valid payloads.

Like the Node SDK, this release also adds webhook signing support via abyssale.webhooks: the same list/create/delete methods for your signing secret, plus a signature verifier that works without an API key configured.

And the same Alpha caveat applies here too: design-import endpoints are intentionally excluded from the generated client while that feature's format is still settling.

→ pypi.org/project/abyssale

→ github.com/getabyssale/abyssale-python-sdk

→ developers.abyssale.com/sdks/python

Why this matters

Every integration built directly against the raw REST API was solving the same problems over and over: retry logic that doesn't double-bill you, polling for async jobs, verifying webhook signatures by hand. With official, typed SDKs for both Node.js and Python — and now first-class webhook signing in both — that work is done once, centrally, and maintained alongside the API itself.

Questions about migrating an existing integration to one of the SDKs? Reach out at help@abyssale.com.

Hi there,

For as long as the Abyssale API has existed, it's followed the same rule: build the design in the editor first, generate from it after. That rule just changed.

You can now send a full design as a single JSON payload and have Abyssale create it for you — and export any existing design back into that same shape.

On top of that, workspace templates are now reachable by API too, alongside a round of platform-level improvements aimed squarely at anyone running Abyssale as part of an integration.

Design Import from JSON — Alpha

Until now, the editor was a mandatory first step. Every design, however simple, had to be built by hand before the API could generate a single asset from it. That dependency is gone: a design can now be described entirely as JSON and imported directly, without ever opening the builder.

The reverse works too — any existing design can be exported into that same JSON shape, which means you can pull a design out, inspect or modify its structure, and import it back as a new one.

This isn't limited to simple static visuals. It covers:

• Static designs
• Animated designs
• Print designs, including multi-page PDFs

Why it matters

This turns design creation itself into something automatable, not just design generation. A few things become possible that weren't before:

• Programmatic design creation — build designs directly from code instead of a human building them first in the UI
• Library migration — bring an existing set of designs from another tool or system into Abyssale by generating the JSON payloads programmatically
• AI agent-built designs — since a design is now just structured data, an agent can construct one directly, rather than being limited to filling in variables on a template a human already built
• Duplicate, tweak, re-import — export a design to JSON, change a handful of fields, and import it as a variant, without touching the editor at all

A note on Alpha

The feature is marked Alpha because the JSON format itself may still evolve — but it's live and rolled out to everyone, with no partner signup or waitlist required to access it. Anyone can start using it today.

Workspace Templates, Now by API

Workspace templates, your brand masters, standardized layouts, whatever your team treats as a starting point — were previously something you could only spin up into a project from inside the builder. That's now available by API as well: list the templates in a workspace, and turn any one of them into a new project programmatically.

This is particularly useful if you're standardizing on a fixed set of brand templates across multiple teams or client accounts and want project creation to be part of an automated flow rather than a manual step someone has to remember.

Platform Improvements

Alongside the two feature additions, this release includes a set of changes to the API's underlying behavior:

• Consistent error handling across every endpoint, so a failure looks and behaves the same way no matter which part of the API triggered it
• Per-workspace rate limiting, so usage in one workspace doesn't affect another
• Versioned responses, so integrations can rely on a stable response shape even as the API evolves

In practice, this means fewer support tickets from integrations breaking in confusing, hard-to-diagnose ways — and a clear, consistent answer any time someone asks "why did my request fail?"

Developer Docs, Rebuilt

The developer documentation has been rebuilt from the ground up, with a quickstart, a full error reference, a changelog, and a complete endpoint catalogue, all in one place.

→ developers.abyssale.com

→ api-reference.abyssale.com

Hi there,

For a while, AI in Abyssale meant reaching into a menu, buried a click or two away from the layer you were actually working on. That's changed. Remove Background, Auto Focus, the Eraser, and AI Text-to-Image now sit together in a single AI toolbar that appears the moment you select an image layer, and each of them just got meaningfully more capable.

Here's a full walkthrough of what's new, with a link to the dedicated guide for each feature if you want the details.

One Toolbar, Four AI Actions

Select any image layer in the Design Editor and an AI toolbar appears at the bottom of the canvas, with all four AI actions right there: Remove Background, Focus, Erase, and Ai text to image. No more navigating through separate modals or side-panel menus depending on which action you needed, it's the same entry point every time, for every action.

From there, each action opens its own context directly in the toolbar, where you configure it and generate without leaving the canvas.

Remove Background: Pick the Model, Fine-Tune the Result

Background removal now gives you a choice of model instead of a single fixed engine. Click the model dropdown to see the available options, each labeled with its relative AI credit cost:
​

• Bria RMBG 2.0 (default) — a high-precision, licensed-data model that's a safe default for most images
• Birefnet — an open-source segmentation model, a solid freely-licensed alternative
• Ideogram's — strong at fine detail like hair or fur
• PixelCut — built for e-commerce and product photography
• imageUtils — a straightforward, no-frills option

If your first pass doesn't cleanly isolate the subject, especially around tricky edges, switching models is usually faster than repeating the same one. Two additional controls round out the feature: Trim Transparent Pixels, which crops the image down to its subject after removal, and Manual Selection, which lets you draw a box around the area you want to guarantee is kept (Design Editor only, not available via API).

Once you're happy with a result, you can save it as the rule for that layer going forward, so every future variation gets the same treatment automatically.

→ Read the full guide: Remove Image Backgrounds

Auto Focus: Smarter Framing for People and Objects

Auto Focus keeps your subject perfectly framed regardless of the original image's size or orientation, and it offersn the two detection models depending on what you're framing:

• People Model — built for human subjects, with control over portrait framing (face, head, shoulders, or full body), zoom intensity, and, when there's more than one person in frame, which subject takes priority (largest, centered, leftmost, rightmost, or all). Enterprise plans also get Celebrity Matching, letting you name a public figure to automatically center the focus on them.
• General Model — for objects, animals, vehicles, or complex scenes. The AI detects individual elements as "Tags" you can select and merge into a single composition, with the same zoom controls (off, low, medium, max).

During automated variations, if the AI detects the tags you've chosen in a new image, it merges them automatically to keep your composition consistent at scale, useful for anything from headshots to product shots run through a large batch.

→ Read the full guide: Auto Focus

AI Eraser: Remove Objects Without Leaving the Canvas

The AI Eraser lets you paint over any object, logo, or unwanted detail in an image and have it intelligently replaced with matching background content — no manual retouching required. It's a natural fit for cleaning up product photos, removing logos from reused assets, or hiding distracting background elements.

Two selection modes are available: brush mode, with an adjustable size for fine edges or broader areas, and bounding box mode, for quickly clearing larger or simpler shapes. Like the other AI actions, you now choose which AI model handles the erase before applying it, and the edit is non-destructive until you confirm it.

→ Read the full guide: Erase Unwanted Objects from Images

AI Text-to-Image: More Models, Reference Images, and API Access

Text-to-Image turns a written description into a custom visual directly inside the builder, no stock photo search, no manual illustration. The feature now supports multiple AI models instead of a single one, and depending on the model you choose, you can add up to 4 reference images to steer the generation instead of working from the prompt alone.

Other capabilities carried over and still worth knowing:

• Choose the output ratio (square, landscape, portrait, ultra-wide, and more) so the generated image fits your layout without awkward cropping
• Browse your prompt history during the current session to reuse or tweak earlier prompts
• Auto-generate a starting prompt from an existing image in the layer, if you want a variation that stays visually consistent with what's already there

Text-to-Image is also available through the API: pass a text_to_image prompt on an image element instead of a static URL, and Abyssale generates the visual in real time as part of your automation.

→ Read the full guide: AI Text to Image

Save Once, Scale Everywhere

The biggest shift isn't any single action, it's that none of them are one-off anymore. Save an AI action once (Remove Background, Auto Focus, or Text-to-Image) and it becomes the standing rule for that image layer.

Every future variation of the design inherits it automatically, whether it's generated through Quick Generation, a spreadsheet, or the API, including having each variation generate its own unique AI image, not just reuse the same one.

That reach comes with control. In Design Settings, you decide whether AI Text-to-Image is allowed on a design at all. For Quick Generation specifically, you can also decide whether the end user creating a new variation is allowed to generate an AI image inside it, or not, so self-serve generation stays exactly as open, or as locked down, as you want it.

For the technical details on wiring any of this into your own workflows, remove_bg, auto_focus, and text_to_image element properties, model names, and payload examples — the API reference has the full spec.

→ Read the API reference: Image element properties

Hi there,

You can now generate print-ready PDFs for large formats directly in Abyssale, at actual dimensions, no workarounds needed.

What's new

Larger canvas sizes

Create print formats up to 10 000 mm per side. Metro posters, roll-ups, billboards, bus shelters, all supported natively.

Custom DPI per format

Set the exact resolution your printer requires, independently for each format in your design. 300 DPI for close-up print, 72–150 DPI for large outdoor formats.

Live credit cost estimate

The generation cost in credits is displayed in real time as you adjust dimensions and DPI — no surprises before you generate.

Higher asset upload limit

Import source files up to 500 MB, so you can bring in high-res images and assets without compression.

How it works

New design : Create a new design, select a Print design type (Multi format or Multipage), then define your format dimensions in mm or inches. For each format, set the DPI that matches your print requirements in the design editor.

Existing design : Already have a print design? Simply add a new format on it to your large format size, then adjust the DPI accordingly.

The maximum available DPI updates automatically based on your canvas size, you'll always see what's possible before generating.