Scripture, for code.

REST API

The Logos77 API returns Bible passages as JSON. Because scripture does not change, responses are cached at the edge and served in milliseconds from anywhere in the world. Every response includes a deep link back into the reader, so any quote you serve can always be opened in full context.

Base URL

https://www.logos77.com/api

Getting started

Every endpoint accepts an optional lang parameter (defaults to English KJV). Here is a first verse.

curl "https://www.logos77.com/api/passage?lang=en&book=John&chapter=3&verse=16"

const res = await fetch("https://www.logos77.com/api/passage?lang=en&book=John&chapter=3&verse=16");
const data = await res.json();
console.log(data.verses[0].text);

Response

{
  "reference": "John 3:16",
  "lang": "en",
  "lang_label": "English (KJV)",
  "book": "John",
  "chapter": 3,
  "verses": [
    { "verse": 16, "text": "For God so loved the world, that he gave his only begotten Son..." }
  ],
  "deep_link": "https://logos77.com/#John-3-16",
  "total_verses_in_chapter": 36
}

Endpoints

Eight endpoints, each following the same response shape. All return JSON and honor Cache-Control.

curl "https://www.logos77.com/api/passage?lang=fr&book=Jean&chapter=3&verse=16-18"

curl "https://www.logos77.com/api/votd?lang=en"

curl "https://www.logos77.com/api/random?lang=ta"

curl "https://www.logos77.com/api/search?q=love&lang=en&limit=5"

curl "https://www.logos77.com/api/through"

curl "https://www.logos77.com/api/books?lang=ta"

curl "https://www.logos77.com/api/languages"

curl "https://www.logos77.com/api/groups"

Reading the whole Bible (chained requests)

Omit from to start at the first verse, and omit to to read to the end — a bare GET /api/through covers the entire canon (Genesis 1:1 to Revelation 22:21 in KJV). A whole Bible never fits in one response (each slice is capped at 4096 verses to stay under platform limits), so you walk it with next_url:

let url = 'https://www.logos77.com/api/through'; // from/to omitted => the whole Bible
for (;;) {
  const r = await fetch(url);
  if (!r.ok) { await new Promise((s) => setTimeout(s, 750)); continue; } // re-issue the same URL — deterministic
  const s = await r.json();
  s.verses.forEach((v, k) => { if (v.index !== s.from_index + k) throw new Error('discontinuity'); }); // optional contiguity check
  if (!s.truncated || !s.next_url) break; // else done
  url = s.next_url; // self-contained: lang, integer from/to, and limit
}

The chain is failsafe by construction:

• Every call is stateless and pure — (lang, from, to, limit) fully determines the slice, and responses are cached immutable at the edge, so a dropped request can be re-issued with an identical result.
• next_url/prev_url are self-contained, so you can resume from the last URL at any time and retries are identical.
• Slices align on integer bounds, so changing limit mid-walk never gaps or overlaps.
• Stop exactly when truncated is false. A whole Bible is at most 8 requests in every translation.

Indexes are stable within a deployment but can shift if verse data is revised. To resume at a point in a way that survives that, anchor on a verse's reference instead of its index: from_after=<reference of your last received verse> starts strictly after that verse. If a stale index ever returns a gap, re-anchor with from_after rather than restarting — at most one verse is re-read. A full restart of the remaining range is only needed if the reference itself no longer resolves (a book renamed or removed). For the canonical book names, see GET /api/books?lang=<lang>.

Reading plans (book groups)

GET /api/groups provides the traditional, overlapping book groupings so you can build a reading plan without hand-listing ranges. Group membership is non-exclusive — the same book may belong to several groups (e.g. Ephesians is in Paul's Letters and in Paul's Prison Letters).

curl "https://www.logos77.com/api/groups?lang=en"

Read one continuous group in a single loop segment by passing its tag, label, or alias to /api/through:

curl "https://www.logos77.com/api/through?group=Torah&limit=5"

• group is mutually exclusive with from/from_after/to — combining them returns a 400.
• Only continuous groups read this way. Non-contiguous groups (e.g. the Johannine corpus: John, 1–3 John, Revelation) report contiguous: false and must be read book by book.
• The response echoes the resolved group as group: { tag, label } — useful when the request used an alias.
• Group tags & labels are language-independent (OT_LAW = the Law = Torah in every translation); only the book names inside are localized.

Groups are additive to /api/books — call /api/books for the canonical 66-book ordering and /api/groups for the reading-plan layers on top. See the full Canonical Schema table at the bottom of this page for every group= tag, label, and alias you can use.

Languages

The lang parameter selects the translation. Note: book names are in the native language of each translation. For example, John is John in KJV, Jean in Martin, and Johannes in Luther. Fetch GET /api/books?lang=<lang> to list the 66 canonical native names, or GET /api/languages to enumerate every translation with its script properties.

Non-Latin scripts & embedded / low-memory / small-display clients

Every response is UTF-8 JSON (Content-Type: application/json; charset=utf-8), has no BOM, and is uncompressed unless the client asks for it — send Accept-Encoding: identity on microcontrollers and never request gzip unless you can decompress. This holds across every transport we expose: REST, MCP, and immutable-cached verses. The guidance below applies to any display (LCD, OLED, TFT, LED matrix, e-ink, segment displays) and any controller (ESP32/Arduino, Raspberry Pi Pico, STM32, …).

Glyph ≠ byte

UTF-8 encodes one code point in 1–4 bytes. Your renderer must group bytes into code points before drawing:

• Latin/Cyrillic map closely to one byte per character. Non-Latin does not: Tamil and Han are three bytes per glyph, Arabic two plus contextual shaping.
• Glyph ≠ byte — a Tamil verse is roughly 3 bytes per character; fixed char[] buffers and byte-offset slicing truncate mid-character and produce mojibake.
• RTL — ar must be laid out right-to-left.
• Combining marks — my, ta, ar use vowel signs and diacritics that attach to (or appear before) the base letter; render them as a unit, not as glyphs on separate advances.
• Every deep_link is pure ASCII — non-Latin book names are percent-encoded (https://ta.logos77.com/#%E0%AE%86…-10-15); the reader decodes fragments at launch.

Rendering on small displays

• Bitmap displays (LCD/OLED/TFT/e-ink) need a font that actually contains the script's code points (e.g. an LVGL or Adafruit-GFX font converted from a Unicode TTF covering Tamil, Arabic, Han, or Myanmar). Without such a font, glyphs render as boxes/blank — a rendering failure, not a data failure.
• LED matrices, seven-segment, and ASCII character displays generally cannot render non-Latin — fall back to a romanized or reference label.
• e-ink: same font rules; prefer full refresh and text wrapping over partial updates.
• Test your pipeline with each translation's sample from GET /api/languages (or the script block in /api/books) — a fixed first-verse string for verifying decoding and font coverage before processing real requests.

Minimal UTF-8 → code point

Decode bytes to code points before any layout or rendering work. Sketch in C:

uint32_t utf8_next(const uint8_t **p, const uint8_t *end) {
  uint8_t b = *(*p)++;
  uint32_t cp = b;
  int extra = 0;
  if (b >= 0xF0) { cp = b & 0x07; extra = 3; }
  else if (b >= 0xE0) { cp = b & 0x0F; extra = 2; }
  else if (b >= 0xC0) { cp = b & 0x1F; extra = 1; }
  for (int i = 0; i < extra && *p < end; i++) cp = (cp << 6) | (**p++ & 0x3F);
  return cp; // code point; look this up in your font (glyph != byte)
}

If text comes back wrong or blank after correct decoding, it is a font/rendering problem on the device — the bytes on the wire are standard UTF-8.

Limits & caching

This API runs on a free tier, so it is designed to be extremely cache-friendly and self-limiting.

• No API key, no rate limit, no authentication.
• Passage, Verse-of-the-Day, Through-the-Bible, Book-list, Group-list, and Language-list responses are cached for a year at the edge. Once warm, they cost nothing to serve from anywhere.
• Search is cached for one day.
• Random is not cached, so each call returns something new.
• An OpenAPI specification is available for tooling.

MCP server

Logos77 also speaks the Model Context Protocol, so AI coding assistants (Claude, Cursor, others) can read scripture directly. It is a public, stateless, read-only server — no API key required.

Endpoint

https://www.logos77.com/mcp

Protocol: MCP Streamable HTTP. Transport over JSON-RPC 2.0.

Tools

Connect

Point your MCP client at the endpoint above:

{
  "mcpServers": {
    "logos77": {
      "url": "https://www.logos77.com/mcp"
    }
  }
}

Every tool returns each verse with a canonical deep link back into the reader, e.g. https://logos77.com/#John-3-16, so any verse an assistant cites can always be opened in full context.