Does Telegraf need a plugin to write to Tag Historian?

No. Tag Historian accepts InfluxDB v2 line protocol on POST /api/v2/write, so the stock outputs.influxdb_v2 plugin works unchanged. Gzip is on by default in Telegraf and the endpoint accepts it, so leave that default alone.

How many tags does a default Telegraf configuration use?

More than you expect. Every distinct metric-and-field combination becomes its own tag. A stock [[inputs.cpu]] alone produces about ten fields per CPU, so an eight-core machine spends roughly eighty tags on CPU metrics before anything else is collected.

Do org and bucket matter?

No. They are parsed and discarded — the API key alone decides where data lands. Any value satisfies Telegraf's config validation. bucket_tag is therefore pointless here.

Telegraf, without running an InfluxDB

Telegraf writes to Tag Historian with its stock outputs.influxdb_v2 plugin. No custom output, no plugin to build — and no InfluxDB to install, patch, back up or restore.

The configuration is four lines. The part worth reading is the second half, because Telegraf's default inputs will spend a tag quota faster than anything else that writes to this endpoint.

Last updated 11 August 2026

1. Get an API key

Create an account and an API key first. The free plan is €0 and takes an email address — no card — and gives you 5 tags and 50,000 readings a day. Then create the key on the Settings page in Tag Historian Explorer — and the scope you give it is not a detail.

Set Scope to Write

Press Create New Key, name it, and set Scope to Write. The dialog opens on Read, which is the safe default and the wrong one here. The key list shows the scope beside every key afterwards, so you can check one you already have instead of issuing another.

This is the credential an unattended gateway holds, so it should be able to do the job and nothing else. A Write key sends measurements, creates a tag the first time it writes to a new name — against your tag quota — and reads and exports everything a Read key can. It cannot issue or revoke API keys, not even its own; it cannot delete a tag, which is what deletes that tag’s history; it cannot change your plan or cancel your subscription; and it cannot invite or remove anyone from your team. Those endpoints refuse it with a 403; they do not quietly do nothing.

If you reuse an existing key, check its scope in that list first. The key an account recovery hands you is Admin — the whole account, billing and key management included, and far more than anything on this page needs.

The key is shown once. Copy it straight into your telegraf.conf, or a TELEGRAF token file — if you lose it, generate a new one rather than hunting for the old one.

2. Add the output

telegraf.conf

[[outputs.influxdb_v2]]
  urls = ["https://api.taghistorian.com"]
  token = "<your-tag-historian-api-key>"
  organization = "anything"
  bucket = "anything"

Gzip works. Telegraf compresses request bodies by default (content_encoding = "gzip") and the endpoint accepts it — leave the default alone.
organization and bucket are ignored. They are parsed and discarded; any value satisfies Telegraf's config validation. Your API key alone decides where data lands.
bucket_tag is pointless here. It exists to let metrics route themselves to different buckets, and Tag Historian has no buckets — everything written with one key lands in that key's account.
Telegraf splits on 413. A request over 5 000 points or 10 MB is refused with 413, and Telegraf halves the batch and retries on its own. You do not need to tune metric_batch_size for this.

The part that costs you money

Every distinct metric-and-field combination becomes its own Tag Historian tag, and each one counts against your plan. Telegraf's naming is generous about this: cpu,cpu=cpu0,host=srv01 with a usage_idle field becomes the tag cpu.cpu-cpu0.host-srv01.usage_idle.

Once you hit the tag limit, new tags are refused with 422 and existing tags keep writing. Going over your plan does not silence the metrics that are already flowing.

Why point Telegraf here rather than at an InfluxDB

If you already run an InfluxDB you are happy with, do not change anything — this is not faster and it is not more capable. The trade is operational: there is no server to keep alive, and the hourly minimum, maximum, average and count for every metric is kept for 10 years on every plan, including the free one, without you sizing a disk for it.

The costs of the trade are equally real, and they are listed plainly on the line protocol reference: there is no query API, no Flux, and no deduplication on rewrite. It is a write endpoint plus storage, not an InfluxDB.

Endpoint: https://api.taghistorian.com. Full status-code table and the tag-naming rules: InfluxDB line protocol.

Common questions

Does Telegraf need a plugin to write to Tag Historian?: No. Tag Historian accepts InfluxDB v2 line protocol on POST /api/v2/write, so the stock outputs.influxdb_v2 plugin works unchanged. Gzip is on by default in Telegraf and the endpoint accepts it, so leave that default alone.
How many tags does a default Telegraf configuration use?: More than you expect. Every distinct metric-and-field combination becomes its own tag. A stock [[inputs.cpu]] alone produces about ten fields per CPU, so an eight-core machine spends roughly eighty tags on CPU metrics before anything else is collected.
Do org and bucket matter?: No. They are parsed and discarded — the API key alone decides where data lands. Any value satisfies Telegraf's config validation. bucket_tag is therefore pointless here.

Try it on the free plan

5 tags, 50,000 readings a day, 14 days at full resolution and ten years of hourly summaries. €0, no card.

Create a free account All guides