Authentication

2mee uses different authentication for the two directions of traffic, because they have different trust models.

Inbound ingest — per-connection signature

Calls into 2mee at the ingest endpoint are authenticated by the URL plus a signature over the request body, not by a global API key:

• Each connection has its own inbound URL containing an unguessable key: https://hooks.2mee.com/v1/in/{inboundKey}. The key identifies which account and connection the call belongs to before any trust is extended.
• The request body is signed with that connection’s shared secret. 2mee verifies the signature against the secret it holds for that connection. A wrong signature is rejected with 401; an unknown key is 404.

This means two clients never share a URL or a secret. See inbound signing & verification for the exact scheme and copy-paste verification code.

No global ingest secret

There is no single shared ingest secret. Authentication is always scoped to the connection the URL identifies, so a leaked secret affects only that one connection — and you can rotate it without downtime.

REST API — API key

Calls to the 2mee API (https://api.2mee.com) are authorised with an API key created in the portal and sent in the x-api-key header:

x-api-key: <your key>

Keys are scoped to your account. Keep them secret and server-side. If a key is exposed, replace it from the portal — the old key stops working immediately.

Outbound — you verify us

When 2mee calls your endpoint (an outbound webhook), 2mee signs the request with your endpoint’s secret so you can verify it came from us. That’s the mirror image of inbound — see inbound signing, which uses the same HMAC-SHA256 scheme.

Transport

• HTTPS only. Plain HTTP is refused.
• TLS 1.2 or higher.