Hoppa till innehållet
Sursa Developers

GET/v1/cards/{card_id}/threads

Lista kommentarstrådar för ett kort

list_card_threads

Kommentarstrådar ovanpå de platta kommentarerna i POST /v1/cards/{card_id}/comments, som fortsätter att fungera: första kommentarer med statusen open | resolved, en förankring i ett fragment, kortversionen, svar och reaktioner (count, shortcode, current_user_reaction_id). Ett meddelande är en kommentar med extra_details.type = announcement. Kräver CARD_VIEW. Med updated_since returneras de trådar där den första kommentaren eller något av svaren skapades eller ändrades vid eller efter den tidpunkten (en kommentar som aldrig har ändrats har updated_at = null, och då räknas dess created_at). En tråd kommer i sin helhet, sorterad efter den tidpunkten i stigande ordning och sedan efter id.

Autentisering

Skicka en API-nyckel i huvudet Authorization: Authorization: Bearer <nyckel>.

Sökvägsparametrar

  • card_idstringobligatorisk

Frågeparametrar

  • open (standard) eller resolved.

  • updated_sincestring (date-time)

    Bara objekt med updated_at vid eller efter den här tidpunkten (RFC 3339 med tidszonsförskjutning), för synkning. Med den sorteras listan efter updated_at i stigande ordning och sedan efter id, och markören fortsätter i den ordningen. Borttagna objekt listas inte: borttagningar kommer som händelser.

    length ≤ 512

Svar

200Lyckat svar

Svarshuvuden

  • RateLimit-Policy

    Gällande gränser i formatet från IETF-utkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerade poster "<name>";q=<quota>;w=<window in seconds>. key är API-nyckelns anropsfrekvens (kvoten är toppen (burst), fönstret är tiden tills den har fyllts på helt; för en session är det user, utan autentiseringsuppgifter ip); minute, day och month är organisationens kvoter för kalenderminuten, kalenderdygnet och kalendermånaden i UTC.

  • RateLimit

    Vad som återstår av varje gräns i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Gränsen för den striktaste posten i RateLimit-Policy (den med minst antal återstående anrop).

  • X-RateLimit-Remaining

    Återstående anrop inom den striktaste gränsen.

  • X-RateLimit-Reset

    Sekunder tills den striktaste gränsen nollställs.

application/json

Objekt: ThreadList

  • itemsarray of Threadobligatorisk
401Inga autentiseringsuppgifter skickades (varken en sessionscookie eller en API-nyckel), eller så hittades inte nyckeln.

Svarshuvuden

  • RateLimit-Policy

    Gällande gränser i formatet från IETF-utkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerade poster "<name>";q=<quota>;w=<window in seconds>. key är API-nyckelns anropsfrekvens (kvoten är toppen (burst), fönstret är tiden tills den har fyllts på helt; för en session är det user, utan autentiseringsuppgifter ip); minute, day och month är organisationens kvoter för kalenderminuten, kalenderdygnet och kalendermånaden i UTC.

  • RateLimit

    Vad som återstår av varje gräns i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Gränsen för den striktaste posten i RateLimit-Policy (den med minst antal återstående anrop).

  • X-RateLimit-Remaining

    Återstående anrop inom den striktaste gränsen.

  • X-RateLimit-Reset

    Sekunder tills den striktaste gränsen nollställs.

application/json

Objekt: Error

404Objektet finns inte eller är inte tillgängligt för dig. API:et bekräftar inte att ett begränsat objekt finns.

Svarshuvuden

  • RateLimit-Policy

    Gällande gränser i formatet från IETF-utkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerade poster "<name>";q=<quota>;w=<window in seconds>. key är API-nyckelns anropsfrekvens (kvoten är toppen (burst), fönstret är tiden tills den har fyllts på helt; för en session är det user, utan autentiseringsuppgifter ip); minute, day och month är organisationens kvoter för kalenderminuten, kalenderdygnet och kalendermånaden i UTC.

  • RateLimit

    Vad som återstår av varje gräns i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Gränsen för den striktaste posten i RateLimit-Policy (den med minst antal återstående anrop).

  • X-RateLimit-Remaining

    Återstående anrop inom den striktaste gränsen.

  • X-RateLimit-Reset

    Sekunder tills den striktaste gränsen nollställs.

application/json

Objekt: Error

429För många anrop (`api.rate_limited`), organisationens kvot för minuten, dygnet eller månaden är förbrukad (`api.quota_exceeded`; `error.details` innehåller `quota`, `limit` och `reset_at`), organisationens gräns är nådd eller svarstjänsten är upptagen (`answers.engine_busy`). Vänta den tid som anges i huvudet `Retry-After`.

Svarshuvuden

  • Retry-After

    Antal sekunder att vänta innan du skickar anropet igen.

  • RateLimit-Policy

    Gällande gränser i formatet från IETF-utkastet draft-ietf-httpapi-ratelimit-headers: kommaseparerade poster "<name>";q=<quota>;w=<window in seconds>. key är API-nyckelns anropsfrekvens (kvoten är toppen (burst), fönstret är tiden tills den har fyllts på helt; för en session är det user, utan autentiseringsuppgifter ip); minute, day och month är organisationens kvoter för kalenderminuten, kalenderdygnet och kalendermånaden i UTC.

  • RateLimit

    Vad som återstår av varje gräns i RateLimit-Policy: "<name>";r=<remaining>;t=<seconds until reset>.

  • X-RateLimit-Limit

    Gränsen för den striktaste posten i RateLimit-Policy (den med minst antal återstående anrop).

  • X-RateLimit-Remaining

    Återstående anrop inom den striktaste gränsen.

  • X-RateLimit-Reset

    Sekunder tills den striktaste gränsen nollställs.

application/json

Objekt: Error

Felkoder

Koder som den här slutpunkten kan returnera i error.code, utöver de allmänna koderna för alla anrop.

Hastighetsbegränsningar

Svaren innehåller huvudena RateLimit och RateLimit-Policy samt de tidigare X-RateLimit-Limit, X-RateLimit-Remaining och X-RateLimit-Reset. Ett 429-svar har Retry-After i sekunder: vänta och försök igen.

← comments · API-referens