Skip to main content

​
Core Objects

Public API v2 treats standard objects and custom objects as records with typed attributes. Every record has:
  • id: the record UUID
  • record_type: the public object name, such as contact, account, or opportunity
  • attributes: the record’s fields, rendered as typed values

​
Reading values

Read responses use value envelopes. Each envelope includes a value_type discriminator and a value. 
{
  "id": "9b4f2fb1-2a7f-4d75-8d5f-3f3f0d7f2a7a",
  "record_type": "contact",
  "attributes": {
    "first_name": {
      "value_type": "string",
      "value": "Sarah"
    },
    "stage": {
      "value_type": "contact_stage",
      "value": {
        "id": "8b8c2b1d-56c1-4b52-84f3-d00d4b8bb1ef",
        "api_name": "working",
        "display_value": "Working",
        "color": "#6966FF"
      }
    }
  }
}
Common value types include:
Value typeMeaning
string, long_text, rich_textText fields
number, percent, currencyNumeric fields
booleanTrue or false fields
timestamp, date, timeDate and time fields
email, phone_number, url, uuidFormatted scalar fields
select, contact_stage, account_stage, opportunity_stageOption or stage fields
record_referenceReference to another Reevo record
contact_email, contact_phone_number, address, account_domainCompound values

​
Writing values

Create and patch requests use an attributes object. For many fields, you can write raw values: 
{
  "attributes": {
    "first_name": "Sarah",
    "last_name": "Chen",
    "primary_email": "sarah.chen@acme.com"
  }
}
You can also write enveloped values when you want the request shape to match read responses: 
{
  "attributes": {
    "first_name": {
      "value_type": "string",
      "value": "Sarah"
    },
    "primary_email": {
      "value_type": "email",
      "value": "sarah.chen@acme.com"
    }
  }
}
Reference fields can use a direct record ID or a match object: 
{
  "attributes": {
    "owner_user_id": {
      "related_record_match": {
        "email": "owner@acme.com"
      }
    }
  }
}
On PATCH, omitted fields are left unchanged. Sending null clears a nullable field.

​
Querying records

Use POST /api/v2/<record_type>/_query to filter, sort, and paginate records. 
{
  "filters": [
    {
      "field": "primary_email",
      "operator": "eq",
      "value": "sarah.chen@acme.com"
    }
  ],
  "sort": [
    {
      "field": "created_at",
      "direction": "desc"
    }
  ],
  "limit": 50
}
Multiple top-level filters are combined with and. More complex filters can use and, or, and not groups. 
{
  "filters": [
    {
      "or": [
        {
          "field": "primary_email",
          "operator": "contains",
          "value": "@acme.com"
        },
        {
          "field": "title",
          "operator": "contains",
          "value": "founder"
        }
      ]
    }
  ]
}
Query responses include an opaque next_cursor when more results are available. Pass that cursor into the next _query request.

​
Relationships

Relationships connect records without embedding every related record in the parent response. Examples:
  • contact -> accounts
  • contact -> opportunities
  • account -> contacts
  • opportunity -> contacts
  • Custom object relationships by api_name
Use relationship endpoints when you need to list, add, update, or remove links: 
/api/v2/contact/{contact_id}/relationship/accounts
/api/v2/account/{account_id}/relationship/contacts
/api/v2/{object_api_name}/{record_id}/relationship/{api_name}
Some relationships use a junction record. A junction record stores data about the relationship itself, such as a role or primary flag.