How do I put JSON API endpoints beside GitHub App events?

Tares puts a JSON API endpoint beside GitHub App events when both sources carry the same primary label value, such as owner/repo. Add the endpoint as an http_poll source and give it a primary label with the value your GitHub events use. Push, release and workflow_run events are keyed owner/repo, so an API source keyed the same way lands on the same timeline.

How it works

Sources share a timeline only when they carry the same value on their primary label. Tares merges everything with that value onto one clock, the way the AI SRE guide keys metrics, logs and alerts by service.

The two sources contribute like this:

• GitHub App events. The GitHub App delivers pull requests, pushes, reviews, issues, releases and CI runs as GitHub webhooks. Every event carries a repo label when it applies.
• Keys differ by event type. push, release and workflow_run events are keyed owner/repo. pull_request, review, issues and issue_comment events are keyed owner/repo#number, so they do not match an owner/repo key.
• JSON API endpoints. The http_poll connector calls your endpoint on a schedule and stores one event per item. A label on the source can be a constant or read from a field of the reply, and you mark one as primary.

So the shared value is owner/repo. Your API source’s primary label must produce exactly the same string as the GitHub event key, for example acme/checkout-api. Details for each side are on the GitHub and HTTP API (poll) pages.

Set it up

1. Connect the GitHub App. On Tares Cloud, choose Connect GitHub in your workspace settings and pick the repositories. On a self-hosted Tares, open Settings > GitHub, choose Create GitHub App, confirm it on GitHub, then choose Install on GitHub. Either way you get a github source carrying the events of those repositories. A local tares up must be reachable from GitHub, so run a tunnel first:

cloudflared tunnel --url http://localhost:8787
TARES_PUBLIC_URL=https://<your-tunnel>.trycloudflare.com tares up

2. Pick the shared value. Use the repository name in owner/name form, for example acme/checkout-api. This is the key of the push, release and workflow_run events.

3. Add the API source with that value as its primary label. In Sources > Add source > HTTP API (poll), fill in the URL and press Discover, or use this object:

- name: checkout_status
  connector: http_poll
  poll: 5m
  config:
    url: https://api.example.com/v1/readings
    event_type: service_status
    id_field: id
    text_template: 'checkout status {status}'
    labels:
      - { name: repo, const: acme/checkout-api, primary: true }
      - { name: status, field: status }

4. Read the value from the reply when it carries one. If each item of the reply holds the repository name, replace the constant with a field, for example field: repo, and keep primary: true. The value must still read owner/repo.

5. Add credentials if the API needs them. Set credential to the whole header value and credential_header to the header name. Tares stores the credential as a secret.

6. Verify. Open the API source. Recent events shows each poll, and Fields shows the coverage of your key label. Then open Explore and pick the key value. Push, release and workflow_run events and the API readings appear on one timeline.

What you get

• One timeline for the key owner/repo, with GitHub pushes, releases and CI runs next to the readings from your API.
• A clear order of events, so you can see a push or a finished workflow run and what your endpoint reported before and after it.
• Polling that Tares runs itself. The source refuses a poll under 10 seconds and backs off on a 429 or a 5xx, with the state shown in the source’s health.
• The same timeline for any agent you connect, as described in the AI SRE guide.

Pull request and issue events keep their owner/repo#number keys and show up under those keys. They carry the repo label when it applies, but they do not merge with an owner/repo key.

When something else fits

• If the rows you want to compare live in your own database rather than behind an API, use the Postgres connector. It reads new and changed rows and keys them with a primary label, so the same shared value works there.
• If you work with a personal token rather than the App, the GitHub page covers the polled path, where each repository is its own source and commits are keyed owner/repo.
• If the system can call Tares itself, the webhook connector fits better than polling an endpoint.

Related