ablo.decks.create() is a single atomic commit to the Ablo API. You describe the entire structure — deck metadata, slides, and their layers — as a plain JavaScript object, and the SDK compiles it into one batch of operations that either all succeed or all fail together. This declarative approach means you get transactional safety and minimal network round trips with no extra configuration.
Why one call beats many
When you build a presentation by callingslides.create() and layers.create() individually, a network failure partway through leaves your deck in a partially-written state. The declarative pattern sidesteps this entirely: the full tree goes into one commit, so readers never see an incomplete deck.
All-or-nothing atomicity
Every slide and layer in the tree commits together. A failure rolls the entire operation back.
Fewer round trips
One HTTP request replaces N sequential calls, cutting latency for large decks.
IDs minted up front
decks.create() returns every resource ID immediately, so you can store them for future updates without a second read.Safe retries
Pass an
idempotencyKey and re-run your code as many times as needed — duplicates are deduplicated server-side.Creating a deck atomically
Passslides (each containing layers) directly inside decks.create(). The SDK compiles all of them into one commit.
DeckResource that includes the id of every created resource — hold on to the layer IDs if you plan to update them later (see Incremental Updates).
RequestOptions
Everycreate, update, and delete method accepts an optional second argument of type RequestOptions:
wait
The wait field controls how long the server waits before returning a response.
| Value | Behaviour | When to use |
|---|---|---|
'confirmed' (default) | Waits for durable persistence before responding. When the call returns, the data is safely stored. | Scripts, data pipelines, anything that must guarantee the write landed. |
'queued' | Returns as soon as the server accepts the message, before it is persisted. Faster, but you cannot assume the write is durable. | Fire-and-forget jobs where you will verify success out of band. |
idempotencyKey
Passing an idempotencyKey makes your call safe to retry. If the server receives two requests with the same key, it executes the operation only once and returns the same CommitReceipt for both.
CommitReceipt
Mutation methods (update, delete, and the underlying commit) return a CommitReceipt:
decks.create() returns a DeckResource (which includes the full ID tree) rather than a bare CommitReceipt, but every other mutation method returns the receipt directly.
Adding a slide to an existing deck
You can add slides one at a time to a deck you created earlier.slides.create() is itself an atomic commit that creates the slide and all of its layers together.
Putting it all together
Describe the full tree
Build your deck, slides, and layers as a single nested object. Use layer builder functions like
barChart() and bullets() for complex content types.Choose your wait level
Pass
{ wait: 'confirmed' } (the default) for scripts that need the write to land before moving on, or { wait: 'queued' } for high-throughput pipelines where you verify asynchronously.Add an idempotency key for retries
Derive a stable key from your own data and pass it as
idempotencyKey. Re-running the same code won’t create duplicate decks.