Skip to main content
Weelkit authenticates every request to your Custom API (manifest discovery, publish, update, list, delete, readback and the background status checks) with an API key you provide when creating the connection.

​
API key header

By default, Weelkit sends the key as a bearer token:
If your API expects a different header, configure a custom header name on the connection. Custom header names must:
  • start with X-,
  • contain only letters, digits, and hyphens,
  • be at most 64 characters.
For example, with the custom header X-Acme-Api-Key configured:

​
Transport requirements

  • HTTPS is required. Plain HTTP base URLs are rejected, the standard port 443 is required, and private, loopback, link-local, and cloud-metadata hosts are rejected at connect time — see Schema and limits.
  • Never place credentials in URLs. Weelkit sends the key only in the configured header, never as a query parameter — and you should not design your API to accept keys in URLs, where they leak into logs and referrers.

​
Key storage and rotation

  • Keys are stored encrypted by Weelkit and are never displayed after entry.
  • Weelkit doesn’t edit a saved key. To rotate, issue the new key on your side and keep the old one valid until you have replaced it. When your API rejects a key (401 or 403), publishing and status checks pause and the connection shows Connection Error; choose Reconnect and enter the new key with the same base URL, and the same manifest path and auth header name if you set them. The saved mapping, defaults and sent articles are kept.
  • A rejected key never signs you out of Weelkit: the error concerns your API key, not your Weelkit session. See the error categories.

​
No request signing

The Custom API protocol authenticates with the key only; its requests are not signed. If you want signed deliveries, use the API webhook, which signs every request and is verified as described in Signature verification.