Most section administration happens in the Console. See Sections and Section Types. A few section features do not have a Console screen, so you use the Rhythm API to get every section in your Rhythm account, see what a signed-in Portal member can read, or send several section record changes in one batch request.
Get Every Section in One Call
GET /sections/{tenantId} returns every section in your Rhythm account in one response. In these paths, {tenantId} is your account identifier. Rhythm sorts sections by saved display order, then by name.
No Filtering and No Paging
This route includes every section because it does not filter by status or Portal visibility. The response includes inactive sections, sections hidden from the Portal, and restricted sections. It also does not page results, so a Rhythm account with a very large number of sections receives them all in one response. If you are building a picker or synchronization job, filter the results yourself for active status and Portal visibility.
You can request specific fields with a fields parameter instead of receiving the whole record.
What a Portal Member Can Read
A member signed in to the Portal can list and read sections directly:
| Operation | Portal access |
|---|---|
| List sections | Allowed |
| Read one section | Allowed |
| Create a section | Refused (403) |
A Portal member’s list and read actions return the section’s whole record. That means the response includes every field, regardless of the section’s status or Portal visibility. The response also includes the welcome-email template, membership-type restriction list, and custom field values. This path does not trim the response to a smaller, member-safe set of fields.
Section types and section dues products do not have equivalent Portal operations, so a member cannot read type names or dues-product prices directly from those services. Any Portal screen that shows a section’s type or price gets that information from the feature presenting the section, not from a direct member read.
Batch Requests
Sections, section types, and section dues products each accept POST /{tenantId}/batch with {"operations": [...]}. Each entry names its kind, such as create, read, update, patch, or delete, and includes the identifier, record, or patch instructions it needs. Every operation uses the same checks as the matching single-record call, and the operations run together. The response gives a success count, an error count, and a result for each operation, so one failed record does not stop the rest.
Warning
The same identifier cannot appear twice in one batch request; a duplicate fails the whole batch. Rhythm’s documentation describes a maximum of 100 operations per batch, but the default schema does not enforce that limit. A very large batch runs every operation at once with no chunking, which can time out before it finishes.