How do I read JSON API endpoints next to logs from Vercel projects when an AI SRE investigates?

Tares puts a JSON API endpoint and your Vercel logs on one timeline when both carry the same label value, such as the Vercel project name. You add a vercel source for the log drain and an http_poll source for the endpoint, and give the API source a label with the project’s value. When an AI SRE reads that value, it gets the log lines and the API items together.

How it works

Two sources feed one timeline, and a shared label value joins them.

• Vercel logs arrive by push. The vercel connector receives a Vercel log drain and stores one event per log entry. Each entry is keyed by project, and environment and source are labels. The labels path, host, deployment and branch are also provided. One drain can carry several projects, and each shows up as its own entity.
• API items arrive by poll. The http_poll connector calls your endpoint on the source’s schedule and stores one event per item. If the reply is a list, each entry becomes an event. If it is an object, the whole object is one event.
• The label value is the join. Give the API source a primary label named project whose value is the Vercel project name. The log lines and the API items then carry the same value. Reading that value returns both, in time order, so a spike in 5xx log lines sits next to the API reading that changed at the same moment.
• Payloads are stored as received. Labels you declare later can still reach every field of the API reply, including nested ones by dotted name.

This is the same data an AI SRE investigation reads. You do not wire the two sources together. You only keep the label value identical.

Set it up

1. Create the Vercel source. In Sources, choose Add source, then vercel. There is no required config. The project, environment and source labels are pre-filled. Save it and copy the ingest endpoint from the source page. Vercel delivers from its cloud, so the endpoint must be publicly reachable. Use a deployed instance or a tunnel, because a bare localhost daemon does not receive drains. See Vercel logs for the full connector page.

- name: web-logs
  connector: vercel
  config:
    labels:
      - { name: project, field: project, primary: true }
      - { name: environment, field: environment }
      - { name: source, field: source }

2. Add the log drain in Vercel. Go to Team Settings, Log Drains, Add Log Drain. Set the endpoint to the ingest URL and the delivery format to JSON. Vercel verifies the endpoint with an x-vercel-verify header, and Tares echoes it back. The sender uses a Bearer Authorization header holding an ingest-scoped API key, needed only when Tares has auth on. In that case, add it to the drain as a custom header.

3. Add the API source. In Sources, choose Add source, then HTTP API (poll). Enter the URL and press Discover. Tares calls the API once, shows the reply, and fills in what becomes an event. Then add the shared label. Here the label project has a constant value equal to your Vercel project name. If each item already carries the project name in a field, use that field in the label instead. See HTTP API (poll) for every option.

- name: web-status
  connector: http_poll
  poll: 5m
  config:
    url: https://api.example.com/v1/readings
    event_type: api_reading
    id_field: id
    credential: abc123
    credential_header: X-API-Key
    labels:
      - { name: project, const: web, primary: true }

The credential is stored as a secret, and credential_header names the header it travels in. Use id_field so an item seen in recent polls is not stored again.

4. Check that the values match. The value of project on the API source must be spelled exactly like the Vercel project name. Open the Vercel source and look at Fields to see which project values appear. Compare them with the label on the API source.

5. Verify both sources. Open each source and look at Recent events. The Vercel source shows log entries arriving, and the API source shows one event per item after the next poll. A poll interval under 10 seconds is refused when you save. On a 429 or a 5xx reply, Tares waits before the next request and doubles the wait up to an hour, and the source’s health shows the next try.

What you get

• One read of a label value returns Vercel log lines and API items together, so an investigation does not need to look in two places.
• API readings, such as a status or usage endpoint, sit on the same timeline as the requests and builds that surround them.
• Each Vercel project stays a separate entity, so the join works per project even when one drain carries several.
• Triggers can watch fields from the API reply by dotted name, for example a number label on a reading, alongside the log events.
• The API is polled by Tares on a schedule, so you run no script on your side.

When something else fits

• If the data you want to place beside the logs lives in a database rather than behind an API, the Postgres connector reads new and changed rows on a cursor column. A tenant_id label on the rows can join them to log lines that carry the same value.
• If the system can call Tares itself, a push source is simpler than polling, because there is no schedule or rate limit to manage.
• If the API items and log lines share no value, there is nothing to join on. Add a constant label such as project to the API source first.

Related