Domino Attachments over REST: DRAPI and DAS Both Have Attachment Endpoints — the Difference Is Modern vs Legacy

The earlier pieces were about users uploading from a UI; sometimes you move attachments programmatically over REST. Domino has two REST APIs: DRAPI (modern, KEEP) and DAS (legacy, Extension Library). A common misconception is 'DAS is read-only' — not so: DAS has its own dedicated attachment endpoints to create, read, update, and delete. The real difference is modern vs legacy, plus a DAS-specific trap: don't push a whole document with embedded attachment data through create/update (it returns 400) — use the dedicated attachment endpoint. This piece lines up both APIs' endpoints and differences.

Multi-File Upload and Selective Attachment Delete in Domino: Classic Web and XPages 14.5.1

The last piece covered attaching one file three ways; this one goes to 'many at once': a classic web form uses the HTML5 multiple attribute to select several files, XPages only got native multi-select by default in 14.5.1 (before that it was OpenNTF community controls), and the case you actually hit most but is thinly documented — deleting attachments by criteria: iterate EmbeddedObjects and Remove by a condition on .Source (with a runnable example). With a figure showing how the selected files land in one rich text field.

File Attachments in Domino Three Ways: Notes Client, Classic Web Form, and XPages

Attaching a file in the Notes client is so easy it barely feels like a feature — drag it into a rich text field, done. But move that same need to the web, or into XPages, and 'how do users upload a file' becomes three different answers: the client uses a rich text field, a classic web form uses the File Upload Control embedded element, and XPages uses xp:fileUpload paired with xp:fileDownload. This piece lines up the three front-end upload mechanisms and points out the reassuring part — all three land as an attachment on the same rich text field of the document, so the backend code to list, extract, and delete them is shared.

The Java Fix for Domino IQ Timeouts: LLMReq.completionStream, and How XPages SSJS Calls It

Yesterday's piece used LotusScript's CompletionStream to get past Domino IQ's 5-minute timeout; if your code is Java (an agent, a bean) or XPages (SSJS), you hit the same timeout. This is the Java version: LLMReq.completionStream with the CompletionStreamCallback interface (return Continue/Stop to control the stream), plus a key fact — SSJS has no native LLM class, but SSJS's session IS a lotus.domino.Session, so you call the Java API directly or wrap the streaming in a Java class and reference it from SSJS. With a three-language comparison table.

Domino IQ Requests Timing Out at 5 Minutes? No Setting to Raise — Switch to Streaming

You build a long-document summary on Domino IQ; in testing the prompts are short and it's instant. In production someone feeds in a huge thread on a modest GPU, and you hit a 'network processing did not complete in time' timeout. You go hunting for a timeout setting to raise — there isn't one. Domino IQ requests time out at about 5 minutes, by design, and it can't be changed. This piece walks a real scenario: why it times out, how to switch from Completion to CompletionStream to get past it, and one important caveat — streaming keeps it from timing out, but doesn't make it faster.

Put the CA in certstore and Everything Trusts It? DRAPI's Outbound Actually Uses the JVM Truststore, Not certstore

Once a certificate is in certstore.nsf, developers hit two practical questions: how does my service — the Domino REST API especially — serve HTTPS straight from it? And when my own code calls out over HTTPS, does it validate the peer against certstore too? The second answer breaks a common misconception: on one server, certificate trust is actually split across three separate places. Part three of the certstore series, grounded in hands-on testing on Domino 12.0.2, covers DRAPI's keepconfig.d TLSCertStore config, what certstore's trusted roots are really for, and disentangles certstore / Domino Directory / JVM cacerts once and for all.

Wiring Domino CertMgr to Let's Encrypt: Automatic TLS Certificate Requests and Renewals over ACME

Manual certificate import still means swapping every 90 days, and still means forgetting. This piece (part two of the certstore series) covers CertMgr's real killer feature: requesting, configuring, and renewing free, trusted TLS certificates from Let's Encrypt automatically over the ACME protocol. Set up the two ACME account profiles (Staging/Production) and Global Settings, walk the request flow and the six things CertMgr does automatically after Submit, understand HTTP-01 vs DNS-01 challenges, and see why the micro CA is test-only, plus ECDSA and key rollover.

Getting Started with Domino Certificate Management: CertMgr and certstore.nsf Instead of Scattered .kyr Keyrings

Since Domino 12, TLS certificates no longer live as .kyr keyring files scattered across each server's disk — one CertMgr server task plus one certstore.nsf database manages them all: certificates stored in TLS Credentials documents, private keys encrypted with 256-bit AES, protected by the database ACL, and readable only by the servers you choose. Part one of the certstore series: the model, how to stand certstore.nsf up, what a TLS Credentials document holds, and the full steps to import an existing third-party CA certificate.

Formula's @For Loop: When You Actually Need It, and a Real 'Reverse an Org Hierarchy' Example

The list functions (@Transform, @Explode…) handle a whole list in one line, but some jobs still need a real loop — accumulate state, build a string in order, reverse a list. This piece goes deep on @For: the four parts (initialize/condition/increment/body), a thing that trips people up (@For returns 1, not your accumulated value, so you return the variable on a separate final line), and a real need worked through — turning an A\B\C org hierarchy into C\B\A. Plus how @While/@DoWhile differ, and the infinite-loop guard.