Changelog

2026-04-03

New

• Watchlist Lock: Administrators can now lock a user's watchlist to restrict API access exclusively to the companies in that watchlist.
  • Scoped Data Access: When locked, the GET /filings/, GET /companies/, and GET /isins/ endpoints automatically return only data for companies on the user's watchlist. This restriction is applied in addition to any existing country or source restrictions.
  • Mutation Protection: All watchlist mutation endpoints (POST /watchlist/companies/, DELETE /watchlist/companies/{id}/, POST /watchlist/companies/bulk-add/, POST /watchlist/companies/bulk-remove/) return 403 Forbidden with a descriptive error message when the watchlist is locked.
  • Lock Visibility: The GET /watchlist/ response now includes an is_locked boolean field, allowing client applications to adapt their UI accordingly (e.g., hiding edit controls).
  • Zero Impact: This feature has no effect on users without a locked watchlist. All existing behavior, response schemas, and performance characteristics are preserved.

Improved

• Company Search Performance: The GET /companies/?search= endpoint has been significantly optimized, reducing worst-case response times from ~1,600ms to ~100ms. This improvement is most noticeable for search terms that previously triggered broad identifier lookups. No changes to the query parameter, search behavior, or response schema — this is a transparent backend optimization.
• Filing Search Performance: The GET /filings/?search= endpoint has been optimized using the same approach, reducing worst-case response times by up to 14x for common search terms. No changes required to existing integrations.
• ISIN Filter Performance: The GET /filings/?company_isin= filter has been re-architected, reducing response times from up to 18 seconds to under 25ms. Clients using ISIN-based filing lookups will see an immediate and significant improvement.

Improved

• Company Search Performance: The GET /companies/?search= endpoint has been significantly optimized, reducing worst-case response times from ~1,600ms to ~100ms. This improvement is most noticeable for search terms that previously triggered broad identifier lookups. No changes to the query parameter, search behavior, or response schema — this is a transparent backend optimization.

2026-04-02

New

• FIGI Identifiers (OpenFIGI Integration): The GET /isins/ endpoint now exposes 8 new fields sourced from the open OpenFIGI registry (ISO 23580), enabling security-level instrument resolution.
  • Identifiers: figi, composite_figi, share_class_figi — the three tiers of the Financial Instrument Global Identifier hierarchy (listing-level, country-composite, and global share class).
  • Classification: security_type, security_type2, market_sector, exch_code — instrument metadata useful for filtering, routing, and portfolio analytics.
  • Freshness: figi_last_updated — timestamp of the last successful enrichment, allowing clients to assess data currency.
  • Coverage: FIGI data is available for the majority of ISINs. Fields return empty strings (or null for figi_last_updated) where enrichment has not yet been performed.

2026-04-01

Fixed

• Pagination Performance: Resolved an issue where GET /filings/ returned 504 Gateway Timeout errors under complex multi-filter queries with large page sizes. Worst-case response times have been reduced from timeout to under 4 seconds. This improvement applies to all paginated API endpoints. No changes to existing integrations required.

2026-03-30

New

• MCP Connector — Write Operations: The MCP server at https://mcp.financialfilings.com now exposes all write endpoints from the 2026-03-29 API update, increasing the total tool count from 33 to 41.
  • watchlist_companies_create: Add a single company to your watchlist.
  • watchlist_companies_bulk_add_create: Add up to 100 companies in a single request.
  • watchlist_companies_bulk_remove_create: Remove up to 100 companies in a single request.
  • webhooks_create: Create a new webhook subscription.
  • webhooks_deliveries_replay_create: Re-send a failed webhook delivery.
  • webhooks_regenerate_secret_create: Rotate a webhook's signing secret.
  • webhooks_test_create: Send a test event to a webhook endpoint.
  • chat_stream_create: Interact with the AI RAG agent via MCP.
• MCP Tool Safety Annotations: Write tools now include MCP protocol annotations (destructiveHint, openWorldHint) to help AI clients distinguish between read-only and mutating operations.

Improved

• MCP Pipeline Reliability: The SDK publication and container deployment pipeline no longer depends on PyPI CDN propagation timing, eliminating intermittent build failures during rapid release cycles.

2026-03-29

Fixed

• Webhook Delivery Logs: Resolved a critical permissions issue where the GET /webhooks/{id}/deliveries/ endpoint returned 403 Forbidden for all users, including those with active paid subscriptions. Delivery logs are now correctly accessible for all Standard Access (Level 1) plans and above.
• Delivery Log Response Schema: The delivery list endpoint previously returned three null fields (request_headers, request_payload, response_headers) that were declared in the schema but did not exist in the data model. These ghost fields have been removed from the list response, eliminating misleading nulls.

New

• Delivery Detail Endpoint: Introduced GET /webhooks/{id}/deliveries/{uuid}/ to retrieve full details for a single delivery attempt.
  • Payload Reconstruction: The response includes the complete request_headers and request_payload that were sent to the user's endpoint, dynamically rebuilt from the referenced filing record.
  • Use Case: Enables debugging of failed deliveries without requiring users to maintain their own request logging infrastructure.
• Delivery Replay: Introduced POST /webhooks/{id}/deliveries/{uuid}/replay/ to re-send a webhook event.
  • Asynchronous Execution: The replay is queued and processed in the background. A new delivery record is created with the result, providing a full audit trail.
  • Use Case: Allows recovery from transient endpoint failures (e.g., a brief outage on the receiving server) without waiting for the next organic filing event.
• Bulk Watchlist Operations: Introduced two new endpoints for managing large watchlists efficiently.
  • POST /watchlist/companies/bulk-add/: Add up to 100 companies in a single request. Companies already on the watchlist are silently skipped.
  • POST /watchlist/companies/bulk-remove/: Remove up to 100 companies in a single request. Companies not on the watchlist are silently skipped.
  • Both endpoints accept a {"company_ids": [1, 2, 3]} request body and return the list of IDs actually affected.
• Webhook Event Documentation: The filing.received webhook event is now documented in the API schema alongside filing.processed, providing a complete data contract for both event types.

Improved

• Watchlist Pagination: The GET /watchlist/ endpoint now returns paginated results using the standard pagination envelope (count, next, previous, results), consistent with all other list endpoints. Previously, large watchlists (up to 1,259 companies) were returned as a single unpaginated response.
  • Backwards Compatible: Clients that do not pass a ?page= parameter will receive the first page of results. The response structure is additive.
• API Documentation Quality: Several schema hygiene improvements to the auto-generated OpenAPI documentation.
  • Removed the internal /mcp/verify/ endpoint and internal chat views from the public schema.
  • Resolved an operationId collision between the delivery list and delivery detail endpoints.

2026-03-26

New

• MCP Server (Claude Integration): Launched a remote Model Context Protocol (MCP) server at https://mcp.financialfilings.com, enabling direct integration with Claude and other MCP-compatible AI clients.
  • Zero-Config Setup: Users can add the server URL as a connector in Claude.ai and authenticate via their existing FinancialReports account. No API key management required.
  • Full API Coverage: All read endpoints from the FinancialReports API are exposed as MCP tools, including filings search, company lookup, markdown content retrieval, and reference data. The tool definitions update automatically when the API schema changes.
  • OAuth 2.1 with PKCE: Authentication follows the MCP authorization specification using AWS Cognito as the identity provider, with full support for Dynamic Client Registration and S256 code challenges.
  • Subscription Required: Access requires an active Analyst or Enterprise subscription. Free-tier users will receive a 403 after authentication.

2026-03-24

New

• API Request Logs: The API Dashboard now includes a dedicated Request Logs page (https://financialreports.eu/accounts/api-dashboard/logs/) providing full per-request visibility for the last 7 days.
  • Detailed Records: Each log entry includes the HTTP method, endpoint path, status code, response latency (ms), IP address, user agent, and precise timestamp.
  • Filtering: Narrow results by status code range (2xx, 4xx, 429, 5xx), HTTP method, endpoint path (substring match), and date range.
  • CSV Export: Export filtered or unfiltered log data for offline analysis, compliance reporting, or integration with external observability tools.
  • Dashboard Summary: The main API Dashboard now displays a real-time "Today's Activity" overview card showing total requests, error rate, and average latency, with a direct link to the full logs page.
  • Scalable Architecture: Log ingestion adds zero latency to API responses. Data is buffered and persisted asynchronously, ensuring no impact on endpoint performance even under high-throughput workloads.

2026-03-22

Improved

• Fiscal Period Data: The detailed Filing object, returned by GET /filings/{id}/ and GET /filings/?view=full, now exposes three new fields providing structured financial period context.
  • New Fields: fiscal_year (integer, e.g., 2025), fiscal_period (enum: FY, Q1, Q2, Q3, Q4, H1, H2), and period_ending_date (date, e.g., 2025-12-31).
  • Coverage: These fields are populated for annual reports, quarterly reports, interim reports, and earnings releases. They are null for other filing types.
  • New Filters: The GET /filings/ endpoint now supports filtering by fiscal_year, fiscal_period, period_ending_date, period_ending_date_from, and period_ending_date_to, enabling precise period-based data extraction (e.g., fetching all Q3 2024 filings across a portfolio).
  • Backwards Compatible: All new fields are additive and nullable. All new filter parameters are optional. No changes required to existing integrations.

2026-03-21

Improved

• Enhanced Company Data (GLEIF Integration): The detailed Company object, returned by GET /companies/{id}/ and GET /companies/?view=full, now exposes legal entity data sourced from GLEIF where available.
  • New Fields: legal_status, legal_form (ISO 20275 ELF code + name), jurisdiction (ISO 3166 code + name), legal_address, legal_city, legal_zip_code.
  • Backwards Compatible: All new fields are additive. Fields without GLEIF coverage return null or an empty string and require no changes to existing integrations.
• Filing Classification Transparency: The detailed Filing object, returned by GET /filings/{id}/, now exposes two new fields providing visibility into the automated classification system.
  • New Fields: filing_type_confidence (float, 0.0–1.0) and filing_type_reasoning (string).
  • Use Case: Allows clients to audit and validate filing type assignments, identify low-confidence classifications, and build trust in the classification pipeline.
  • Backwards Compatible: Both fields are additive and nullable. No changes required to existing integrations.

2026-03-18

Improved

• Universal Render Endpoint: The /filings/render/{id}/ endpoint now natively handles all filing formats via intelligent routing.
  • Automatic Redirects: While originally designed exclusively for ZIP/ESEF extraction, requesting this endpoint for a flat file (e.g., PDF, HTML) will now automatically issue an HTTP 302 redirect to the direct CDN document.
  • Simplified Integration: Clients can now use a single, uniform URL structure for rendering or proxying any filing without needing to implement client-side conditional logic based on the file_extension.
  • Backwards Compatible: Existing ZIP extraction logic remains entirely unchanged, ensuring zero disruption to current automated workflows.

2026-02-25

Improved

• High-Concurrency Infrastructure & Latency Reduction: Deployed a major architectural upgrade to the backend database routing and asynchronous processing layers.
  • Enterprise-Grade Pooling: Transitioned the API to a native asynchronous database driver with optimized transaction pooling. This entirely eliminates connection exhaustion and 500 Internal Server Error timeouts during massive data ingestion spikes or high-frequency webhook bursts.
  • Sub-Millisecond Authentication: Migrated user session validation to a high-performance, in-memory datastore. This removes transactional overhead from the core database, noticeably reducing overall API latency.

2026-02-22

New

• AI RAG Agent API (Beta): Introduced a new suite of endpoints to interact programmatically with the FinancialReports AI Assistant. This allows Level 3 users to build automated Q&A workflows directly against our entire regulatory database.
  • Streaming Chat (POST /chat/stream/): A high-performance Server-Sent Events (SSE) endpoint that streams the agent's real-time reasoning, tool execution, and final markdown response.
  • Session Management: Added endpoints to retrieve chat history (GET /chat/sessions/{id}/messages/), rename sessions (PATCH /chat/sessions/{id}/), and delete sessions (DELETE /chat/sessions/{id}/).
  • Contextual Grounding: The streaming endpoint supports passing specific company_id or filing_ids parameters to strictly constrain the AI's search space to specific entities or documents.
  • Source Citations: Agent responses include an array of citations mapping the exact source text, document URL, and metadata used to generate the answer, ensuring complete auditability.
  • Note: This feature is currently in Beta. Response schemas and event types for the SSE stream are subject to minor modifications based on user feedback.

Improved

• API Tiering Nomenclature: Updated the API documentation to reflect the evolving capabilities of our data tiers. "Level 3 (Extracted Financials)" has been officially renamed to "Level 3 (RAG / Agent)" to better represent the interactive AI tools now available at this tier.

2026-02-21

Improved

• Smart Document Extraction (proxy_url): Added to GET /filings/ and GET /filings/{id}/. This dynamically extracts and serves the main renderable document (HTML/XHTML) from complex ZIP archives (e.g., ESEF, SEC), while safely falling back to the raw CDN link for flat files like PDFs.
• Interactive Web Viewer (viewer_url): Added to list and detail responses, providing a direct deep link to the filing within the FinancialReports web platform for immediate visual analysis and AI Chat.
• Strict Backwards Compatibility: The original document_url and document fields remain entirely unchanged. They continue to return the raw S3 bucket links to ensure zero disruption to existing automated data ingestion pipelines.
• Zero-Latency Implementation: URL generation for these new fields is handled purely in memory, adding 0ms of latency overhead to high-volume paginated API requests.

2026-02-20

New

• Point-in-Time Audit Trails: Introduced a dedicated GET /filings/{id}/history/ endpoint to provide full transparency into record evolution.
  • Data Immutability: Users can now track the complete lifecycle of a filing, specifically monitoring changes to high-value mutable fields such as filing_type (classification), language, and processing_status.
  • Automated Diffing: The response returns a chronological list of state changes, including a changes object that explicitly maps the old value and the new value for every updated field. This eliminates the need for clients to manually store and compare historical snapshots.
  • Audit Compliance: This feature aligns FinancialReports with institutional data standards, allowing analysts to verify exactly when a filing was reclassified or when processing confidence scores were updated.
  • Availability: This endpoint is available immediately for all Standard Access (Level 1) plans and above.

2026-02-19

Improved

• Markdown Availability Visibility: The GET /filings/{id}/markdown/ endpoint now provides explicit status visibility when a markdown file is unavailable.
  • Contextual 404s: Instead of returning a generic "Not found" message, a 404 response will now include a processing_status key (e.g., PENDING, FAILED, SKIPPED).
  • Data Pipeline Resiliency: This allows client engineering teams to programmatically differentiate between a document that is still actively processing versus one that failed extraction, enabling smarter retry logic for bulk downloads and automated ingestion workflows.
  • Backwards Compatible: This is a non-breaking, additive change. The HTTP status code remains 404 Not Found and the original detail key is preserved.

2026-02-16

New

• Annual Report Estimates: Introduced a dedicated GET /companies/{id}/next-annual-report/ endpoint.
  • Predictive Analytics: Utilizes a statistical Density Window Algorithm to forecast the expected release window for a company's next Annual Report based on historical filing density.
  • Actionable Metadata: The response includes the estimated start_date and end_date, a confidence score (0-100), and an is_overdue boolean to immediately flag companies that have missed their expected reporting cycle.
  • Availability: This endpoint is available immediately for all Standard Access (Level 1) plans and above.

2026-02-13

New

• Security Master API (ISINs): Introduced a dedicated GET /isins/ endpoint to resolve International Securities Identification Numbers to legal entities.
  • Portfolio Mapping: The endpoint supports a codes parameter for comma-separated bulk resolution (e.g., ?codes=US0378331005,DE000A1EWWW0). This allows clients to resolve an entire portfolio to Company IDs in a single HTTP request.
  • Hybrid Granularity: Responses include a nested company object (containing id, name, ticker, and country_code). This "Hybrid" design prevents the "N+1 query" problem, giving users immediate context without requiring secondary API calls.
  • Search: Added a search parameter for fuzzy matching, enabling autocomplete experiences (e.g., searching "US03...").

Improved

• ISIN Integration: Extended ISIN-based filtering across the core domain endpoints.
  • Filings: The GET /filings/ endpoint now accepts a company_isin filter, allowing users to fetch regulatory documents directly using a security identifier.
  • Companies: The GET /companies/ endpoint now supports an isin filter for exact entity lookups (case-insensitive).

2026-02-10

New

• Webhook Observability API: Introduced a new GET /webhooks/{id}/deliveries/ endpoint.
  • Audit Logs: Users can now programmatically retrieve the full history of delivery attempts for a specific webhook.
  • Detailed Metrics: The response includes the status (success/failed), response_status_code (e.g., 200, 404, 500), and duration_ms for every event, allowing for automated health monitoring of your integration.
• Dashboard Enhancements: The Webhook Management UI has been upgraded with a dedicated "View Logs" interface.
  • Users can now visually inspect delivery payloads, headers, and error responses directly in the dashboard.
  • Added "Eye" toggle visibility for Secret Keys to prevent shoulder-surfing.

Security

• Secret Key Hygiene: The secret_key field has been removed from the standard GET /webhooks/ and GET /webhooks/{id}/ responses.
  • Display Once: To align with industry security standards (e.g., Stripe, GitHub), the signing secret is now only returned in the API response immediately following creation (POST /webhooks/) or regeneration (POST /webhooks/{id}/regenerate-secret/).
  • Action Required: Clients and developers must store the secret key securely immediately upon generation, as it can no longer be retrieved later via the API.

Improved

• Unified Test Logic: The POST /webhooks/{id}/test/ API endpoint now utilizes the exact same execution pipeline as the Dashboard's "Send Test Event" button.
  • Audit Trail: API-initiated tests now create a persistent WebhookDelivery record, ensuring that automated integration tests leave a visible trace in your delivery logs for debugging.

2026-02-03

New

• Filing Category Filtering: The GET /filings/ endpoint now supports precise filtering by the standardized FRCF categories.
  • Single Filter: category (e.g., ?category=1) for targeted queries.
  • Batch Filter: categories (e.g., ?categories=1,3,9) for multi-category data ingestion workflows (e.g., fetching both "M&A" and "Financial Reporting" simultaneously).
  • These filters utilize the immutable IDs exposed via the GET /filing-categories/ endpoint.

Improved

• Direct Document Linking: Added a document_url field to both the filing list (GET /filings/) and detail (GET /filings/{id}/) responses.
  • Utility: Clients can now access the direct CDN link for the original source document (PDF/HTML/ZIP) immediately from the list view, eliminating the need to query detail endpoints for every item.
  • Zero-Latency Implementation: The URL generation logic uses a high-performance, non-blocking construction method. This ensures that adding this field incurs 0ms of additional latency, maintaining the API's <50ms response standard even on large result sets.

2026-01-30

Improved

• Webhook Delivery Latency: Upgraded the webhook notification infrastructure to a dedicated, high-priority execution pipeline.
  • Impact: Webhook events (filing.received and filing.processed) are now strictly isolated from heavy data processing tasks. This ensures near-instant delivery times (<500ms), even when the system is processing large queues of complex Annual Reports.
• Processing Stability: Implemented "Resource Isolation" for heavy document analysis (PDF/XBRL conversion).
  • Impact: Complex, memory-intensive files are now processed in a segregated environment. This guarantees that deep analysis tasks never degrade the performance of the core API or the timeliness of new data ingestion.

2026-01-28

New

• Event-Driven Webhooks (Fast Lane): Transformed the webhook architecture into a fully event-driven system, offering two distinct subscription modes for high-frequency trading (HFT) and data ingestion use cases.
  • Filing Received (Fast Lane): Introduced a trigger_on_filing_received option. This event fires milliseconds after ingestion, providing immediate awareness of a filing's existence (e.g., for headline trading) before analysis is complete.
    • Note: In this mode, derived metadata (Filing Type, Language) and Markdown content will be null.
  • Filing Processed (Slow Lane): The standard behavior is now explicitly controlled via trigger_on_filing_processed. This event fires only after deep analysis, classification, and markdown conversion are complete, guaranteeing rich metadata.
  • Hybrid Subscription: Users can subscribe to both events to receive an immediate "heads-up" followed by the complete data payload later.

Improved

• Webhook API Schema: Updated the Webhook object and POST /webhooks/ endpoints to support the new event triggers.
  • Backwards Compatibility: The API defaults preserve existing behavior (trigger_on_filing_received=False, trigger_on_filing_processed=True), ensuring no disruption to current integrations.
  • Schema Accuracy: The API schema for the webhook payload has been updated to explicitly mark analysis fields (filing_type, language) and markdown_content as nullable, accurately reflecting the data contract for "Fast Lane" events.

2026-01-22

Fixed

• Rate Limit Exception Handling: Resolved a critical configuration issue where exceeding the "Burst Limit" (e.g., >50 req/s) caused a 500 Internal Server Error instead of a graceful 429 Too Many Requests.
  • Context: A latent path reference error in the settings configuration prevented the new "Smart 429" JSON renderer from loading during high-concurrency spikes.
  • Impact: Automated scrapers and Enterprise clients will now correctly receive the JSON error body with the retry_after_seconds field, allowing for proper exponential backoff.
• Header Injection Reliability: Fixed a regression where X-RateLimit tracking headers were occasionally omitted from responses (returning N/A) due to Nginx URL rewriting.
  • Resolution: The middleware logic now identifies API traffic using a robust "Triple Check" (Host Header, Path, or API Key presence), ensuring accurate quota visibility for every request, regardless of the internal routing path.

2026-01-21

Fixed

• Pagination URL Normalization: Normalized the next and previous cursor URLs in all paginated API responses.
  • Context: Following the "Edge-to-Origin" migration, pagination cursors briefly included a redundant path segment (/api/api/...) due to upstream routing strictness. These URLs now correctly resolve to the root resource (https://api.financialreports.eu/filings/...).
  • Compatibility: This is a non-breaking change. The redundant URLs generated over the last 24 hours remain valid and will automatically redirect to the correct resource, ensuring no disruption to running ingestion pipelines.

2026-01-20

Improved

• Infrastructure Latency Reduction: Successfully completed a major infrastructure migration, moving the API termination point directly to our primary European data center.
  • Architecture: Transitioned from a proxied API Gateway architecture to a direct "Edge-to-Origin" topology.
  • Performance Impact: This removes an entire network hop and a redundant SSL handshake for every request, resulting in an average latency reduction of ~150ms per call.
  • Reliability: Simplified the request routing path, reducing the potential points of failure between the client and the database.

2026-01-19

Improved

• Developer Experience (DX) Overhaul: Major improvements to the Python SDK and API documentation to streamline integration and usability.
  • Zero-Config Python SDK: The generated Python client has been completely re-architected with a new "Facade" pattern.
    • Simplified Usage: Users no longer need to instantiate Configuration or ApiClient objects manually. A single FinancialReports(api_key="...") class now handles everything.
    • Smart Methods: Clean, Pythonic method names (e.g., client.filings.list()) are now standard, replacing the verbose generated names (e.g., filings_api.filings_list()).
    • Async Native: Full support for async/await syntax with proper context manager (async with ...) support for high-performance concurrent requests.
    • Cross-Platform SSL: Embedded certificate handling ensures robust connectivity on all platforms (macOS, Linux, Windows, Docker) without manual certificate configuration.
  • Documentation Clarity: The API documentation now explicitly defines the "Access Levels" (Level 1, 2, 3) directly in the introduction and endpoint descriptions, removing ambiguity about permission requirements.

2026-01-18

New

• Rate Limiting Architecture: Implemented a new dual-layer throttling system to ensure high service availability and fair usage across all tiers.
  • Burst Protection: A high-speed "short circuit" throttle now protects the API against accidental script loops or concurrency spikes (e.g., 50 requests/second for Enterprise).
  • Transparent Headers: All API responses now include standard tracking headers (X-RateLimit-Monthly-Limit, X-RateLimit-Monthly-Remaining, X-RateLimit-Burst-Limit) to help clients monitor their consumption in real-time.
  • Smart 429 Errors: Rate limit exceptions now return a detailed JSON body distinguishing between "Speed Limit" (Burst) and "Budget Limit" (Quota) errors, with specific retry instructions.

Improved

• Middleware Optimization: The Rate Limiting logic utilizes Request-Local Memoization, ensuring that the injection of tracking headers adds zero database overhead to the request lifecycle.
  • This architecture allows even high-volume Enterprise users with massive usage histories to receive accurate "Remaining" counts with no latency penalty.

2026-01-14

Improved

• Core Performance Overhaul: A comprehensive re-architecture of the database and caching layers has resulted in an ~80% reduction in average response times across all endpoints.
  • Redis Connection Pooling: Upgraded the caching infrastructure to use enterprise-grade persistent connection pooling. This eliminates the SSL handshake overhead for every request, significantly improving internal latency.
  • Database Optimization: Optimized query execution plans for the /filings/ and /companies/ endpoints, replacing expensive full-table scans with efficient index-only scans where possible.
• High-Performance Pagination: Implemented a new "Fast Count" pagination strategy to prevent database timeouts on large datasets (10M+ records).
  • Note on Counts: To ensure consistent sub-second latency, the count field in paginated responses is now capped at 10,000 for broad, unfiltered queries.
  • Users can still navigate through all results via the next link, but total record counts for massive result sets are now instantaneous estimates rather than expensive precise counts.

Fixed

• Timeouts: Resolved an issue where the GET /filings/ endpoint would timeout (504 Gateway Timeout) when filtering by broad historical ranges or complex criteria. These queries now execute in under 500ms.

2026-01-10

Improved

• Filing Metadata: The GET /filings/ and GET /filings/{id}/ endpoints now expose two new high-value fields:
  • file_extension (e.g., "PDF", "HTML")
  • file_size (in bytes)
  • These fields empower data pipelines to make intelligent ingestion decisions (e.g., routing based on file type or optimizing storage bandwidth) without downloading the full document.
• Advanced Filtering: The GET /filings/ endpoint has been upgraded with precision filtering capabilities for institutional workflows:
  • Extension Filtering: A new extensions parameter accepts single or comma-separated values (e.g., ?extensions=PDF,XBRL) to filter results by file type (case-insensitive).
  • Size Filtering: New file_size_min and file_size_max parameters allow users to filter out empty placeholders or cap downloads based on file size (e.g., ?file_size_min=1024).
• Documentation: The OpenAPI/Swagger examples have been strictly updated to reflect the new schema, ensuring 100% parity between the documentation and the production API.

2026-01-07

Improved

• Filing Availability Visibility: The GET /filings/ endpoint now exposes a processing_status field for every item in the list.
  • This allows users to immediately identify which filings have processed markdown content available (COMPLETED) versus those that are still PENDING or FAILED, eliminating the need to query individual detail endpoints to check for availability.
  • Performance Optimization: The list endpoint's database query has been optimized to remove heavy text prefetching, significantly reducing memory overhead and response latency while providing this new status visibility.

2025-12-18

New

• Global Webhook Firehose: Introduced a new track_all_companies configuration for webhook subscriptions.
  • Users can now configure webhooks to receive filing.processed events for every company in the database, bypassing the need to add companies to a personal watchlist.
  • This capability is designed for high-volume automated data ingestion and broad market monitoring.
  • The API endpoints POST /webhooks/ and PUT /webhooks/{id}/ now accept a track_all_companies boolean parameter to enable this mode.

Improved

• Webhook Management UI: The Webhook List interface (/webhooks/) now includes distinct visual badges to differentiate between standard "Watchlist" alerts and "Global Firehose" subscriptions, providing immediate clarity on the notification scope.
• Documentation: The Webhook documentation has been updated to explicitly detail the two modes of operation (Watchlist vs. Global), including specific setup instructions and use-case recommendations for the new global tracking feature.

2025-12-12

Improved

• Data Governance & Schema Strictness: Implemented stricter data integrity rules across the Company dataset to align with institutional standards.
  • Mandatory Country Codes: The country_code field is now strictly mandatory. The API schema has been updated from string | null to string, guaranteeing a valid ISO 3166-1 alpha-2 code for every active company profile.
  • LEI Uniqueness: Database-level constraints now enforce uniqueness on the Legal Entity Identifier (LEI). This ensures 1:1 entity mapping and eliminates the possibility of ambiguous duplicate profiles.

2025-11-25

New

• Filing Categories (Disclosure Types): Introduced a new GET /filing-categories/ endpoint.
  • This endpoint exposes the 11 standardized Disclosure Types defined by the Financial Reporting Classification Framework (FRCF), such as "Financial Reporting & Information" and "ESG Information".
  • This completes the API's exposure of the three-tiered FRCF hierarchy, allowing users to programmatically access the top-level classification logic.

Improved

• Filing Types Taxonomy: The GET /filing-types/ endpoint has been significantly enhanced to support the new classification structure.
  • Nested Category Data: Each filing type object now includes a full category object (containing id, name, and sort_order). This is an additive, backwards-compatible change that provides immediate context without requiring additional API calls.
  • Category Filtering: Added a category query parameter (e.g., ?category=1) to filter publication types by their broader disclosure category.
  • Text Search: Added a search query parameter (e.g., ?search=Annual) to perform case-insensitive searches against filing type codes and names.

2025-11-24

Fixed

• URL Generation: Fixed an issue where the markdown_url and document fields could generate incorrect paths when accessed via specific proxy configurations. These fields now strictly enforce absolute URLs (e.g., https://api.financialreports.eu/...), ensuring consistent reachability regardless of the client's network route.

Improved

• Raw Markdown Delivery: The markdown endpoints now return raw, unescaped Markdown text (text/markdown) instead of a JSON-wrapped string.
  • This change ensures that content is immediately renderable by client applications and correctly identified as a file download by browsers.
  • Added a Content-Disposition header to the response to support proper file naming (e.g., filing_12345.md) when saving the output.

2025-11-21

Improved

• Multi-Type Filtering: The GET /filings/ endpoint now supports a new types query parameter.
  • Users can now filter by multiple filing type codes simultaneously using a comma-separated list (e.g., ?types=10-K,10-Q,10-Q).
  • The filter is case-insensitive and automatically sanitizes input, ensuring a robust developer experience even if codes are entered in lowercase.

2025-11-15

New

• Webhook Management API: Introduced a full suite of endpoints for managing webhook subscriptions. Users can now programmatically create, list, update, and delete webhooks to receive real-time notifications for processed filings.
  • GET /webhooks/: List all configured webhooks.
  • POST /webhooks/: Create a new webhook subscription.
  • GET /webhooks/{id}/: Retrieve a specific webhook.
  • PUT /webhooks/{id}/: Update a specific webhook.
  • PATCH /webhooks/{id}/: Partially update a specific webhook.
  • DELETE /webhooks/{id}/: Delete a webhook.
• Webhook Actions: Added two utility endpoints for security and testing:
  • POST /webhooks/{id}/regenerate-secret/: Invalidates the old secret and generates a new one for verifying payload signatures.
  • POST /webhooks/{id}/test/: Sends a sample filing.processed.test event to the configured URL to help debug and validate the client's endpoint.
• Security & Validation: The POST /webhooks/ endpoint now enforces strict validation for the url field, including requiring HTTPS and performing DNS resolution to prevent SSRF (Server-Side Request Forgery) attacks against internal or reserved IP addresses.
• Documentation: The API schema now includes a dedicated "Webhooks" section documenting the filing.processed event. This provides a clear data contract for the payload that will be sent to a user's endpoint, detailing the company and filing objects.

2025-11-13

Improved

• OpenAPI 3.1 Support: The API schema has been upgraded to OpenAPI 3.1.0. This brings full alignment with the latest JSON Schema specifications, enabling seamless integration with modern tools (including OpenAI GPT Actions) and offering improved type strictness for client SDK generation.
• Enhanced Type Definitions: Nullable fields are now explicitly typed using standard arrays (e.g., type: ["string", "null"]) rather than the legacy nullable: true flag. This provides a more precise contract for data consumers.
• Schema Hygiene: Internal session-based utility endpoints (e.g., job status checks) have been removed from the public documentation to reduce noise and focus strictly on API-key authenticated resources.

2025-11-11

Improved

• Enhanced Filtering: The GET /filings/ endpoint now supports a new sources query parameter.
• This parameter accepts a comma-separated list of source IDs (e.g., ?sources=38,40,51), allowing clients to efficiently query for filings from multiple sources in a single API call.
• Stable Pagination: Both the GET /filings/ and GET /companies/ endpoints now support sorting by id (e.g., ?ordering=id or ?ordering=-id). This provides a consistent, incrementing key for more reliable pagination.
• Documentation: API documentation for the ordering and source parameters on these endpoints has been updated to be more explicit and descriptive.

2025-11-08

Improved

• API Consistency: Nested objects within API responses now consistently include their primary id field.
• The source, language, and filing_type objects returned by all endpoints (e.g., GET /filings/, GET /sources/) will now include their id.
• Example: A source object in a filing response will now appear as {"id": 38, "name": "Unternehmensregister", ...}.
• This is a backwards-compatible, additive change that improves the professional standard of the API and allows for simple cross-referencing with their dedicated metadata endpoints (e.g., GET /sources/{id}/).

2025-11-05

New

• Watchlist Filtering: Added a new on_watchlist query parameter to both the GET /filings/ and GET /companies/ list endpoints.
• This powerful boolean filter allows users to scope search results based on their personal watchlist:
  • ?on_watchlist=true: Returns only items from companies on the user's watchlist.
  • ?on_watchlist=false: Returns only items from companies not on the user's watchlist.
  • (Parameter omitted): Returns all items (current default behavior).

2025-10-21

Improved

• The detailed Company object, returned by GET /companies/{id}/ and GET /companies/?view=full, has been updated to include additional data fields.
• The new fields are:
  • Profile: description, description_last_updated, logo
  • Address: address, city, zip_code
  • Identifiers: local_company_id
  • Financials: shares_outstanding
  • Market Data: designated_sponsor, listed_stock_exchange, stock_index
• Database queries for the full company view have been optimized to prefetch these new related fields.

2025-09-15

Improved

• The tagline field has been added to the Company object. This short, one-liner description is now available in both the summary and full views for the GET /companies/ and GET /companies/{id}/ endpoints, as well as in the nested company data within filing responses.

2025-08-19

Improved

• The GET /filings/ endpoint now supports a view=full query parameter. This allows clients to retrieve the complete filing object for each item in the list, providing more detail in a single request.

Fixed

• The updated_date_from and updated_date_to query parameters are now correctly implemented and documented for the GET /filings/ endpoint. This resolves a discrepancy from the 2025-08-12 changelog and enables proper data synchronization based on the last modified date.

2025-08-16

Documentation

• Added new documentation pages explaining the standards for ISIC Classification, Language Codes, Country Codes, and Data Sources (OAMs).

Improved

• The GET /companies/ endpoint now supports a view=full query parameter. This allows users to retrieve the complete company object for each item in the list, restoring access to detailed fields in response to user feedback.

Fixed

• The isins field on the Company object was not appearing in the API documentation for the /companies list and detail endpoints. This has been corrected, and the schema now accurately reflects that isins is an array of strings.

2025-08-12

Improved

• Performance: The list endpoints for /filings/ and /companies/ now return a simplified "summary" response. This significantly reduces payload size and improves response times for list-based queries. The full object details remain available via the detail endpoints (e.g., /filings/{id}/).
• API Structure: Access to processed filing content is now more intuitive. The markdown_url field in the /filings/{id}/ response now links directly to a nested endpoint (/filings/{filing_id}/markdown/), logically connecting the content to its parent filing.
• Documentation: The API documentation has been updated to reflect all recent changes and enhancements.

New

• New Endpoints: Added two foundational endpoints to provide metadata:
  • GET /countries/: Returns a list of all supported countries and their ISO codes.
  • GET /languages/: Returns a list of all supported filing languages.
• New Filtering: Added two new query parameters to the GET /filings/ endpoint to allow filtering by modification date, useful for data synchronization:
  • updated_date_from
  • updated_date_to

Removed

• The standalone GET /processed-filings/{id}/ endpoint has been removed in favor of the new nested markdown content endpoint for better API design and performance.