📘 ScriptureFlow Developer Docs

ScriptureFlow API Product Overview — Public

Public API integration guidance based on approved ScriptureFlow documentation.

← Back to Developer Docs home Open API Preview

ScriptureFlow API Product Overview — Public

Purpose

This document gives developers, ministries, educators, automation builders, and product teams a clear public overview of ScriptureFlow.

It explains what ScriptureFlow is, what it is designed to help people build, why the API exists, and how developers should think about using it.

What ScriptureFlow Is

ScriptureFlow is a Scripture access API and data infrastructure layer.

It is not primarily a Bible reading app.

A Bible reading app is an end-user product. ScriptureFlow is closer to the foundation beneath those products. It gives developers structured access to Scripture data so they can build applications, workflows, tools, and ministry resources without having to rebuild the Scripture data layer from scratch.

A simple way to understand it:


ScriptureFlow helps builders retrieve structured Scripture data through a public API.

Developers can use ScriptureFlow to request passages, inspect available translations, build translation selectors, create study tools, automate Scripture retrieval, and support multilingual Bible-centered experiences.

What ScriptureFlow Is Not

ScriptureFlow should not be confused with a finished devotional app, sermon platform, Bible reader, or content generator.

Those kinds of products can be built on top of ScriptureFlow, but they are not the API itself.

ScriptureFlow is not meant to replace:

  • Bible reading apps
  • Church websites
  • Sermon platforms
  • Devotional publishing tools
  • Study guide platforms
  • Ministry content systems

Instead, ScriptureFlow can help power those kinds of tools.

Why ScriptureFlow Exists

Many developers want to build Bible-powered tools, but Scripture data can be difficult to work with.

Common challenges include:

  • Finding structured Scripture data
  • Working with multiple translations
  • Supporting different languages
  • Handling book/chapter/verse references
  • Building reliable lookup behavior
  • Avoiding one-off hardcoded solutions
  • Preparing data for apps, automations, and AI-assisted workflows

ScriptureFlow exists to make that work easier.

The goal is to provide a clean, public API layer that lets developers focus on building useful products instead of first having to solve the Scripture data access problem.

Who ScriptureFlow Is For

ScriptureFlow is useful for several kinds of builders.

App Developers

Developers can use ScriptureFlow to add Scripture lookup to web apps, mobile apps, dashboards, study tools, and custom ministry software.

Automation Builders

Automation builders can use ScriptureFlow in tools like n8n, Make, Zapier-style workflows, custom scripts, and AI-assisted content pipelines.

Ministries and Churches

Ministries can use ScriptureFlow to support sermon preparation, teaching resources, devotional workflows, discipleship tools, and Scripture-driven digital experiences.

Educators and Bible Teachers

Educators can use ScriptureFlow to build study aids, classroom tools, reading plans, reference lookup tools, and multilingual teaching resources.

Product Teams

Product teams can use ScriptureFlow as a Scripture access layer inside larger applications where Bible text needs to be retrieved, displayed, compared, or inserted into a workflow.

What Developers Can Build

ScriptureFlow can support many types of projects.

Examples include:

  • Bible verse lookup widgets
  • Sermon preparation tools
  • Devotional generation workflows
  • Scripture reference checkers
  • Bible study dashboards
  • Teaching slide generators
  • Multilingual Scripture comparison tools
  • Chatbots that retrieve Bible passages
  • Daily verse automations
  • Ministry email workflows
  • Discipleship resource builders
  • Bible-powered AI tools
  • Translation-aware search or study experiences

The public API is intentionally practical. It gives builders enough structure to begin building without needing access to the private repository.

Current Public API Preview

The current public preview API is available at:


https://scriptureflow-api-preview.pages.dev

Core public resources include:


https://scriptureflow-api-preview.pages.dev/translations.json


https://scriptureflow-api-preview.pages.dev/public-catalog.json


https://scriptureflow-api-preview.pages.dev/status.json

The primary scripture lookup endpoint is:


https://scriptureflow-api-preview.pages.dev/api/verse

The current public preview is useful for testing, early integrations, documentation, and developer feedback.

Main Public Lookup Capability

The main public lookup endpoint allows developers to request a verse or same-chapter passage range.

Example single verse request:


https://scriptureflow-api-preview.pages.dev/api/verse?version=en-kjv&book=Psalm&chapter=23&verse=1

Example same-chapter passage request:


https://scriptureflow-api-preview.pages.dev/api/verse?version=en-kjv&book=Proverbs&chapter=3&verse=5&end_verse=6

Example free-text reference request:


https://scriptureflow-api-preview.pages.dev/api/verse?version=en-kjv&reference=Micah%206%3A8

The API returns JSON, making it suitable for websites, scripts, backend services, automations, and application integrations.

Version Keys Matter

ScriptureFlow uses exact version keys to identify translations.

For example, the King James Version is requested with:


en-kjv

Use:


version=en-kjv

Do not use:


version=kjv

Do not use:


version=en-KJV

Developers should check the live translation catalog before assuming a version key is available:


https://scriptureflow-api-preview.pages.dev/translations.json

This matters because ScriptureFlow is designed to support many languages and translations. Short abbreviations alone are not reliable enough for a multilingual API.

Multilingual Vision

A central part of ScriptureFlow’s purpose is multilingual Scripture access.

The Word of God should not be limited to only the major languages of the internet.

ScriptureFlow is being shaped to support:

  • Major global languages
  • African languages
  • Indigenous languages
  • Regional languages
  • Creoles
  • Diaspora languages
  • Underrepresented language communities
  • Multiple translations within a single language where available

This is one of the reasons ScriptureFlow uses catalog-driven version keys instead of relying only on familiar translation abbreviations.

The long-term goal is to make it easier for developers to build Bible-powered tools in as many languages as possible.

Why This Matters for Underrepresented Languages

Many languages are underserved by modern digital tools.

When Scripture data is difficult to access programmatically, developers are less likely to build apps, study tools, automations, or ministry resources for those language communities.

ScriptureFlow aims to lower that barrier.

That does not mean every translation can automatically be published or redistributed. Translation rights, licensing, copyright, attribution, and publication status still matter.

But the broader vision is clear: developers should be able to build Scripture-centered tools for more than just the most commercially dominant languages.

Technical Readiness vs. Publication Permission

ScriptureFlow separates technical readiness from responsible public use.

A translation may be technically structured and readable by the API pipeline while still requiring review for:

  • Copyright status
  • Licensing
  • Attribution requirements
  • Redistribution permission
  • Commercial use restrictions
  • Publication approval

Developers should use the public catalog and respect all applicable translation rights.

Technical access should never be treated as permission to ignore copyright, licensing, or attribution requirements.

Public API Boundary

The public ScriptureFlow API gives developers a supported way to use the current public Scripture access layer.

The public documentation does not include:

  • Internal architecture
  • Corpus processing details
  • Build and indexing logic
  • Deployment workflow internals
  • Private roadmap details

This boundary is intentional.

Developers should be able to use ScriptureFlow without needing access to the private repository.

Typical Developer Flow

A simple application flow looks like this:

  1. Load the translation catalog.
  2. Let the user choose a translation.
  3. Store the selected version key.
  4. Request a verse or passage from /api/verse.
  5. Display the returned Scripture text and reference.
  6. Handle errors clearly if the passage or version is unavailable.

Example:


translations.json
        ↓
User selects a version key
        ↓
Application calls /api/verse
        ↓
ScriptureFlow returns JSON
        ↓
Application displays or uses the passage

This pattern works for many use cases, from simple widgets to larger ministry platforms.

Example Use Case: Bible Study Tool

A Bible study tool could use ScriptureFlow to:

  1. Load available translations.
  2. Let a user select a translation.
  3. Let the user enter a reference such as Micah 6:8.
  4. Request that reference from /api/verse.
  5. Display the returned text.
  6. Save the reference into a lesson, note, or study plan.

This keeps the application focused on the user experience instead of requiring the developer to build a Scripture data backend first.

Example Use Case: Automation Workflow

An automation workflow could use ScriptureFlow to:

  1. Receive a verse reference from a form or spreadsheet.
  2. Send the reference to ScriptureFlow.
  3. Receive the Scripture text as JSON.
  4. Insert the passage into an email, devotional, teaching note, or content workflow.

This kind of workflow is useful for ministries, educators, writers, and content teams that repeatedly need structured Scripture retrieval.

Example Use Case: Multilingual Scripture Tool

A multilingual Scripture tool could use ScriptureFlow to:

  1. Load available translations from the catalog.
  2. Group translations by language code.
  3. Let the user choose a language or translation.
  4. Request a passage using the selected version key.
  5. Present the returned passage in the user’s chosen translation.

As ScriptureFlow grows, this pattern can help support more inclusive Bible-centered tools for communities that are often left out of mainstream technology.

What Makes ScriptureFlow Different

ScriptureFlow is not just a single-purpose endpoint.

Its public direction is shaped by several ideas:

  • Scripture data should be structured and developer-friendly.
  • Multilingual access should be treated as a first-class concern.
  • Developers should not need to rebuild the Scripture data layer for every project.
  • Public API usage should be separated from private implementation details.
  • Translation rights and publication responsibility must be respected.
  • Underrepresented languages deserve better digital infrastructure.

That combination makes ScriptureFlow a foundation for future Bible-powered products, not just a one-off lookup tool.

Current Public Limitations

The current public preview is useful, but it is still developing.

Known public limitations include:

  • Cross-chapter ranges are not currently supported as one request.
  • Version keys must match the catalog exactly.
  • Free-text reference parsing supports common reference patterns but not every possible citation style.
  • Alias and localized book-name support may vary.
  • Public behavior may evolve as ScriptureFlow moves toward formal versioned releases.
  • Translation availability may change as publication and licensing review continues.

Developers should build with graceful error handling and avoid assuming the preview API will never change.

Recommended Developer Practices

Developers should:

  • Use translations.json to discover available translations.
  • Store exact version keys from the catalog.
  • Use /api/verse for verse and same-chapter passage lookup.
  • URL-encode free-text references.
  • Handle unavailable versions and missing passages gracefully.
  • Avoid hardcoding unsupported translation abbreviations.
  • Respect copyright, licensing, and attribution requirements.
  • Keep user-facing error messages clear and helpful.
  • Watch for future updates as ScriptureFlow matures.

Public Documentation Set

The public ScriptureFlow developer documentation is expected to include:

  • API Product Overview
  • Developer Quickstart
  • Endpoint Specification
  • Example Requests
  • Supported Languages
  • Terms and Attribution

Together, these documents help developers understand what ScriptureFlow is, how to call the API, what to expect from responses, and how to build responsibly.

Next Steps

Developers who are new to ScriptureFlow should start with:

  1. Developer Quickstart
  2. Example Requests
  3. Endpoint Specification
  4. Supported Languages
  5. Terms and Attribution

The fastest way to begin is to open the translation catalog, copy a valid version key, and make a simple /api/verse request.

ScriptureFlow Developer Docs • Public API guidance.