Knowledge base

PMTA knowledge base›Block <signals>›Directive§ 11.1.6.2.1

api-key

<signals>

Access key for the analytics service
in the configuration this is a lineapi-keyinside the block <signals>
The same name 2:<inline-seeding><signals><transmissions-api>— some of them are other settings, some are the same one
A line without which the node does not start

The key with which the node identifies itself to the analytics service when uploading data. The format is strict — exactly forty hexadecimal characters.

🔴 The line is mandatory in the strong sense: the manual says that the node will not start if a <signals> block exists but has no key in it. This sets it apart from most mandatory lines, where the failure is softer.

The key needs two permissions: “Incoming Events: Write” and “Account: Read.” The same key also works for seeding.

The key sits in the configuration in plain text and gets into its backups.

The main trap is adding the block and forgetting the key. This is not “the feature does not work” but the node does not come up. When editing the configuration on a live fleet, the price of such forgetfulness is higher than usual.
What the Hub does. It does not write it: we do not use export to external analytics. The fleet’s events reach us directly, through the accounting webhook, and there is no reason to hand them outside.
Recommended values

The choice here is short:

What Requirement
length exactly 40 characters
character set hexadecimal digits
permissions Incoming Events: Write and Account: Read
The format, both required permissions and the fact that the node does not start without the line come from the manual (§ 11.1.6.2.1).
Example configuration
# without this line the node will not come up at all
<signals>
    api-key 0123456789abcdef012345678901234567890123</signals>
The key is in the configuration in plain text: the file’s permissions are kept as for a secret.
yellow — — directive names, blue — blocks. They are highlighted the same way in the text of the card.
▲

Common mistakes and problems

what people get wrong and how it ends1 mistake▶

Adding the upload block without a key

our experience

What it costsThe node will not start. This is not a feature failure but a failure of the entire engine.
How to spot itAfter a configuration edit the engine does not come up.
How to do it rightCheck that the key is present before applying; configuration reconciliation catches this.
Compatibility
PowerMTA 6.0
described in the manual of this version · platform: any
The vendor does not state the first version for every directive — there is no note here. The name also appears in the 5.0 edition of the manual.
Reference data
Syntax
api-key <40 hexadecimal digits>
Values
forty hexadecimal characters
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<signals>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
There is no inheritance: the line lives inside <signals>, and there is only one such block on a node. The export coverage by stream is set not here but with the enable-signals line, which has three levels.
How to check on the node
Whether the key works is visible from the upload log:
grep -i "signals\|sparkpost" /var/log/pmta/log | tail -20
Refusals from the service mean a wrong key or missing permissions. The very fact that the node started means the line at least exists.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Prepare a node for sending