> ## Documentation Index > Fetch the complete documentation index at: https://help.reevo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Schema & Resources > Introspect the Public API v2 data model — objects, typed attributes, capability flags, and direct vs junction relationships — with GET /_schema/{record_type}. **Restricted access.** Public API v2 is currently available only to allowlisted organizations. Requests from workspaces that have not been enabled are rejected. Contact your Reevo representative to have your organization added to the allowlist. # Schema & Resources Public API v2 treats standard objects and custom objects the same way: every object is a record type with typed **attributes** and **relationships**. Rather than hard-coding what each record type supports, a generic client discovers it at runtime from the schema endpoints. * `GET /api/v2/public/_schema/{record_type}` is the authoritative description of one record type — what you can read, write, filter, and sort, plus how it relates to other record types. * `GET /api/v2/public/_organization_schema_summary` lists every object type available to the workspace, including custom objects. Call `_schema` before writing or filtering a field rather than guessing an `api_name` or a capability. Field names are already post-rename, so what `_schema` returns is exactly what the read, write, filter, and relationship endpoints accept. ## Listing object types `GET /api/v2/public/_organization_schema_summary` returns a lightweight list of the object types in the workspace. Each entry carries the object's `api_name`, `display_name`, labels, and flags such as `is_custom`, `is_junction`, and `supports_custom_fields`. Use it to enumerate record types, then expand any one into a full descriptor with `GET /api/v2/public/_schema/{record_type}`. ## Attributes Each entry in `attributes` describes one field. The two pieces you use most are the field's `api_name` (the name to send and read back) and its value type, carried in `type_info` as a `value_type` discriminator. See [Value Types](/Public-API-v2/Value-Types/Overview) for the full catalog of value types and their read, write, and filter shapes. Alongside the type, each attribute advertises capability flags: | Flag | Meaning | | ----------------------- | -------------------------------------------------- | | `is_creatable` | The field can be set in a create request. | | `is_updatable` | The field can be set in a `PATCH` request. | | `is_required_on_create` | The field must be supplied when creating a record. | | `is_filterable` | The field can be used in `_query` filters. | | `is_sortable` | The field can be used to sort `_query` results. | A **read-only** field is one where `is_creatable` and `is_updatable` are both `false` — it appears on reads but has no writable path (for example, computed or system fields such as `created_at`). Consult `_schema` before writing or filtering: attempting to write a non-creatable field, or filter a non-filterable one, is rejected rather than silently ignored. ## Relationships — direct vs junction Relationships connect records without embedding every related record in the parent response. Each entry in `relationships` has an `api_name`, a `display_name`, a `related_object_api_name` (the record type on the other end), and a `type` that is either `direct` or `junction`: * **`direct`** — a single outbound reference, such as a foreign key or an owned association. There is no edge record between the two sides, so a direct relationship has no per-edge attributes. * **`junction`** — a many-to-many link mediated by a junction object (named in `junction_object_api_name`) that carries **per-edge attributes** of its own, such as a `role` or an `is_primary` flag. To tell them apart from `_schema`, read the relationship's `type`. Junction relationships are the only ones that carry edge attributes, and the only ones that name their edge object in `junction_object_api_name`. Direct relationships have nothing to patch on the edge itself. Relationships also carry `is_creatable` and `is_updatable` flags that report whether your key may add or change edges, plus `is_array` (whether the relationship holds many targets) and `is_custom`. ## Relationship CRUD Relationship edges are managed through parent-scoped endpoints, not by addressing junction records directly: ```text theme={null} /api/v2/public/{record_type}/{record_id}/relationship/{api_name} ``` * **List edges** — `GET` returns the current targets and pagination metadata. * **Add an edge** — `POST` links a target by `related_record_id` or by a unique-field `related_record_match`. * **Update an edge** — `PATCH` on `.../relationship/{api_name}/{target_id}` applies **only to junction relationships**, because only they have per-edge attributes to change. There is no edge to patch on a direct relationship. * **Remove an edge** — `DELETE` on `.../relationship/{api_name}/{target_id}` unlinks the target. See [Manage Relationships](/Public-API-v2/Guides/Manage-Relationships) for the full workflow, including cardinality, `is_primary` semantics, match keys, and error recovery. ## Example: `GET /_schema/{record_type}` A trimmed response for `GET /api/v2/public/_schema/contact` shows a couple of attributes with their flags, one direct relationship, and one junction relationship: ```json theme={null} { "api_name": "contact", "display_name": "Contact", "is_custom": false, "is_junction": false, "singular_label": "Contact", "plural_label": "Contacts", "supports_custom_fields": true, "attributes": [ { "api_name": "first_name", "display_name": "First Name", "is_creatable": true, "is_updatable": true, "is_required_on_create": false, "is_sortable": true, "is_filterable": true, "type_info": { "value_type": "string", "is_array": false } }, { "api_name": "primary_email", "display_name": "Primary Email", "is_creatable": true, "is_updatable": true, "is_required_on_create": true, "is_unique": true, "is_sortable": false, "is_filterable": true, "type_info": { "value_type": "email", "is_array": false } }, { "api_name": "created_at", "display_name": "Created At", "is_creatable": false, "is_updatable": false, "is_sortable": true, "is_filterable": true, "type_info": { "value_type": "timestamp", "is_array": false } } ], "relationships": [ { "api_name": "reports_to", "display_name": "Reports To", "related_object_api_name": "contact", "type": "direct", "is_array": false, "is_custom": false, "is_creatable": true, "is_updatable": true }, { "api_name": "accounts", "display_name": "Accounts", "related_object_api_name": "account", "related_object_relationship_api_name": "contacts", "type": "junction", "junction_object_api_name": "contact_account_role", "is_array": true, "is_custom": false, "is_creatable": true, "is_updatable": true } ] } ``` Here `created_at` is read-only (`is_creatable` and `is_updatable` are both `false`), `primary_email` is required on create and unique, `reports_to` is a direct reference with no edge to patch, and `accounts` is a junction whose `contact_account_role` edge carries per-edge attributes you can change with a per-edge `PATCH`. ## Where to go next * [Supported Resources](/Public-API-v2/Supported-Resources): which actions each record type supports, plus the infrastructure endpoints. * [Objects](/Public-API-v2/Objects/Overview): the record envelope, reads, writes, queries, and relationships. * [Value Types](/Public-API-v2/Value-Types/Overview): the catalog of value types and per-type read, write, and filter behavior. * [Manage Relationships](/Public-API-v2/Guides/Manage-Relationships): the full relationship-edge workflow.