Fetch Connector — Overview

Introduction

The Fetch Connector enables RecordPoint customers to integrate any customer-hosted API with the RecordPoint platform for compliant records management. Rather than connecting to a specific vendor system, this connector provides a standardised, MuleSoft-compatible integration interface that allows organisations to expose their own data sources — ingesting records, binaries, and audit metadata into RecordPoint.

This connector is suited for organisations that need to bring content from custom or internal systems into RecordPoint, where no native connector exists. It is particularly valuable for MuleSoft-based integration architectures and bespoke line-of-business systems.

Key Capabilities

The Fetch Connector periodically polls customer-hosted API endpoints to discover new or updated items. It ingests records, binaries, and optionally audit events into RecordPoint for governance, classification, and lifecycle management.

Key Features

Standardised Response Structure — Every endpoint returns JSON in a unified envelope format, simplifying connector-side processing.
Delta / Incremental Ingestion — Supports query-parameter-based delta (e.g. lastModifiedDate) for incremental ingestion of changed items only.
Record and Binary Management — Allows ingestion and disposal of records and associated binary files.
Pagination — Supports pagination using links.self and links.next to ensure complete data retrieval.

Default Managed Objects

The connector manages customer-defined aggregations, records, and binaries. The entity hierarchy is flexible and defined by the customer API implementation.

Aggregation (Customer-defined container)
├── Record (Business data item)
│   └── Binary (Attached file or document)

Detailed Entity Table

Customer API Entity	RecordPoint Item Type	Parent	Notes
Aggregation	Aggregation	—	Primary container, customer-defined (e.g. Project, Case)
Record	Record	Aggregation	Business data item, uniquely identified by `ExternalId`
Binary	Binary	Record	Attached file or document linked via `itemExternalId`

How It Works

1. Records

Polls GET /records on a scheduled basis.
Supports cursor-style filtering, e.g. by using lastModifiedDate to request only items that have changed since the last poll.
Records are uniquely identified by ExternalId.
Supports pagination: the connector follows links.next until no further pages are available.

2. Binaries

Polls GET /binaries/metadata to retrieve metadata about binary files (e.g. documents).
Metadata includes details such as fileName, fileSize, fileHash, and itemExternalId (which links the binary to its record).
Downloads binary content from GET /binaries using metadata identifiers.
Associates binaries with the correct record in RecordPoint by matching on itemExternalId.
If binaries are versioned, each new version is ingested as a unique entry.

4. Disposals

The connector supports customer-controlled disposal processes.
When RecordPoint triggers a disposal, the connector calls the customer API to execute the disposal action in the source system.

Authentication

The API supports:

MuleSoft Client ID Enforcement — client_id + client_secret passed via HTTP headers.
OAuth 2.0 Client Credentials — Standard OAuth 2.0 client credentials flow.

API Contract

Response Envelope

All JSON responses must use the same top-level structure. This is the minimum required structure — the API may pass additional fields, but they are not logged or consumed by the connector.

Field	Description
`result`	`"SUCCESS"` or `"ERROR"`
`code`	HTTP status as a string (e.g. `"200"`, `"400"`, `"404"`, `"429"`)
`data`	For `200`: records or binary metadata. For errors: human-readable error message (string)
`links`	(Optional) Pagination/navigation links with `self` and `next`

Response Headers

You can add X-Correlation-ID and X-Transaction-ID to the response headers. In the case of an error, these will be logged along with the error data property string.

Dates and Times

All date/time strings must be in ISO 8601 format, UTC, or include a timezone offset.

Pagination

List endpoints paginate using links.self and links.next.

Rules:

links.self is the current page URL (absolute).
links.next is the next page URL (absolute).
Use deterministic ordering (e.g. modifiedDate ASC, externalId ASC as tie-breaker).
Return an empty result set to signify the end of pagination.

Ensure links are available in all list responses. Use an empty result to signify the end of pagination.

Limits

Constraint	Limit
Max records per page	1,000
Max record size	32 MB
Response timeout	60 seconds per request

Error Handling

HTTP	`code` (string)	`result`	Meaning	Typical Causes
200	`"200"`	SUCCESS	Successful response	—
400	`"400"`	ERROR	Bad Request	Missing/invalid params, invalid filters
404	`"404"`	ERROR	Not Found	Resource does not exist
429	`"429"`	ERROR	Too Many Requests	Rate limit exceeded
4xx	`"4xx"`	ERROR	Other Error	Other client-side error
5xx	`"5xx"`	ERROR	Server Error	Transient server or connectivity issue

Error Body Example

{
  "result": "ERROR",
  "code": "429",
  "data": "Too Many Requests"
}

Retry Behaviour

For 429 — implement exponential backoff and honour Retry-After if provided.
For 400 — correct the request and retry.
For other 4xx / 5xx — retry with backoff.

429 / 503 Retry-After Support

If the customer API cannot respond (e.g. due to a rate limit, timeout, or server error), it can reply with an HTTP Retry-After header. The RecordPoint connector will honour this header after a 429 or 503 to determine when to retry. If the response does not include a Retry-After header, the connector will perform a backoff retry.

Additional Entity Types

Please contact RecordPoint support to discuss support for additional entity types or custom API configurations.