How do I send an API key or bearer token with the requests an http_poll source makes?

Tares sends one credential with every http_poll request through the credential field, which holds the whole header value, such as Bearer xyz or a plain API key. Tares stores it as a secret and never returns it through the API or exports it. The credential_header field names the header, Authorization by default, and non-secret extra headers go in headers.

How it works

An http_poll source calls a JSON endpoint on its schedule. Authentication adds one header to each request, built from two fields:

• credential is the whole header value, exactly as the API expects it. For a bearer token you write Bearer ghp_xxx. For an API key you write the key on its own, such as abc123. Tares does not add a Bearer prefix for you.
• credential_header is the name of the header that carries the value. If you leave it out, Tares uses Authorization. Set it to something like X-API-Key when the API expects its key there.

Tares stores credential as a secret. The API never returns it and an export never includes it. You can enter it once and rely on Tares to keep sending it.

One credential travels in one header. Other headers the API wants on every request go in headers, a map of extra request headers. Because headers is not secret, keep only non-sensitive values there, such as an Accept type or a version header.

The same fields apply on every request the source makes, including the single call that Discover makes when you set the source up.

Set it up

1. Open Sources, choose Add source, then HTTP API (poll). Fill in the method and URL. In the credentials part of the form, enter one header name and the value. Tares stores the value as a secret.
2. Add any non-secret headers the API wants in the additional headers field.
3. Press Discover. Tares calls the API once with your credential, shows the reply, and fills in what becomes an event. Pick the entity key from the fields it saw, then create the source.
4. To define the source as an object instead, use the same config with POST /api/sources. A bearer token in the Authorization header looks like this:

config:
  url: https://api.github.com/user
  credential: Bearer ghp_xxx          # a bearer token
  credential_header: Authorization

5. For an API key in a custom header, set credential_header to that header name:

config:
  url: https://api.example.com/v1/readings
  credential: abc123                   # an API key
  credential_header: X-API-Key

6. Put other headers the API needs on every request in headers. They are not secret.
7. Open the source and check Recent events. Each poll’s events appear with their summary line, which confirms the credential was accepted. Fields lists every field seen, with its coverage.

What you get

• Every poll carries your API key or bearer token without a script on your side.
• The credential stays a secret. The API never returns it and exports leave it out.
• You choose the header, so Authorization and custom names such as X-API-Key both work.
• Non-secret headers sit separately in headers, so the secret and the plain config stay apart.
• Rejections are visible. Any 4xx other than a rate limit shows as a config error on the source’s health, with the status and a slice of the reply, so a wrong or expired credential is easy to spot. On a 429 or a 5xx, Tares backs off and the health says when the next try is.

When something else fits

If the system calls Tares rather than the other way round, use the webhook connector instead. For the full list of fields and the rate limiting rules, see the http_poll page.

Related