Skip to main content
TLVs are declared as <name>_<tag> tokens. The name is cosmetic — the tag is authoritative, so the gateway, a credential and a vendor may each name the same tag differently and still agree on it.

​
The tag is decimal unless prefixed 0x

This is the one genuinely surprising part of the syntax, and it is that way because existing deployments already declare decimal tags. Valid tags are 0x0000–0xFFFF. A token whose tag will not parse is logged and skipped.
vendor_1400 and peid_0x1400 are different tags. If a carrier gives you a tag as 0x1400 and you write 1400, everything loads, nothing warns, and the wrong tag goes on the wire.

​
Five declaration levels

​
Precedence: message > credential > vendor

Defaults only fill gaps. They never overwrite a value that is already present. So a value the customer sent beats a credential default, which beats a vendor default. The exception is the whitelist stamp in replace mode, where the overwrite is the approval — see Whitelisting.

​
Default values

A default may be:
Values cannot contain , or =. There is no escaping — use hex: when a vendor needs them.The format is <name>_<tag>=<value>, comma-separated. A malformed entry such as PEID=…, with no tag on the name, parses to nothing and logs only a WARN. The setting looks applied and does nothing.

​
Unlisted tags are discarded

registered.tlvs.submit on a listener is an allow-list: a tag the customer sends that is not declared there is dropped, not passed through. The same on the vendor side decides what actually reaches the carrier.
The per-vendor mandatory.tlvs.submit is checked after registered.tlvs.submit has filtered. Requiring a tag that is not also registered can therefore never be satisfied — the gateway warns about that pairing at load.

​
Where a missing tag surfaces

See Status codes and, for the operator’s view of which approved rows have tags nothing will supply, the coverage report described in Sender IDs.