> ## 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 Event Types > Returns all active event types, grouped by category (in the categories' defined order) and ordered by slug within each. Event type slugs are the values for the `event_type` filter on `GET /api/v1/events`. ## OpenAPI ````yaml https://nordicfinancialnews.com/openapi/v1/openapi.yaml get /api/v1/event_types 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 Rate limits apply per account, shared across every API key on that account — not per individual key: - **Free**: 100 requests/hour - **Plus**: 100 requests/hour - **Pro**: 5,000 requests/hour On Free and Plus, MCP tool calls have their own hourly and monthly allowance and do not count toward these REST limits. On Pro, REST requests and MCP tool calls share one allowance. 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; fixed window`) A single client IP is additionally capped at 300 requests per 5-minute window, so reaching your account's full hourly allowance requires spreading requests across more than one source IP. The `/health` endpoint is exempt from rate limiting and does not return rate limit headers. ## Monthly Usage Limits Free and Plus accounts have a fixed monthly allowance that resets at the start of each calendar month, shared across every API key on the account: - **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 Every list and single-resource endpoint returns an `ETag`. Most also return `Last-Modified` (on lists, when the page is not empty); `GET /stories/{id}` and the Events endpoints do not. Send the ETag back as `If-None-Match`, or the date as `If-Modified-Since`, to receive `304 Not Modified` when nothing has changed. A 304 has no body and does not count against the monthly request allowance. `GET /events`, `GET /events/{id}` and `GET /companies/{identifier}/events` return an `ETag` but no `Last-Modified`, so revalidate those routes with `If-None-Match`. An event's visible company and story membership, and its live article count, all change without moving its `updated_at`, so a date-based validator would report "not modified" across a change the `ETag` catches. Some requests are never cached and return `Cache-Control: no-cache, no-store` with no `ETag`: full-text search (`q`), `updated_after` sync requests, and `GET /search`. The `ETag` reflects the response as served, not only record timestamps. On articles and stories, including the company-scoped routes, and on `GET /calendar_events`, it changes when a plan limit alters the visible set, and on stories when a story's visible article set changes. A changed `ETag` does not necessarily mean a record was updated. On the Events endpoints the `ETag` additionally covers each event's visible company and story ids and its live article count, none of which move the event's `updated_at`. ## 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. A record can therefore 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 signaled: an article withdrawn from the feed 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/event_types: get: tags: - Event Types summary: List Event Types description: >- Returns all active event types, grouped by category (in the categories' defined order) and ordered by slug within each. Event type slugs are the values for the `event_type` filter on `GET /api/v1/events`. parameters: - name: fields in: query required: false description: >- Comma-separated list of fields to include. Available fields: `id`, `slug`, `label`, `category`, `summary`. `id` is always included. example: id,slug,label schema: type: string responses: '200': description: Event types retrieved successfully content: application/json: examples: basic_response: value: event_types: - id: evt_earnrep01 slug: earnings-report label: Earnings Report category: earnings summary: >- A company's scheduled quarterly, interim or annual results without consensus framing. pagination: count: 1 next_cursor: null schema: type: object properties: event_types: type: array items: $ref: '#/components/schemas/EventTypeSummary' pagination: type: object properties: count: type: integer next_cursor: type: string nullable: true required: - event_types '401': description: unauthorized content: application/json: examples: unauthorized: value: type: https://docs.nordicfinancialnews.com/problems/auth-invalid title: Unauthorized status: 401 detail: Missing or invalid API key instance: urn:request:abc123 schema: $ref: '#/components/schemas/problem_details' '403': description: forbidden - missing scope content: application/json: examples: forbidden: value: type: >- https://docs.nordicfinancialnews.com/problems/auth-insufficient title: Forbidden status: 403 detail: Insufficient scope for this resource instance: urn:request:abc123 schema: $ref: '#/components/schemas/problem_details' security: - bearer_auth: [] components: schemas: EventTypeSummary: type: object required: - id - slug - label - category - summary properties: id: type: string description: Unique event type identifier example: evt_earnrep01 slug: type: string description: >- Event type slug: the value for the `event_type` filter on `GET /api/v1/events` only. `GET /api/v1/calendar_events` takes a different, underscored vocabulary enumerated on that endpoint; these slugs are not accepted there, and a few spellings overlap while denoting different things. example: earnings-report label: type: string description: Event type display label example: Earnings Report category: type: string description: The broader category this type belongs to enum: - earnings - ma - executive_changes - regulatory - dividends - equity_actions - legal - credit - bankruptcy - partnerships - products - restructuring - macro - funding - esg - operations - analyst_ratings - shareholder_activity - other - commentary example: earnings summary: type: string nullable: true description: One-line description of what this type covers example: >- A company's scheduled quarterly, interim or annual results without consensus framing. 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 ````