Resources

Security & Webhook Operations

What enterprise security reviewers and integration engineers need to know about COUNT's Partner API — authentication, data handling, rate limits, and outbound webhook delivery.

Security overview

The Partner API uses defense in depth: every request is authenticated with HMAC request signing (your app) and scoped with a workspace OAuth bearer token (the end user). Internal numeric database identifiers and storage paths are never exposed in partner responses.

Transport: TLS 1.2+ required for all API and webhook traffic.
Credential storage: clientSecret and refresh tokens must be stored server-side, encrypted at rest. Never embed secrets in client-side code or mobile apps.
Workspace isolation: Bearer tokens scope every data request to a single workspace authorized by the end user.
Least exposure: Partner JSON omits internal foreign keys, storage URLs, and sensitive document fields. See the Documents API for privacy field details.

Token and secret handling

// Store refresh tokens encrypted at rest.
// Never log clientSecret, access tokens, or signing secrets.
// Rotate clientSecret if compromised — contact COUNT support.

Authentication model

See Authentication & signing for the full HMAC base string and OAuth token exchange flow. Token exchange routes require signing only; all data endpoints require signing plus a valid Bearer access token.

Clock skew

Request timestamps must be within the allowed window. Use NTP-synchronized servers for signing.

Rate limits & availability

Partner API requests are limited to 100 requests per minute per clientId at the HMAC gate. Some resource-specific limits apply (for example Documents upload tiers). Responses may include X-RateLimit-* and Retry-After headers.

Production API availability targets 99.9% monthly uptime. Subscribe to status.getcount.com for incident notifications.

Data handling

Partner responses expose UUIDs as id — never internal numeric IDs.
Webhook and API payloads may contain customer PII — treat as confidential financial data.
Document downloads are not returned on the partner Documents API — plan a controlled flow if you need file bytes.
Disconnecting an app should revoke stored tokens on your side; users can revoke access from COUNT.

Privacy policy: getcount.com/privacy

Enterprise diligence

For security questionnaires, SOC 2 reports, or penetration test summaries, contact support@getcount.com from your company domain with your integration name and expected go-live date.

Include your planned data categories (customers, transactions, documents, etc.). See the Partner Program page for the production review process.

Webhook delivery operations

COUNT sends outbound HTTPS POST requests to your registered callback URL when a subscribed event occurs. This is traffic to your server — not an API route you call.

Behavior	Detail
Protocol	HTTPS only. Localhost and private IPs rejected at subscription and delivery.
Timeout	15 seconds per delivery attempt.
Redirects	Not followed (maxRedirects: 0).
Retries	Up to 3 attempts with exponential backoff starting at 2 seconds. Egress safety failures are not retried.
Acknowledgment	Return HTTP 2xx to acknowledge success.
Ordering	Deliveries are not guaranteed to arrive in causal order. Design handlers to be idempotent using the delivery `id`.

Webhook headers & envelope

X-Webhook-Id — unique delivery UUID (same as envelope id)
X-Webhook-Event — event name, e.g. invoice.updated
X-Webhook-Signature — present when a signing secret is configured. Format: sha256=<hex>

Walkthrough: Verify webhook deliveries. Reference: Webhooks API.

Handler checklist

// Verify X-Webhook-Signature against the raw request body bytes.
// Respond with HTTP 2xx within 15 seconds.
// Process the event asynchronously if your handler needs more time.

Idempotency recommendations

Store processed delivery IDs and skip duplicates. For create/update events, upsert by resource UUID from the envelope data object. Delete events include previousData when the full record is no longer available.