Creating a Document in the Domino REST API: Why It Needs a Form Field and a dataSource

The door is open (schema + scope); this part does the real work: create/read/update/delete NSF documents over REST. Create is POST /document with a required Form field in the body, and the response @meta carries a unid; read is GET /document/{unid}/{mode}. Every CRUD call carries dataSource — and that value is the scope name you made last part. It also covers two things that give Domino developers pause: why the Form field is required, and what a mode is. Part four of the DRAPI series.

Scopes and Schemas in the Domino REST API: How an NSF Becomes REST Endpoints (Exposing Nothing by Default)

Putting an NSF on REST isn't flipping a switch that exposes everything. DRAPI is secure-by-default: you write a schema (a whitelist of which forms, views, folders, agents, and fields go out), then create a scope (the REST mapping that activates it). A scope's name is the very name the JWT scopes claim recognizes from the last part — and underneath, Domino's ACL and Readers fields still apply. This piece separates schema from scope. Part three of the DRAPI series.

Getting 401s from the Domino REST API? Understand Its JWT Authentication and Scopes First

Almost every DRAPI call has to prove who you are. It doesn't use classic session/LTPA — it uses a JWT bearer token: POST to /api/v1/auth with Domino credentials for a token, then send it in the Authorization header on every request. This piece covers logging in for a token, what the scopes/aud claims control, where tokens come from (Domino-signed JWT, external OIDC, idpcat.nsf), and traps like the signing key changing on restart. Part two of the DRAPI series.

Getting Started with the Domino REST API: Turn NSF Data into Endpoints Any Language Can Call

You want a modern front end, a Python service, or a Power Automate flow to read and write Domino data. The classic answers — XPages, DIIOP, a hand-rolled LotusScript web agent spitting JSON — all make the caller meet Domino on its terms. The Domino REST API (DRAPI, the KEEP project) flips it: a standard REST/JSON layer over your NSF that anything speaking HTTP can call. This is part one of a DRAPI series — what it is, how it differs from classic access, the three building blocks (scope/schema, JWT, OpenAPI/Swagger), and how to start.

A Cross-DB Embedded View Won't Start in the Test Region? It's the Replica ID Baked into the DXL

A cross-database embedded view on a form worked fine in dev, then showed 'cannot start' the moment it reached the customer's test region. Nowhere in Designer's embedded-view UI is there a field to change the source database. Export the form to DXL and the reason shows up: the embeddedview element pins its source by the source database's replica ID — change environments and that ID no longer resolves. This is a field report: how to diagnose it, how to swap it in bulk with a NotesDXLExporter/Importer agent, and the faster way I found afterward — editing the DXL directly in Designer.

Java's NotesException: .id, .text, and try/catch/finally

LotusScript error handling is On Error Goto, Err.Number, Resume. In Java, nearly every lotus.domino method throws a checked NotesException — the compiler forces you to handle it — and it carries .id (the Notes error code) and .text (the message). This piece covers Java exception handling: NotesException's fields, using .id against NotesError constants for targeted handling, and the rule that ties this whole Java data-layer series together — recycle belongs in finally, so it still runs when something throws.

Looping a DocumentCollection in Java: Get the Next One First, Then recycle This One

In LotusScript you loop a DocumentCollection with Set doc = coll.GetNextDocument(doc) and never think about memory. In Java the same loop over tens of thousands of documents exhausts the agent's memory — unless you recycle each one inside the loop, in an order you can't get wrong: fetch the next document using the current one, then recycle the current one. This piece covers the correct Java iteration idiom: DocumentCollection's getFirstDocument/getNextDocument, the isValid deletion-stub check, when to switch to the leaner ViewNavigator, and the recycle ordering LotusScript never makes you think about.

Why Can't You Just Use java.util.Date for Notes Dates in Java?

To work with a Notes date in Java you can't just use java.util.Date — there's a lotus.domino.DateTime in the way. It's a heavyweight back-end object with a handle behind it, so it leaks memory in a loop if you don't recycle it; it stores dates as strings and throws on bad input; and toJavaDate() is the bridge that converts it into Java's own date type so you can reach java.time. This piece covers how Java's DateTime is created, read, and written, how it crosses into Java's time world, and the recycle burden LotusScript doesn't carry over.

Reading and Writing Notes Items in Java: getItemValue Hands You a Vector, Not the Array You Know

In LotusScript, doc.GetItemValue returns a Variant array and you loop over it without a second thought. In Java, the same call returns a java.util.Vector — you have to know the element type, a missing item comes back empty instead of throwing, and if it holds DateTime objects it leaks memory. This piece covers reading and writing items on the Java Document: getItemValue and the typed getters and their missing-item behavior, what Java types replaceItemValue accepts and how it auto-creates an item, why appendItemValue quietly makes duplicate items, and three instincts LotusScript won't carry over.