Knowledge base

always-allow-api-submission

<source>

Whether to enable all permissions needed for API submission at once
in the configuration this is a linealways-allow-api-submission falseinside the block <source>
A shortcut behind which stands one specific line

The default is false. The manual describes the directive as a convenience: it enables at once all SMTP permissions and capabilities needed for our submission APIs.

And right there it says what this equals currently: the value yes is equivalent to allow-mailmerge yes. With no the question is decided by the other settings individually.

That is, the line is not a switch for a single capability but a shortcut for a set, and the vendor reserves the right to change that set. Today it contains one directive; the next version may have more.

The main trap is that the set may change while the line does not. The wording “currently equivalent” is a vendor warning: what exactly the shortcut enables depends on the engine version. An upgrade can expand the set silently, and the source’s permissions will grow without a single configuration edit.

Hence the rule: if you need one capability from the set, enable it with a direct line. Keep the shortcut for when you really submit through the vendor API.

What the Hub does. It does not write it — the line was removed from the working configuration on August 29, 2026.

Why it was removed. The Hub does not use HTTP submission at all, there is no <transmissions-api> block in the configuration, and the merging the line currently enables is not needed. The deciding argument was the manual’s word “currently equivalent”: the vendor reserved the right to expand the directive’s content, and the permission had been granted to all addresses at once.

If HTTP submission is needed, it is enabled by its own block with a key, and at that point you consciously decide whom to open it to.

Recommended values

What to set. The question is whether you submit through the vendor API:

Value When
false (default) submission goes over regular SMTP — our case
true submission really goes through the vendor API, and there is no point listing permissions one by one

There is a third path between them: enable the needed capability with a direct line. It is preferable to the shortcut wherever the set is known — because it does not change when the engine is upgraded.

The false default, the purpose and the “currently equivalent to the merge permission” caveat come from the manual, § 3.3.7.72. The advice to prefer a direct line is ours.
Example configuration
# the shortcut is justified where submission really goes through the vendor API
<source 10.0.0.0/24>
    always-allow-api-submission true</source>
Currently the same line is equivalent to allow-mailmerge yes. If that is exactly what you need, it is more honest to write it directly: the vendor may expand the set behind the shortcut.
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 ends2 mistakes▶

Enabling the shortcut for the sake of one capability

§ 3.3.7.72

What it costsThe source’s permissions are already broader than intended, and with an engine upgrade they may grow further — without a configuration edit and without notice.
How to spot itThe receiver’s greeting advertises extensions you did not enable.
How to do it rightEnable the needed capability with a direct line, and keep the shortcut for real submission through the vendor API.

Keeping the shortcut where the API is not used

our experience

What it costsThe source gets permissions it does not use. Removing them later is harder than not granting them: the line looks necessary until you read what it equals.
How to spot itThe shortcut is in the configuration, while submission goes over regular SMTP.
How to do it rightRemove the line and check that submission did not break — regular SMTP does not need it.
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
always-allow-api-submission <boolean>
Values
yes | no | true | false
Default
false § 3.3.7.72
Applying
reload, no restart needed
Queue
will not touch what is already queued
Where to write it
<source>
How many times
once in the block
Everything here comes from the manual, with the section.
Inheritance
The directive lives in <source> and follows source merging: a connection falls under all address blocks that cover it, and a narrow one overrides a broad one. The shortcut in the 0/0 block hands its set of permissions to all subnets that did not say otherwise themselves.
How to check on the node
You need to look at both the shortcut and what it enables:
grep -n 'always-allow-api-submission\|allow-mailmerge' /etc/pmta/config /etc/pmta/virtualhost.txt
printf 'EHLO test\r\nQUIT\r\n' | nc <node-address> 2525
The receiver’s greeting shows which extensions are actually advertised to the source. This is the reliable way to learn what the shortcut enables in your engine version.
In the Hub
Cost of a mistake
reversible: harms only while it is set
Scenarios
Connect a sending platform