NationBuilder has written the parameter reference that most JSON:API providers leave to the specification. Using parameters to interact with the NationBuilder API walks six conventions in order: filtering, pagination, sparse fields, sorting, sideloading and sideposting. The filter grammar is the useful part. A bare filter matches, and bracketed operators narrow it: eql for case sensitivity, prefix, suffix and match for substrings, gt, gte, lt and lte for numbers, and a not_eq against null for existence checks. Index endpoints return 20 results by default, with page size and page number as bracketed parameters and self, prev and next links in every response. Sparse fieldsets, a minus sign for descending sort, and include for related resources round out the read side.
The one caveat in the article is also its sharpest line. Filtering on a sideloaded resource, such as active memberships, “does not remove unassociated Signups from the response. Signups without an active membership will still be included in the payload.” That is a real trap: the filter shapes what is included, not who is returned, and a developer who reads the parameter as a WHERE clause will ship a bug. Sideposting is the write-side equivalent: one request creates a signup, a recruiter and two new tags, binding them with temp-id values and a method of create or update on each relationship. Nothing in the article is a marketing figure. It is a vendor describing its own query surface, and the description matches the JSON:API conventions the catalog already records for it.
The catalog holds NationBuilder across 41 API pages, and the article walks four of them. Every example is a query against the NationBuilder Signups API, the nested filter reaches into the NationBuilder Memberships API, and the sideposting payload creates records in the NationBuilder Signup Tags API while the include example pulls taggings from the NationBuilder Signup Taggings API. The agentic access profile maps 190 operations, 108 of them acting, which is a large write surface for a supporter CRM that holds donations and voter data.
The Kin Score is 65.0, strong band, with access clarity at 84.2 and discoverability at 73.2 against contract governance at 31.8. The Agent Readiness score is 37.1, agent-ready, with spec presence, OpenAPI examples, error semantics, the rate limit signal and agent skills all lit. Idempotency is unlit. Read that next to the sideposting example: a single POST that creates a signup, a recruiter and tags in one transaction, identified by client-chosen temp-ids, retried by an agent after a timeout, creates all of them twice. The article documents how to compose that request precisely. Nothing in the record documents how to make it safe to repeat.