API Key Usage Documentation

Authentication Header

Include your generated API key in every request header:

x-api-key: <api_key>

API key values are shown only once at creation. Store them securely in your server-side secret manager.

Quickstart Example

Example request using API key authentication:

curl -X POST "https://prospector.estateprospector.com/api/private/user/getDataByConditions" \
  -H "Content-Type: application/json" \
  -H "x-api-key: <api_key>" \
  -d '{
    "filterList":[{"field":"State","value":"CA"}],
    "page":1,
    "sortBy":"Office Name",
    "sortOrder":"DESC"
  }'

Scopes

Supported Routes

POST /api/private/user/getDataByConditions Request Body

Use this payload structure for unlocked list fetch requests with API keys.

{
  "filterList": [
    { "field": "State", "value": "AK" }
  ],
  "page": 1,
  "sortBy": "Office Name",
  "sortOrder": "DESC"
}

Body Fields

filterList Item Format

value Format by field

Validation Notes

• If sortBy is invalid, API returns HTTP 400.
• If sortOrder is not ASC or DESC, API returns HTTP 400.
• If filterList is not an array, API returns HTTP 400.
• If a filter.field is outside the allowed set, API returns HTTP 400.
• For best stability, always send non-empty string value for each filter.

Rate Limits

API key requests are rate-limited to protect service stability. Limits are enforced server-side and can vary by account plan and endpoint sensitivity.

• When limit is exceeded, the API returns HTTP 429 (Too Many Requests).
• Implement exponential backoff and retry with jitter for safe recovery.
• Avoid sending burst traffic from parallel workers using the same API key.
• Use separate API keys per integration to isolate traffic patterns.

Common Status Codes

Security Recommendations

• Never expose API keys in frontend client code or public repositories.
• Rotate keys regularly and revoke keys immediately if compromise is suspected.
• Use separate keys per integration and environment for safer isolation.
• Grant only required scopes to minimize risk.