generated: '2026-08-12'
method: searched
source: >-
  https://developers.feedly.com/reference/introduction,
  https://developers.feedly.com/reference/authorization,
  https://developers.feedly.com/reference/request-limits,
  https://developers.feedly.com/reference/status-codes,
  https://developers.feedly.com/docs/understanding-continuation — fetched 2026-08-12; cross-checked
  against the 18 OpenAPI documents in openapi/.
description: >-
  Cross-cutting request/response semantics that apply to every Feedly API operation and are not fully
  expressed in the OpenAPI documents.

base_url: https://api.feedly.com/v3
api_style: REST over HTTPS, JSON request and response bodies
host_note: >-
  The documentation states all interactions are conducted over HTTPS "from the api.feedly.com domain".
  cloud.feedly.com/v3 is the historical host and still answers (the Authorization page's own curl
  example uses it), but every published OpenAPI servers[] block names api.feedly.com. Prefer
  api.feedly.com.

authentication:
  scheme: Bearer token in the Authorization header
  example: 'Authorization: Bearer <token>'
  token_type: Long-lived enterprise API access token (not OAuth for the REST API)
  provisioning: >-
    Generated by an account admin at https://feedly.com/i/team/api. Self-service tokens are available
    to Enterprise customers only; the token is displayed once and cannot be retrieved again.
  oauth: >-
    The REST API uses static bearer tokens. OAuth 2.1 applies only to the separate Threat Graph MCP
    server at mcp.feedly.com — see authentication/feedly-authentication.yml and mcp/feedly-mcp.yml.
  docs: https://developers.feedly.com/reference/authorization
  detail: authentication/feedly-authentication.yml

idempotency:
  supported: false
  mechanism: null
  note: >-
    Feedly publishes NO idempotency-key header, no request-deduplication window, and no
    Idempotency-Key parameter appears in any of the 18 OpenAPI documents. Retrying a write is not
    server-deduplicated. This matters most on create-or-update-a-webhook (upsert, can produce
    duplicate triggers on retry) and add-articles-to-board. Consumers must reconcile against the
    corresponding list operation after any retried write.

pagination:
  style: cursor (continuation token)
  docs: https://developers.feedly.com/docs/understanding-continuation
  request_params:
    count: Number of items to return, 1-100 (default 20 on Streams).
    continuation: Opaque page token returned by the previous response.
    newerThan: Epoch milliseconds lower bound. Capped at 31 days in the past.
    olderThan: Epoch milliseconds upper bound.
  response_fields:
    id: The streamId used in the initial request.
    updated: Epoch ms timestamp of the response — use as the next poll watermark.
    continuation: Page token; ABSENT when there are no further pages.
    items: Array of results.
  termination_rule: >-
    Stop when `continuation` is absent from the response. An empty items array alone is not a
    reliable terminator.
  supported_on:
  - collect-articles (GET /v3/streams/contents)
  - search (POST /v3/search/contents)
  - getVulnerabilityAgent (POST /v3/trends/vulnerability-dashboard)
  - get-cyber-attacks-agent (POST /v3/ml/relationships/cyber-attacks/dashboard/table)
  - get-custom-agent (GET /v3/custom-agents/{id})
  - the threat-intelligence trending endpoints
  window_limit: >-
    newerThan cannot be older than 31 days. A pipeline stopped for longer than a month cannot backfill
    the gap through the API.

field_expansion:
  supported: false
  note: >-
    No expand[]-style parameter. Related objects are retrieved through dedicated relationship
    endpoints (/v3/ml/relationships/actor/..., /v3/ml/relationships/malware/...) rather than inlined.

sparse_fields:
  supported: false
  partial_flags:
    note: >-
      A few operations carry boolean response-shaping flags rather than a general field selector —
      e.g. includeAiActions and similar on collect-articles, withStats on getEntityDetails.

metadata:
  user_defined_metadata: false
  note: No arbitrary key/value metadata object on Feedly resources.

json_conventions:
  property_naming: camelCase (explicitly not snake_case or kebab-case)
  empty_fields: Blank fields are omitted from responses entirely.
  empty_strings: >-
    Not supported. Use an explicit null to unset a string value rather than "".
  timestamps: >-
    All timestamps are long epoch values in MILLISECONDS (not seconds, not ISO 8601). Some request
    filters — notably the Vulnerability Agent's Custom period — take full ISO 8601 datetimes instead,
    so the two formats coexist and must not be confused.
  identifiers:
    stream_id: >-
      enterprise/<team>/category/<uuid> (folder/AI Feed) or enterprise/<team>/tag/<uuid> (board).
      MUST be URI-encoded when passed as a query parameter.
    entity_id: >-
      Namespaced opaque id, e.g. nlp/f/entity/ioc:<uuid>. MUST be URI-encoded in path position.
    entry_id: Opaque base64-ish string containing / and + characters. URI-encode it.

request_tracing:
  response_header: X-Request-Id
  note: >-
    Present on webhook deliveries and echoed in error bodies as `requestId` on some operations
    (e.g. "853eb1877eebc529-SEA" — the suffix is the edge PoP). The alternate error envelope uses
    `errorId` (e.g. "xyz.2018021111.12345"). Quote whichever is returned when contacting support.
  note_inconsistency: >-
    Two different correlation identifiers (errorId and requestId) appear across two different error
    envelopes on the same API. A consumer must handle both.

versioning:
  scheme: uri-path
  current: v3
  note: >-
    /v3 has been the path segment across the whole documented history. There is no version header, no
    date-pinned version, and no published policy for how a v4 would be introduced or how long v3
    would be supported. Breaking changes are shipped in place — see lifecycle/feedly-lifecycle.yml.

error_envelope:
  shapes:
  - fields: [errorMessage, errorId]
    example: '{"errorMessage":"Invalid JSON", "errorId":"xyz.2018021111.12345"}'
  - fields: [errorCode, requestId, errorMessage]
    example: '{"errorCode":401,"requestId":"853eb1877eebc529-SEA","errorMessage":"must provide authorization token"}'
  problem_json: false
  note: >-
    Not RFC 9457. Two envelope shapes coexist. Resource-specific validation errors are documented on
    the individual resource pages rather than centrally.
  detail: errors/feedly-problem-types.yml

rate_limit_signaling:
  headers: [X-RateLimit-Count, X-RateLimit-Limit, X-RateLimit-Reset]
  exhaustion_status: 429
  retry_after: false
  note: >-
    X-RateLimit-Reset is a COUNT OF SECONDS remaining until reset, not a timestamp. There is no
    Retry-After header, so a client must compute its own backoff from X-RateLimit-Reset.
  detail: rate-limits/feedly-rate-limits.yml

deduplication:
  supported: experimental
  docs: https://developers.feedly.com/docs/removing-duplicates-from-streams-api
  note: Experimental article deduplication on the Streams API. Keep client-side id dedupe regardless.

export_formats:
  note: >-
    Entity endpoints expose export links in STIX 2.1, MISP, CSV and Markdown — the interoperability
    surface that matters most for TIP/SIEM consumers.

cross_references:
  authentication: authentication/feedly-authentication.yml
  errors: errors/feedly-problem-types.yml
  rate_limits: rate-limits/feedly-rate-limits.yml
  lifecycle: lifecycle/feedly-lifecycle.yml
  webhooks: asyncapi/feedly-webhooks.yml
  data_model: data-model/feedly-data-model.yml