Skip to main content
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 for the full catalog of value types and their read, write, and filter shapes. Alongside the type, each attribute advertises capability flags:
FlagMeaning
is_creatableThe field can be set in a create request.
is_updatableThe field can be set in a PATCH request.
is_required_on_createThe field must be supplied when creating a record.
is_filterableThe field can be used in _query filters.
is_sortableThe 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: 
/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 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: 
{
  "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: which actions each record type supports, plus the infrastructure endpoints.
  • Objects: the record envelope, reads, writes, queries, and relationships.
  • Value Types: the catalog of value types and per-type read, write, and filter behavior.
  • Manage Relationships: the full relationship-edge workflow.