The DonorDrive connector extracts data from the DonorDrive Export API into the data platform. It is designed around DonorDrive’s export endpoints and dynamically discovers the schema for each configured table before retrieving its records.

The connector is read-only. All interactions with DonorDrive use HTTP GET requests; it does not create, update, or delete data in DonorDrive.

A key characteristic of this connector is that tables and columns are not hardcoded. The selected table names come from the connector catalog, and each table’s columns are obtained from DonorDrive’s metadata endpoint at runtime.

The connector requires:

The base URL is constructed as:

The API key is sent using:

The configured earliest_start_date is normalized to the America/New_York timezone before it is used in API requests.

The connector validates the configuration using:

Full request:

The connectivity test treats 400, 401, and 403 as failures. Other HTTP status codes are considered sufficient to indicate that the credentials/API location are reachable. In particular, the code intentionally allows a 404 response during this connectivity test.

Important: This means a successful connector test does not necessarily prove that every configured export table exists or is accessible. Individual table endpoints are validated later during discovery and sync.

Before retrieving records, the connector performs schema discovery for every selected table.

For a table named {table}, it calls:

Example:

The response must contain:

as an array of column metadata. Each entry’s column value becomes a destination column.

All discovered columns are declared as string fields.

The connector does not declare any unique/key columns:

If the metadata response does not contain a valid result array, discovery fails for that table.

A normal sync explicitly runs schema discovery before retrieving records. This allows newly exposed columns to be picked up without maintaining a static schema in the connector.

The connector itself does not return a predefined list of DonorDrive tables. Its table-list operation returns an empty list.

Therefore:

This differs from connectors that have a fixed table map embedded in the connector.

The connector retrieves records using DonorDrive's lastModifiedStart and lastModifiedEnd filters.

For each table:

The start timestamp is formatted as:

The connector therefore requests all records modified from the configured earliest start date onward.

Although the DonorDrive API query uses a lastModifiedStart filter, the connector does not maintain or advance a sync bookmark.

The same configured earliest_start_date is used at the beginning of every run. No new last_started, last_modified, or similar state value is written after a successful sync.

For example, if:

then every run asks DonorDrive for records modified from January 1, 2025 onward.

This has two consequences:

For large or long-running integrations, this behavior can significantly affect sync duration and API usage.

Before retrieving a table, the connector first asks DonorDrive how many matching records exist.

The connector reads:

from the response.

If metadata.recordcount is missing, the connector assumes there are 0 records to retrieve.

Records are subsequently retrieved from:

with:

per API request.

Pages begin at:

and increase sequentially.

The connector continues requesting pages until the number of records written reaches the recordcount obtained before the paging operation began.

Every data response is expected to contain:

The connector also reads:

If the requested page number exceeds the page number reported by the response metadata, the connector fails with a Missing data encountered error rather than silently completing with potentially incomplete data.

This acts as a safety check against inconsistent or incomplete pagination.

Records from the API's result array are written directly to the corresponding table.

The connector does not perform significant transformation or field remapping during the data sync.

During discovery, every discovered column is declared as a string.

The actual record payload is then written as returned by DonorDrive.

Developers should therefore be aware that fields representing numbers, booleans, dates, or timestamps may still be represented by the connector schema as strings.

The connector uses GET only.

There are no POST, PUT, PATCH, or DELETE calls in this connector.

Purpose:

Authentication:

Purpose:

No query parameters are sent.

Parameters:

Purpose:

The count is taken from:

Parameters:

Purpose:

The connector has no delete synchronization mechanism.

It:

Therefore, if a record is physically removed from DonorDrive, that deletion will not automatically be reflected downstream.

If deletion reconciliation is required, it must be handled separately—for example through periodic full reconciliation or another source of deletion information.

The connector does not persist an incremental bookmark or watermark.

The only date controlling extraction is the configured:

That date is loaded again at the beginning of every run.

There is consequently no automatic progression such as:

This is one of the most important operational differences between DonorDrive and connectors that use true incremental state.

After each table finishes, the connector emits a:

metric containing the number of rows written for that table during the run.

This can be useful for:

Normal API requests may retry for up to:

The connector waits:

between attempts.

The delay is fixed; it does not progressively increase.

The following statuses are not retried by the standard request method:

These fail immediately.

Other non-200 responses are retried every 65 seconds until the 20-minute retry window is exhausted.

After that point, the last HTTP error is surfaced to the caller.

The connector defines specific messages for:

The most significant limitation is that the connector does not advance the extraction start date after successful runs.

Every run begins from the configured earliest_start_date.

A large historical window can therefore cause the same records to be downloaded repeatedly.

Recommendation: Carefully choose earliest_start_date based on the required historical window and expected sync frequency.

Dynamically generated schemas use:

No source field is marked as the unique identifier for a table.

Consequences include:

Records deleted upstream are not removed downstream automatically.

There is no delete endpoint or deletion-event handling in this connector.

Periodic source-to-destination reconciliation may be necessary if accurate deletion handling is required.

The connector's table-list operation returns:

This means the connector cannot independently tell a user which DonorDrive exports are available.

Table names must be provided through configuration/catalog and must correspond exactly to export resources available on that DonorDrive instance.

Columns are pulled from:

on every run.

This allows the connector to automatically detect new source columns, but it also means the destination schema can change when DonorDrive modifies its export schema.

Downstream models that assume a fixed set of fields should account for possible schema drift.

Regardless of the underlying business meaning, metadata fields are represented as strings in the connector's schema.

Dates, numeric amounts, counters, and boolean-like fields may therefore require explicit casting in downstream models.

Because every run re-reads everything modified since earliest_start_date, the size of the extraction can grow substantially over time.

Although individual API pages contain up to 5,000 records, large tables can still require many API requests.

A sync also performs:

for every selected table.

The connector obtains recordcount before beginning the main paging loop and uses that initial number to determine when to stop.

If the underlying export changes substantially while a long sync is running, the initial count and later pages may no longer represent exactly the same snapshot.

The connector includes a page-count consistency check to catch some pagination problems, but it does not establish a point-in-time snapshot of the source.

Instead of using the execution time as lastModifiedEnd, requests use:

In effect, the connector asks for everything modified after the configured start date with no practical upper date restriction.

The configured earliest_start_date is converted to:

before querying DonorDrive.

However, the outgoing lastModifiedStart value is formatted without an explicit timezone offset:

Developers troubleshooting records around date boundaries should keep this behavior in mind.

If the initial count response does not contain:

the connector interprets the table as having zero records rather than failing the run.

An unexpected zero-record sync should therefore be investigated rather than automatically interpreted as proof that the source table contains no records.

Every data page must contain both:

If either is missing, the connector aborts the table with:

This protects against silently accepting malformed or incomplete API responses.

The initial test only rejects HTTP:

Other responses—including 404—can result in a successful connectivity test.

Therefore, a successful Test Connection confirms basic connectivity/credentials more than it confirms that each configured export endpoint is valid.

Dynamic columns; all declared as strings.

with:

with

Because every execution re-queries data from the configured earliest_start_date, the connector can become slower over time and may repeatedly deliver the same records. Downstream data handling should therefore account for deduplication and repeated updates.