> ## Documentation Index > Fetch the complete documentation index at: https://docs.nordicfinancialnews.com/llms.txt > Use this file to discover all available pages before exploring further. # List Exchange Companies > Returns companies listed on a specific exchange, ordered alphabetically. The `ticker` and `exchange` shown for each company reflect its primary listing, which may be on a different exchange if the company is listed on multiple exchanges. ## OpenAPI ````yaml https://nordicfinancialnews.com/openapi/v1/openapi.yaml get /api/v1/exchanges/{identifier}/companies openapi: 3.0.1 info: title: Nordic Financial News API version: v1.0 description: > REST API for Nordic financial news. Each article is summarized in English (headline, short summary, and key points) with the original-language article linked via `article_url`. The full article body stays at the source. ## Authentication All endpoints require Bearer token authentication using an API key. Include the API key in the Authorization header: ``` Authorization: Bearer YOUR_API_KEY ``` ## Rate Limiting The API enforces per-hour rate limits based on your plan: - **Free**: 100 requests/hour - **Pro**: 5,000 requests/hour Rate limit information is included in response headers: - `X-RateLimit-Limit`: Maximum requests per hour - `X-RateLimit-Remaining`: Requests remaining - `X-RateLimit-Reset`: Seconds until limit resets - `X-RateLimit-Policy`: Human-readable rate limit policy (e.g. `5000 per hour; token bucket`) The `/health` endpoint is exempt from rate limiting and does not return rate limit headers. ## Monthly Usage Limits Free and Plus keys have a fixed monthly allowance that resets at the start of each calendar month: - **Free**: 100 requests/month - **Plus**: 100 requests/month Responses on these plans include: - `X-Monthly-Limit`: Maximum requests for the current month - `X-Monthly-Remaining`: Requests remaining this month - `X-Monthly-Reset`: ISO 8601 timestamp when the allowance resets When the allowance is exceeded, the API returns `429 Too Many Requests` with a `Retry-After` header. Pro has no hard limit. It includes 25,000 requests per billing cycle, with usage-based pricing beyond that, so requests are never blocked. Responses on Pro include: - `X-Monthly-Usage`: Requests used in the current billing cycle - `X-Monthly-Reset`: ISO 8601 timestamp when the current billing cycle ends A Pro billing cycle follows your subscription's billing period, which begins on the date you subscribed and is not necessarily a calendar month. Usage is counted by day, so the first day of a billing cycle is counted in full. ## Caching The API supports HTTP caching with ETags. Include the `If-None-Match` header with the ETag from a previous response to receive a 304 Not Modified response if the data hasn't changed. ## Pagination List endpoints support cursor-based pagination. Use the `cursor` parameter with the value from `pagination.next_cursor` in the response to fetch the next page. Paginated responses also include a `Link` header with `rel="next"` pointing to the next page URL. ## Incremental Sync To keep a local copy current, poll `updated_after` — not `published_after`. 1. Request `?updated_after=`. 2. Results are ordered by `updated_at` ascending and cursor-paginated. 3. Follow `pagination.next_cursor`, resending the same `updated_after`, until it is `null`. 4. Only then store the time the sync started, minus a small overlap, as your new watermark. A minute is plenty. Step 3 matters: a response is capped at `limit` (default 25, max 100), so a changed set larger than one page arrives across several. Advancing your watermark before draining every page skips the remainder. The overlap in step 4 matters for the same reason: a record's `updated_at` is set when the write happens, but it only becomes visible when that write commits a moment later. Without an overlap a record can be stamped just before your watermark and land just after it, and you would never ask for it again. Re-reading a minute of changes is cheap and idempotent. `published_at` is editorial time — when the news happened, not when the record reached this API — so a record can appear with a `published_at` older than one you already hold. Records are re-sent when they change, so reconcile by `id`. Removals are not signalled: an article withdrawn from the feed simply stops being returned. Incremental sync tells you what changed, not what disappeared, so treat a local mirror as append-and-update rather than an exact replica. ## Error Handling Errors follow the RFC 9457 Problem Details format with appropriate HTTP status codes. contact: name: API Support email: hello@nordicfinancialnews.com servers: - url: https://nordicfinancialnews.com description: Production server security: [] paths: /api/v1/exchanges/{identifier}/companies: parameters: - name: identifier in: path required: true description: Exchange ID or MIC code (e.g. `XSTO`) schema: type: string get: tags: - Exchanges summary: List Exchange Companies description: >- Returns companies listed on a specific exchange, ordered alphabetically. The `ticker` and `exchange` shown for each company reflect its primary listing, which may be on a different exchange if the company is listed on multiple exchanges. parameters: - name: limit in: query required: false description: Number of companies to return per page (default 25, max 100). example: 25 schema: type: integer - name: cursor in: query required: false description: Opaque pagination cursor from a previous response. schema: type: string responses: '200': description: Exchange companies retrieved successfully content: application/json: schema: type: object properties: companies: type: array items: $ref: '#/components/schemas/CompanySummary' pagination: type: object properties: count: type: integer next_cursor: type: string nullable: true required: - companies '404': description: Exchange not found content: application/json: examples: not_found: value: type: https://docs.nordicfinancialnews.com/problems/not-found title: Not Found status: 404 detail: The requested resource could not be found instance: urn:request:abc123 schema: $ref: '#/components/schemas/problem_details' security: - bearer_auth: [] components: schemas: CompanySummary: type: object required: - id - name - slug - former_tickers properties: id: type: string description: Unique company identifier example: w55fcw3pbg3p name: type: string description: Company name example: Volvo Car AB slug: type: string description: URL-friendly company name example: VOLCAR-B ticker: type: string nullable: true description: Primary stock ticker (null if unlisted) example: VOLCAR-B former_tickers: type: array items: type: string description: >- Tickers the company was formerly listed under — from delisted or renamed listings, excluding any that are still a current ticker. Always present; empty when none. The ticker filter resolves former tickers as well as the current one, so a match on an old ticker still returns the company; this field tells you the ticker you searched by is historical. example: - VOLV is_active: type: boolean description: Whether the company is currently active/operating example: true exchange: type: object nullable: true description: Primary exchange where the company is listed properties: id: type: string description: Exchange identifier name: type: string description: Exchange display name mic_code: type: string description: ISO 10383 Market Identifier Code problem_details: type: object required: - type - title - status - detail - instance properties: type: type: string description: URI that identifies the problem type title: type: string description: Short human-readable summary status: type: integer description: HTTP status code detail: type: string description: Human-readable explanation instance: type: string description: URI that identifies the specific occurrence securitySchemes: bearer_auth: type: http scheme: bearer bearerFormat: API Key description: API Key authentication using Bearer token ````