Endpoints

List jobs

Roles across every board you track, newest first.

GET/v1/jobs

curl -X GET "https://api.slashtrace.com/v1/jobs?addedAfter=2026-08-24T12%3A00%3A00Z&limit=50" \
  -H "Authorization: Bearer $API_KEY"

Scoped to the boards on your own list, always. A board you do not track cannot be reached through this endpoint even if you know its id, and a board that is locked — tracked but past your plan’s limit — contributes nothing, because it is never read.

company is denormalised onto every row so a list is legible without a second call. It is null until a board’s first scrape has identified the company.

Reading never triggers a fetch. You get what the last scheduled read found; nothing here goes out to the careers page and makes you wait for it.

Query parameters

boardIdstring: Only roles from this board. An id you do not track returns an empty list rather than that board's jobs.
addedAfterISO 8601: Only roles first seen strictly after this instant. Pass back the polledAt from your last response — see below.
statusopen | closed | all default open: Open roles are still on the board. Closed ones were there and have gone; they sort by when they closed, not when they appeared.
searchstring: Case-insensitive match on the job title.
locationstring: Case-insensitive match on the location as the board wrote it. It is free text on their side, so 'Berlin' will not catch 'DE — Remote'.
limitinteger default 50: 1 to 100.
skipinteger default 0: Paging offset. The sort is deterministic, so paging does not repeat or drop rows.

Response

200 OK

{
  "jobs": [
    {
      "id": "6a8cbf4cde26f685eabcfc0a",
      "boardId": "6a86f2675d98a41a50f70083",
      "company": "Clay",
      "title": "Senior Backend Engineer",
      "location": "New York, NY",
      "department": "Engineering",
      "url": "https://www.clay.com/careers/senior-backend-engineer",
      "status": "open",
      "firstSeenAt": "2026-08-24T22:01:48.814Z",
      "lastSeenAt": "2026-08-25T09:14:02.113Z",
      "closedAt": null
    }
  ],
  "total": 312,
  "polledAt": "2026-08-25T12:39:41.877Z"
}

Error responses

400 · invalid_request

{
  "error": {
    "code": "invalid_request",
    "message": "Some of those query parameters were not valid.",
    "details": [
      {
        "path": "addedAfter",
        "message": "Expected an ISO 8601 date, e.g. 2026-08-24T09:00:00Z"
      }
    ]
  }
}

429 · rate_limited

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit of 10 requests per minute exceeded. Retry in 35s.",
    "retryAfter": 35
  }
}

Polling for what is new

addedAfter filters on firstSeenAt — when we first saw the posting, not a date the employer published. That is the only honest timestamp available: job boards publish dates that are variously absent, relative (“2 days ago”) or simply the day the listing was last edited, and none of them survives being compared across providers.

Every response carries polledAt. Pass it back as the next request’s addedAfter rather than computing now - 24h yourself:

polledAt is stamped before the query runs, so a role written while the query was in flight is returned again next time rather than falling into the gap between two client-side timestamps and being missed forever.
It is the server’s clock. A client whose clock runs two minutes fast silently skips two minutes of roles on every poll.

Duplicates are possible at the boundary and are the deliberate trade: deduplicate on id. A repeat is a nuisance; a miss is a role your integration never hears about.

One wrinkle worth knowing. When a board is first added, its entire back catalogue is discovered in one read, so every role on it shares a single firstSeenAt. A poller that added a board yesterday will see that whole board as “added in the last 24 hours”, once. It settles after the first read.