> ## Documentation Index
> Fetch the complete documentation index at: https://docs.thefaithapp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Discipleship API availability

> Understand the current public integration boundary for TheFaithApp Discipleship.

# Discipleship API availability

Discipleship is available in TheFaithApp's first-party admin dashboard and
member apps. It is **not currently included in the supported public partner
`v1` API**.

That means a partner app cannot yet use the public API to load pathways,
submit quizzes, update progress, manage mentorship, or participate in private
formation practices.

<Warning>
  Do not call admin dashboard routes or internal mobile routes from a partner
  app. They use first-party authentication, permissions, and privacy rules and
  may change without a partner API version transition.
</Warning>

## Supported today

| Need                                                | Recommended approach                                         |
| --------------------------------------------------- | ------------------------------------------------------------ |
| Church staff create and manage Discipleship content | Use the TheFaithApp admin dashboard                          |
| Members take classes and use formation practices    | Use the TheFaithApp member app                               |
| A person verifies a completion certificate          | Open the public verification link printed on the certificate |
| A partner app needs supported TheFaithApp data      | Use only endpoints listed in this `v1` API reference         |

Certificate verification links are public product links. A person does not
need dashboard access to verify a certificate. This does not make the wider
Discipleship data model a public API.

## Why the boundary matters

Discipleship includes unusually sensitive data: private journals, spiritual
goals, Examen responses, fast choices, Rule of Life commitments, and mentor
check-ins. A public contract needs explicit scopes, consent behavior, owner-only
authorization, retention guarantees, and safe error responses before it can be
offered to partners.

## What not to do

* Do not copy a bearer token or cookie from the first-party apps.
* Do not scrape the admin dashboard or mobile responses.
* Do not store correct quiz answers in a client bundle.
* Do not recreate staff access to private member formation data.
* Do not treat an internal route path as a stable API contract.

## Prepare for a future integration

You can design your application so a future supported API is easier to adopt:

1. Use [Hosted Auth](/api-reference/hosted-auth) for member identity where your
   current integration already uses supported `v1` endpoints.
2. Keep church and member identifiers opaque; do not derive meaning from them.
3. Separate shared learning progress from private spiritual reflection in your
   own data model.
4. Build explicit consent and revocation into any feature that shares formation
   data.
5. Subscribe to the [Changelog](/changelog) for new public API capabilities.

<Note>
  Hosted Auth does not grant access to Discipleship by itself. It is listed
  here only as the supported identity pattern for existing partner APIs.
</Note>

## Requesting access

If Discipleship integration is important to your church or product, contact
[support@thefaithapp.com](mailto:support@thefaithapp.com) with the member
workflow, data you need, and how you plan to protect private formation data.
That information helps shape a safe future public contract.