---
title: "Get Sections"
method: GET
path: "/sections"
tags: ["sections"]
---

# Get Sections

`GET /sections`

## Request

- Base URL: `https://api.3gppscout.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.3gppscout.com/sections`
- Auth: none declared

Fetch the text of one clause of a 3GPP document, with its citation line and official 3GPP link.

Use this after search_text identifies a relevant section.

**Excerpt limit:** each call returns one clause and at most 2,000 words of spec text, shared across all
versions in the response. A longer clause is cut with `truncated=true`, `truncation_reason="word_limit"`,
`returned_words`, `total_words` and `limit_words`; read the rest at `official_url`. Every result has a
`citation` to quote with the text.

**Section number formats supported:**
- Numeric: `5.3.5`, `6.3.2`, `16.14.3.2.3`
- Trailing-letter (release-introduced): `5.3.1a`
- Annexes: `A.1`, `B.2.3` (uppercase letter prefix, dot-delimited)

**Empty result, not an error:** If no section matches, this returns an empty list (HTTP 200), not a 404. Common reasons for an empty result: the section number is invalid for that doc, the doc isn't indexed yet, or your spelling differs from the spec. The response then carries `X-Scout-Section-Status` (`section_not_found` or `document_not_found`) and `X-Scout-Nearest-Sections` (comma-separated existing clause numbers closest to the one asked for, e.g. `6.2K,6.2K.1,6.2J`); MCP tool calls get the same suggestions as an error message. Use `/sections/toc?doc_number=...` to list all valid sections for a document.

**prefix=true** returns the requested clause with text plus its sub-clauses (5.3.1, 5.3.1.1, 5.3.2, ...) as
numbers and titles only (`truncation_reason="one_clause_per_call"`). Call again with a sub-clause number to read it.

**Dates for prior art:** every result has `provenance`: when that version was uploaded to the 3GPP archive
(UTC) and the TSG plenary it was approved at, with source links. The dates are per version, not per clause.
`available_before` keeps only versions uploaded before a date; with `latest=true` it returns the newest such
version, e.g. what the spec said before a patent's priority date among the indexed versions.

## Query parameters

- `section_number` string, required: Section number to look up. Numeric ('5.3.5', '6.3.2'), trailing-letter ('5.3.1a'), or 3GPP annex ('A.1', 'B.2.3') identifiers are all supported. Use the same dot-delimited numbering as it appears in the spec; case-sensitive (annex letters are uppercase).
- `doc_number` string, required: Document number, e.g. '38.331' (NR RRC), '23.501' (system architecture), '38.300' (NR overview). Required — section numbers like '5.1' exist in hundreds of unrelated documents. Use the numeric format without the 'TS'/'TR' prefix.
- `version` string, nullable: Specific document version, e.g. '19.1.0'. Usually not needed — use release instead.
- `release` string, nullable: 3GPP release, e.g. 'Rel-19'. Omit to return all indexed versions of the document.
- `prefix` boolean: If true, also list sub-sections. E.g. '5.3' returns 5.3 with text plus 5.3.1, 5.3.1.1, 5.3.2, etc. as numbers and titles only (API and MCP return one clause of text per call). Also works for annex prefixes: 'A' with prefix=true lists A, A.1, A.2.3, etc.
- `latest` boolean: If true, return one version only: the given version, else the newest version of the given release, else the newest indexed version. Each result then has latest_version and latest_release; an older result also has same_text_as_latest, whether the newest version's same section has the same text (null when the newest version lacks it). When the clause has a different title in another indexed version, other_version_titles names it (with that version's text when short) and other_version_note says so.
- `available_before` string, date, nullable: Only versions uploaded to the 3GPP archive before this date (YYYY-MM-DD; before 00:00 UTC, so the day itself is excluded), e.g. a patent application's priority date. A version whose upload time is unknown is left out. Usually one version per release of each spec is indexed (the newest in that release, Rel-15 onward), so a release appears only if that version predates the cutoff; older versions are in the 3GPP archive but not searchable here. With latest=true and no version, returns the newest version uploaded before the date.

## Response `200`

Successful Response

- SectionResult[]
  - `doc_number` string, required
  - `doc_type` string, nullable: 'TS' (Technical Specification) or 'TR' (Technical Report), from the stored document type.
  - `version` string, required
  - `release` string, required
  - `section_number` string, required
  - `section_title` string, nullable
  - `heading_level` integer, nullable
  - `full_text` string
  - `token_count` integer, nullable
  - `fragment_count` integer, nullable
  - `parent_section_number` string, nullable
  - `latest_version` string, nullable
  - `latest_release` string, nullable
  - `same_text_as_latest` boolean, nullable
  - `other_version_titles` OtherVersionTitle[], nullable: With latest=true: this clause's title in other indexed versions, where it differs (the clause was rewritten or replaced). Each has the other version's full_text and citation when that text is short.
    - `version` string, required
    - `release` string
    - `section_title` string, required
    - `full_text` string, nullable: That version's text, when it is at most 400 tokens (and, for REST and MCP, fits the call's word limit).
    - `citation` string, nullable
  - `other_version_note` string, nullable: A one-sentence note when other_version_titles is present.
  - `citation` string, nullable
  - `official_url` string, nullable
  - `truncated` boolean
  - `truncation_reason` string, nullable: 'word_limit' (clause longer than limit_words) or 'one_clause_per_call' (a sub-clause from prefix=true, text withheld).
  - `returned_words` integer, nullable
  - `total_words` integer, nullable
  - `limit_words` integer, nullable
  - `next_step` string, nullable
  - `provenance` SpecProvenance: When this spec version reached the public 3GPP archive, and the TSG plenary it came from. Every value comes from the 3GPP FTP server: archive and dated plenary folder listings, 3GPP's lists of specifications arising from each TSG round, and the 3GPP change request database. Unknown values stay null.
    - `statement` string, nullable: The known facts as plain sentences, ready to quote, e.g. 'Uploaded to the 3GPP archive on 2026-09-24 at 16:47 UTC. Approved at TSG SA #113 (2026-09-15 to 2026-09-18).' It says 'uploaded to the 3GPP archive' and 'approved at', never 'published': no source states a publication date.
    - `archive_uploaded_at` string, nullable: When this version's zip was uploaded to the 3GPP archive (ISO 8601, UTC), as the 3GPP FTP folder listing at archive_url shows it. If 3GPP re-uploaded the file, the earliest time seen. Null when not found; see unknown_reasons.
    - `archive_url` string, nullable: The zip on the 3GPP FTP server whose folder listing gives archive_uploaded_at; open its folder to verify the time.
    - `archive_date_source` string, nullable: 'ftp_archive_listing' (the spec's folder under /ftp/Specs/archive/) or 'ftp_plenary_folder_listing' (a dated plenary folder that showed an earlier time).
    - `plenary_batch` string, nullable: YYYY-MM of the plenary round whose batch of specifications includes this version (3GPP's dated folders, /ftp/Specs/YYYY-MM/).
    - `plenary_batch_source` string, nullable: 'tsg_spec_list' (stated in 3GPP's list of specifications arising from that TSG round), 'tsg_meeting_start' (the month the plenary in tsg_meeting started) or 'ftp_plenary_folder' (the earliest dated folder holding the zip).
    - `tsg_meeting` string, nullable: Plenary meeting ID: 'SP-113' (TSG SA #113), 'RP-109' (TSG RAN), 'CP-110' (TSG CT); a trailing '-e' marks an electronic meeting.
    - `tsg_meeting_name` string, nullable: The meeting as 3GPP names it, e.g. 'TSG SA #113'.
    - `tsg_meeting_relation` string, nullable: 'approved': change requests approved at this meeting created this version (3GPP CR database). 'arising_from': 3GPP lists this version among the specifications arising from this meeting. 'presented': a draft (below version 3.0.0) presented to this meeting.
    - `tsg_meeting_start` string, date, nullable: First day of the plenary meeting.
    - `tsg_meeting_end` string, date, nullable: Last day of the plenary meeting.
    - `tsg_meeting_source` string, nullable: 'cr_database' (3GPP change request database export) or 'tsg_spec_list' (3GPP's list of specifications arising from that TSG round).
    - `tsg_meeting_source_url` string, nullable: The 3GPP file that names the meeting.
    - `unknown_reasons` object, nullable: Why a field is null, by field name. archive_uploaded_at: 'not_in_archive_listing'. tsg_meeting: 'before_tsg_lists_no_approved_cr' (uploaded before March 2023, when 3GPP's per-round spec lists start, and created by no approved change request, e.g. a release upgrade), 'draft_not_listed', or 'not_in_cr_database_or_tsg_lists'. Nothing is guessed.
    - `notes` string, nullable: Anything a reviewer should know, e.g. the file was re-uploaded or two sources name different meetings.

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/3gppscout/apis/3gpp-scout-api.md) · [All operations](https://skmtc.dev/3gppscout/apis/3gpp-scout-api/llms.txt) · [OpenAPI document](https://skmtc.dev/3gppscout/apis/3gpp-scout-api/revisions/60bd6896e5b9?raw)