Feature Request: Expose available list condition types via API (GET /lists/condition_options)

[Benechi]

Problem

There is no endpoint to discover what filter condition types, comparison operators, or settings options are valid when building list rules. The schema exists in the UI but is entirely undocumented and inaccessible via the API.

Proposed Solution

Add a read-only GET /lists/condition_options (or /list_rule_schema) endpoint returning all available definition_class types, their supported comparison operators, and valid settings structures.

Why It Matters

• Building tools that programmatically create or validate lists is impossible without knowing what filter conditions are valid
• When PCO adds new filter types (new app integrations, new field types), there is no way to discover them via API — they can only be noticed manually in the UI
• This is a prerequisite for AI-assisted list creation — a model needs to know what's structurally possible before it can suggest or construct valid filter logic. PCO's own beta AI list builder in the UI is constrained by the same missing schema exposure on the client side

Current Workaround

Reverse-engineer the schema by reading conditions off existing lists — which only surfaces types already in use, misses comparisons not yet tried, reveals nothing about valid settings structures, and is completely blind to new filter types added in future PCO updates.

[github-actions]

Potentially Related Issues

I found some existing issues that may be related to this one. Please check if any of them address your question before waiting for a response:

🟣 #1435 — CRUD Endpoints for Lists and List Rules People API (Closed)

Summary: Requested full CRUD endpoints for Lists and List Rules in the People API to programmatically create and manage list filter criteria. Directly related to the new issue as both concern API access to the list filtering system—this issue focused on creation/modification while the new issue focuses on discovering what filter types and operators are valid.

Key discussion points:

• User wanted to avoid manually creating list variations in the UI or replicating the entire Planning Center database to run filtered queries
• Noted that the list rules engine is one of Planning Center's strongest features but limited API access reduces its utility for automation and reporting
• Existing People search/filter endpoints can't replicate the complex rule combinations available in the Lists UI (e.g., attendance patterns combined with giving history)

Resolution: Closed without implementation. Planning Center acknowledged the suggestion and noted it for future consideration but indicated there are no current plans to create an API around lists at this time. This suggests the new issue's request for even read-only schema exposure may face similar prioritization challenges.

🟢 #1438 — Feature Request: Support nested includes for list rule conditions ?include=rules.conditions (Open)

Summary: Requested nested includes support (e.g., ?include=rules.conditions) to retrieve full list filter logic in a single API call instead of requiring separate requests per rule per list. Related to the new issue as both deal with improving API access to list condition data, though this focuses on retrieval efficiency while the new issue focuses on schema discovery.

Key discussion points:

• Current approach requires ~150 sequential API calls to audit all list filter logic across an organization
• Without nested includes, each list requires fetching rules, then separate calls for each rule's conditions
• Makes real-time auditing impractical and burns through rate limits quickly

🟣 #1424 — Expose Membership type field options (Closed)

Summary: Requested exposure of Membership Type field options through the API to avoid hardcoding customizable values. Demonstrates a successful precedent where Planning Center made a private endpoint public after a feature request, which is directly analogous to what the new issue is requesting for list condition options.

Key discussion points:

• User needed to discover valid field options programmatically rather than hardcoding default values that could break when organizations customize their settings
• Planning Center revealed the endpoint already existed privately but was undocumented
• Team committed to making it part of the stable public API

Resolution: Successfully resolved. Planning Center made the private endpoint public and documented it at https://api.planningcenteronline.com/docs/apps/people/versions/2025-11-10/vertices/membership_type. This provides a clear precedent that Planning Center is willing to expose configuration/schema endpoints when there's a valid use case, which strengthens the argument for the new issue's request for list condition schema exposure.

---

This comment was generated automatically. If none of these match your issue, no action is needed — a team member will review your issue soon.

[usborn116]

Thanks for this feature request @Benechi! It would be pretty neat to be able to get these available filters/conditions programmatically. I'll add this to our board as a feature request!