Skip to main content
Version: v1.0

Security

Security guidelines for the integration between your CRM and Spot2 Ingestion.


Channels

The integration uses two channels:

  1. Pull: we query your API to fetch properties.
  2. Webhook (optional): you receive notifications from us about results.

Each channel has its own authentication mechanism.


Pull (authenticating our queries to your API)

Supported methods

MethodImplementation
API KeyHeader x-api-key. You provide us a key and we send it with every request.
Bearer TokenHeader Authorization: Bearer <token>.
Custom headerAny header name and value you define.

Recommendations

  • Dedicated key: create a key exclusively for Spot2. Don't reuse keys from other integrations.
  • Least privilege: read-only scope over the properties endpoint. No write permissions or access to other resources needed.
  • No auto-expiry: the key must not expire over time. If you need to rotate it, coordinate a transition window.
  • Per-key rate limiting: if your API has rate limits, configure them per key (not globally) so other integrations don't affect us.

Webhook (authenticating our notifications to your endpoint)

Bearer Token

Each webhook we send includes a shared bearer token so you can verify that the request comes from Spot2.

Header:

Authorization: Bearer <feedback_token>

Verification:

  1. Extract the token from the Authorization header.
  2. Compare the received token against the agreed value (feedback_token).
  3. If it matches: process the webhook. If it does not match: respond 401 and discard.

Token rotation

If you need to rotate the feedback_token, coordinate it with us. We can configure a transition window where we accept both tokens (old and new) to avoid rejections during the change.


Transport

  • TLS: minimum 1.2. Preferably 1.3.
  • HTTPS: required for both channels (pull and webhook).
  • Certificates: must be valid, not expired, issued by a recognized CA.

Rate limits

By default, we make a maximum of 60 requests per minute to your API.

Timeout

The standard operational timeout is up to 300 seconds per request. We recommend that your API respond well before that limit and use 429 or 503 when you need to indicate rate limiting or temporary maintenance.