SyncDock API Keys, Scopes & HMAC Signing

Create SyncDock API keys, assign least-privilege permission scopes, and decide when to require HMAC-SHA256 request signing.

Updated July 21, 2026 3 min readintermediate

On this page

A SyncDock API key is created in the admin screen, carries its own set of permission scopes, and is stored only as a SHA-256 hash — the raw key is displayed exactly once. Getting the key design right up front is most of what makes an external integration safe to leave running unattended.

Before you begin

SyncDock installed and active — see the SyncDock setup guide
A clear picture of what each external client actually needs to do

Creating a key

Open the key management screen

In wp-admin, open SyncDock's API key screen. Every key your site has issued is listed here with its scopes and signing policy, and each can be revoked independently.

Name the key for its client

One key per integration — "newsletter-pipeline", "claude-agent", "mobile-app" — never one shared key for everything. Naming by client is what makes the activity log and revocation meaningful.

Assign the minimum scopes

Pick from the ten permission scopes (read_posts, write_posts, delete_posts, and seven more) and grant only what the client uses. A read-only analytics job gets read scopes; a publishing agent gets write but not delete.

Set the HMAC signing policy

Choose disabled, optional, or required per key. Require signing for keys that hold write or delete scopes or traverse untrusted networks.

Copy the raw key immediately

The key is shown once, then stored as a SHA-256 hash. Put it in your secret manager now — if it is lost, you revoke and reissue; there is no recovery.

How authentication works on the wire

Clients send the key in the X-SyncDock-Key header on every request to the namespace. Because keys are hashed at rest, a database dump does not leak working credentials, and because each key is independent, revoking a compromised integration never disturbs the others.

HMAC-SHA256 signing adds a second property: proof that this exact request was authored by the key holder and is fresh. Signed requests carry timestamp headers and are rejected outside a five-minute replay window, so a captured call cannot be replayed later. It closes the gap between "the caller has a token" and "the caller wrote this request."

Rate limits and brute-force defence

A sliding-window rate limiter applies per key and per IP, with thresholds you set in the admin screen — cap an experimental integration low, raise it once it earns trust. Separately, repeated authentication failures trigger brute-force protection at ten failures per fifteen minutes per IP, so a scanner probing for valid keys is throttled before it touches your database.

Every request lands in the activity log with its status code and response time, which is where a misbehaving client shows up first.

Never embed a write-scoped key in client-side code that ships to users, such as a public browser extension. Keys belong on servers or in per-user configuration; anything published can be extracted.

Next steps

SyncDock

Headless publishing for WordPress — push posts in from external tools and AI pipelines over a clean, authenticated API.

About SyncDock →Get SyncDock (Free)