> ## Documentation Index
> Fetch the complete documentation index at: https://docs.recotap.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Connect any system to Recotap using our REST API

Recotap is an AI-powered account-based marketing (ABM) platform built for SaaS and software companies. It aggregates first, second, and third-party intent signals across multiple sources — website visits, G2, Bombora, and LinkedIn ads — to score accounts, map them to buying journey stages, and help sales and marketing teams identify which accounts are most likely to convert and when. Recotap is an official LinkedIn Marketing Partner, with deep integration into LinkedIn ad activity as a core intent signal.

The Recotap External API gives you programmatic access to the Recotap platform. Any system — a CRM, a data warehouse, a CDP, an internal tool, or any custom application — can use these APIs to push data into Recotap and pull enriched data back out.

## What this API provides

<CardGroup cols={2}>
  <Card title="Push data into Recotap" icon="arrow-up">
    Push accounts, deals, sales activities, and custom field definitions so Recotap can score and segment them.
  </Card>

  <Card title="Pull enriched data out" icon="arrow-down">
    Pull accounts back with Recotap scores, intent signals, journey stages, and segment memberships to enrich your records.
  </Card>
</CardGroup>

<Warning>
  When you first push an account, all `rtp_` score fields are stored as `0`. Scores are updated on a schedule — not in real-time. Build your integration to expect a delay between pushing an account and seeing updated scores.
</Warning>

## Authentication

All requests require an API key passed in the `X-Api-Key` header. See the [Authentication](/authentication) page for how to generate your key and use it correctly.

## Base URL

All External API endpoints are under:

```
https://eapi.recotap.com/api/v1/
```

The current API version is `v1`. Breaking changes will be introduced under a new version path (e.g. `/v2/`). Existing `v1` endpoints will not be modified in a breaking way.

## Request format

POST, PUT, and PATCH requests must include:

```
Content-Type: application/json
```

GET requests require only the `X-Api-Key` header. No multipart or other content types are used anywhere in this API.

## Response envelope

All responses — success and error — share a consistent top-level structure:

```json theme={null}
{
  "statusCode": 200,
  "timestamp": "2026-04-30T10:00:00.000Z",
  "path": "/api/v1/accounts",
  "data": { ... }
}
```

Error responses follow the same envelope with `data: null` and two additional fields:

```json theme={null}
{
  "statusCode": 400,
  "timestamp": "2026-04-30T10:00:00.000Z",
  "path": "/api/v1/accounts",
  "data": null,
  "message": "Validation failed",
  "customMessage": "externalId is required for all accounts"
}
```

## Pagination

All GET list endpoints support `limit` and `cursor` query parameters. Most endpoints default to `limit=100`. Pagination is keyset-based — the `cursor` value is taken directly from `nextCursor` in the previous response. Pass `nextCursor` as `cursor` on the next request to fetch the next page.

| Parameter | Type    | Description                                                                        |
| --------- | ------- | ---------------------------------------------------------------------------------- |
| `limit`   | integer | Number of records to return. Defaults to `100`.                                    |
| `cursor`  | string  | Keyset cursor from `nextCursor` in the previous response. Omit for the first page. |

## Delta sync

Every GET list endpoint also supports `lastSync`, an ISO 8601 timestamp. Pass your last sync time and Recotap returns only records updated after that point. This is a **filter**, not a pagination control. Use it alongside `limit` and `cursor` for large syncs.

```
First sync:    GET /accounts?limit=100
Next page:     GET /accounts?limit=100&cursor=663abc...
Delta sync:    GET /accounts?lastSync=2026-04-30T10:00:00Z&limit=100
Delta + page:  GET /accounts?lastSync=2026-04-30T10:00:00Z&limit=100&cursor=663abc...
```

Your integration is responsible for storing the timestamp of each completed sync and passing it as `lastSync` on the next run.

## Bulk limits

| Resource                     | Max records per request |
| ---------------------------- | ----------------------- |
| Accounts (POST)              | 100                     |
| Deals (POST)                 | 100                     |
| Sales Activities (POST)      | 50                      |
| External ID mappings (PATCH) | 100                     |