The fields your community actually runs on
Every community needs different information from its members. A developer community needs a GitHub handle. A healthcare community needs a specialty. A SaaS community needs a company name. WordPress gives you a bio and a website URL and nothing else, so all of that context ends up scattered in signatures and forum posts, or nowhere at all. Custom Fields lets you define exactly the structured information that makes a member useful and findable, and attach it to the profile where it belongs.
You create each field with a label, a type, and a description, and Jetonomy generates a stable field key you can use in the API. There are nine types to choose from, covering short text, long text, numbers, email, URLs, single-choice dropdowns and radio buttons, a yes/no checkbox, and a calendar date. For select and radio fields you type the options right in the editor, one per line, so building a country picker or a role selector takes seconds.
Control what is required and who can see it
Not every field should be optional, and not every field should be public. Custom Fields gives you both controls per field. Mark a field required and members cannot save their profile until it is filled in, with a red asterisk to signal it and validation that runs on save, so your profiles stay complete instead of half-empty.
Visibility works the same way, one setting per field. Public fields show to anyone, including logged-out visitors. Members-only fields show to logged-in members. Private fields stay between the member and your admins, editable by the member but hidden from their public profile. That means you can collect sensitive detail without ever exposing it, while still surfacing the fields that help members connect.
Fields that travel with your data
Custom fields are not trapped in the profile UI. Once a field is configured, its value rides along automatically in the REST API, embedded in the custom_fields object on the users and posts endpoints and their list responses, subject to the field’s visibility. You do not register a read endpoint per field; the value is simply there on the object it belongs to.
Writing is just as direct. Send a custom_fields object to a user to update several fields at once, or post a single value to the custom-field-values endpoint for a lightweight partial update, the same path the edit-profile form uses. Members can only change their own fields and admins can change anyone’s. If you are coming from an older release, update both the free and Pro plugins to 1.4.1 or later so every configured field appears in the API automatically.