canonical: https://jentic.com/apis/rd.services/rd

# Rd Services API de verticalização

The API de verticalização extends RD Station with custom objects: you define your own object types, such as properties or vehicles, and store records of them linked to RD Station contacts. Each custom object carries an external_id, a slug, and a label, and each record carries its own external_id, free-form attribute values, and contact metadata such as name and email. Records can be related to other objects, for example to a contact by email, and those relationships are listed, created, and removed through their own operations.

## For AI agents

Define RD Station custom objects, create and update records of them tied to a contact, and link records to contacts or other objects through relationships.

## Scope

Does not send email campaigns, score leads, or manage deals and pipelines. Use for defining RD Station custom objects and storing related records only.

## Capabilities

- Define a custom object type with an external_id, a slug that cannot change after creation, and a label
- Search custom object definitions by slug, label, or description with filter parameters and page through results
- Create a record under one custom object with its external_id, attribute values, and the contact it belongs to
- Update a record's attribute values with PATCH, passing the contact metadata the operation requires
- Link a record to another object, such as a contact identified by related_object_id and related_record_id
- Find every record related to a given record or object with the filter[related_record_id] and filter[related_object_id] parameters
- Exchange a client_id and client_secret for an access token with the client credentials grant

## Use cases

### Keeping RD Station records in sync from an AI agent through Jentic

An agent that watches another system, such as a property listing tool, can mirror each new item into RD Station as a custom object record tied to the interested contact. Through Jentic the agent searches for 'create a custom object record', receives the record-creation operation with its data and metadata inputs, and calls it while your self-hosted Jentic One instance handles the client credentials token exchange and injects the bearer token.

Example prompt: POST `/v1/custom_objects/{custom_object_id}/records` with data.external_id '123556', an attribute value for the listing, and metadata.contact with name 'Maria Silva' and email 'maria.silva@rdstation.com'

### Modelling a vertical business inside RD Station

Real estate, automotive, and education businesses track things that are not contacts or deals: buildings, cars, courses. The custom objects operations let you create an object type with a slug like buildings and a label like Imóvel, list existing definitions with slug, label, and description filters, and read one definition by id before adding records.

Example prompt: POST `/v1/custom_objects` with data.external_id 'sistema_imoveis', data.slug 'buildings', and data.label 'Imóvel', then GET `/v1/custom_objects/{id}` to confirm the definition

### Relating records to contacts

A record becomes useful in marketing once it is linked to the people who care about it. The relationships operations take a related_object_id such as rdsm_contact and a related_record_id such as the contact's email, and the records listing can then be filtered by filter[related_record_id] to find everything tied to one contact.

Example prompt: POST `/v1/records/{record_id}/relationships` with data.related_object_id 'rdsm_contact' and data.related_record_id 'joao@email.com', then GET `/v1/records` with filter[related_record_id] 'joao@email.com'

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/oauth2/token` | Get an access token |
| GET | `/v1/custom_objects` | List custom objects |
| POST | `/v1/custom_objects` | Create a custom object |
| POST | `/v1/custom_objects/{custom_object_id}/records` | Create a record |
| PATCH | `/v1/custom_objects/{custom_object_id}/records/{id}` | Update a record |
| GET | `/v1/records` | List records by related record or object |
| POST | `/v1/records/{record_id}/relationships` | Create a relationship |

## Key resources

- **Custom objects** — Object type definitions with external_id, slug, label, and description
- **Records** — Instances of a custom object with attribute values and contact metadata
- **Relationships** — Links from a record to a contact or another object's record
- **Access token** — Client credentials token exchange for the bearer token

## AI readiness

This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.

- **Score:** 69 / 100
- **Maturity:** AI-Aware
- **Dimensions:**
  - Foundational Compliance: 64 / 100
  - Developer Experience & Jentic Compatibility: 75 / 100
  - AI-Readiness & Agent Experience: 60 / 100
  - Agent Usability: 94 / 100
  - Security: 60 / 100
  - AI Discoverability: 64 / 100
- **View full report:** https://jentic.com/apis/rd.services/rd/scorecard
- **How the score is calculated:** https://docs.jentic.com/reference/api-readiness-framework/overview/
- **More about the dimensions:** https://docs.jentic.com/reference/api-readiness-framework/specification/#dimensional-model-overview

### Score it yourself

Every API in the directory is allowlisted, so you can re-score it with no key required.

- **Score your own API:** https://jentic.com/scorecard.md
- **Scoring CLI agent skill:** https://github.com/jentic/jentic-api-scorecard/blob/main/skills/jentic-api-scorecard/SKILL.md

```sh
npx @jentic/api-scorecard-cli score <openapi-url>
```

## Why Jentic

- **Setup:** Wiring this API by hand means running the client credentials exchange at POST `/oauth2/token`, refreshing the bearer token when it expires, and building the nested data and metadata bodies. Through Jentic you install once, import the API de verticalização from the API Directory, store the client credentials once, and your agent calls it.
- **Permission scoping:** The custom object id sits in the URL path (`/v1/custom_objects/{custom_object_id}/records`), so a rule can pin your agent to one custom object's records. You choose the operations it may call, so destructive ones like record deletion or relationship removal are not included unless you add them.
- **Credential handling:** Your client_id and client_secret are stored once, encrypted, by your own Jentic One instance and the resulting token is injected at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a custom object record' or 'link a record to a contact', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint without reading the Portuguese reference docs.

## Related APIs

- **HubSpot CRM Objects** — Generic CRM object records and associations in HubSpot
- **Pipedrive** — Sales CRM with persons, organizations, and deals
- **Zoho** — CRM and business apps suite

## FAQ

### What authentication does the API de verticalização use?

Per its OpenAPI spec, the API uses bearer tokens in the Authorization header. You get the token from POST `/oauth2/token` with the client credentials grant, sending grant_type, client_id, and client_secret; that token operation itself is open. Through Jentic, the client_id and client_secret are stored encrypted by your own Jentic One instance and the token is injected at execution time, so neither enters the agent's context.

### Is there an RD Station custom objects MCP server?

You don't need an MCP server to give your agent the API de verticalização. Jentic connects it directly from the API Directory: import it, store your client credentials once, and your agent calls it. Operations are discovered on demand, so the agent's context holds only the operation it is about to call.

### Can I limit what my agent is allowed to do with the API de verticalização?

Yes. For example, allow only GET and POST on `/v1/custom_objects/123/records` for one custom object, so the agent can read and add records of that type but cannot delete records, remove relationships, or define new object types. Every call it makes is logged.

### What fields does a new record need?

POST `/v1/custom_objects/{custom_object_id}/records` requires both data and metadata. Inside data, external_id is required and the remaining keys are your object's attribute values as text, numbers, or date-times; metadata needs a contact object. Optional relationships can be created in the same call.

### Can I change a custom object's slug after creating it?

No. The spec describes slug as the readable identifier used to reference the object in the API and states it cannot be changed after creation, so choose it carefully when calling POST `/v1/custom_objects.`

### What are the rate limits for the API de verticalização?

The OpenAPI spec does not specify rate limits. Check https://developers.rdstation.com for current limits before bulk-loading records.

### How do I add a custom object record through Jentic?

Install Jentic One with `curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh`, import the API de verticalização from the API Directory, and store your client_id and client_secret. Your agent searches for 'create a custom object record', receives the record-creation operation with its input schema, and calls it with the record and contact. To run it on your own infrastructure, install Jentic One from its GitHub repo.