Skip to main content

Authentication & Provisioning

BlueSender's auth model has three layers:

  1. License keys — issued to an end-user (often by an upstream tool like Stripe or Zapier). Each license has a maxSeats cap. See License keys.
  2. Device pairing — a Mac running BlueSender activates against a license using a stable deviceId. While the device is active, it counts as one seat against maxSeats. See Device pairing.
  3. Locations — once activated, a Mac binds to a single CRM tenant via a locationId. The location is the routing key for inbound POST /crm/webhook traffic from the CRM and for outbound delivery back to the CRM. See Locations.

What you, as a CRM integrator, call​

The only HTTP surface you call is POST /crm/webhook on the BlueSender backend. See HTTP Webhooks for the full request/response contract.

Everything else — license issuance, device pairing, seat management — is handled out-of-band between the BlueSender operator and the Mac client. Integrators don't need to call those surfaces.

What you don't authenticate​

  • HTTP webhooks (POST /crm/webhook) do not require per-request credentials. Routing is keyed on locationId matching a connected Mac. Optional signature verification is available but disabled by default.
  • License vs Location — these are separate; a license tracks seats, a location is a CRM tenant.