Start here

Authentication

Use the credential for the direction of the connection. A Pongg event key and your CRM bridge credential serve different purposes.

Two credentials, two boundaries

Credential	Sent by	Used for
Pongg integration key	Your server → Pongg	The three public subscription/preview endpoints
Bridge API key or service-account access token	Pongg → your server	The fixed CRM bridge operations
Native provider browser consent	Customer → provider	A supported CRM/calendar connection in Pongg Integrations

Pongg integration keys

Every public event API request sends Authorization: Bearer <key>. A key is pongg_ plus 40 random characters (46 total). Pongg resolves the account from the key, so do not send a workspace id, tenant header or tenant query parameter.

HTTP

Authorization: Bearer YOUR_PONGG_KEY

Owners/admins create and turn off keys in Integrations. The key is shown once; only a hash is stored. A lost key cannot be recovered. For rotation, create a new key, update your server and verify it, then turn off the old key. Never reuse an internal Pongg service credential.

CRM bridge API keys

Create a dedicated credential on your bridge, bound to the correct Pongg tenant. Enter it in the Custom CRM connection form. Pongg sends it as a Bearer token; no Pongg event key is involved. Enforce the tenant binding on every bridge operation and isolate credentials, calendar access and records between clients.

Authentication

API key: Pongg sends the configured key as a Bearer credential on every bridge request. Keys must contain visible ASCII characters without spaces or control characters. Store credentials in the Custom CRM connection form, never in the endpoint URL.

Contract example

Authorization: Bearer YOUR_BRIDGE_API_KEY

OAuth 2.0 client credentials: provide your HTTPS token URL, client ID, client secret and optional scope. The scope field is sent only when provided. Pongg sends a form POST using HTTP Basic client authentication. Client ID and secret are form-encoded before Basic encoding. This is a machine account flow, not an end-user browser consent screen.

Contract example

POST https://auth.example.com/oauth/token
Authorization: Basic BASE64_ENCODED_CLIENT_CREDENTIALS
Content-Type: application/x-www-form-urlencoded
Accept: application/json

grant_type=client_credentials&scope=crm.read+crm.write

Contract example

{
  "access_token": "EXAMPLE_ACCESS_TOKEN",
  "token_type": "Bearer",
  "expires_in": 3600
}

Return token_type: "Bearer". expires_in is optional; only a numeric lifetime greater than 30 seconds is cached, for at most five minutes with a 30-second safety margin. Without a usable lifetime, Pongg requests a fresh grant next time. The cache is bound to tenant, account, endpoint, configuration and credentials. A bridge HTTP 401 causes one fresh grant and one replay of the same request; another 401 stops. API-key 401s are not replayed through OAuth.

Native CRM and calendar sign-in

Supported OAuth integrations such as Google Calendar and HubSpot ask the customer to approve their own provider account through Integrations. Those flows do not create a public Pongg authorization server, and the service-account bridge flow is not a browser sign-in flow.

Credential handling

Keep credentials on a server or in the configured integration store, never in a screenshot, example payload or query string.
Use a separate bridge credential per company and restrict its CRM permissions to the operations required.
Treat caller names, addresses, summaries and notes as customer data. Keep them out of logs and support messages unless needed and authorized.
On repeated authentication failure, correct the connection rather than retrying indefinitely.