OpenFIGI Pricing: Free Access & Rate Limits (2026)

Pricing overview

OpenFIGI provides a free-to-use API service designed for mapping various security identifiers to Financial Instrument Global Identifiers (FIGIs). Unlike many financial data providers, OpenFIGI does not implement a tiered subscription model or charge per API call. Instead, its operational costs are supported by Bloomberg L.P., allowing the service to be offered freely to a broad audience, including individual developers, academic institutions, and commercial enterprises. The primary constraint on usage is a system of rate limits, which are applied to ensure equitable access and system stability.

The core value proposition of OpenFIGI's pricing strategy is its zero-cost access to a standardized identifier mapping service. This approach significantly lowers the barrier to entry for projects requiring reliable financial instrument identification, as users do not incur direct costs for API usage. The emphasis is on managing demand through transparent rate limits rather than monetizing access. This model contrasts with traditional financial data vendors who typically charge based on data volume, user count, or specific data entitlements. Developers can integrate OpenFIGI into their applications without budget considerations for API calls, provided their usage adheres to the published rate limits, which are designed to accommodate a wide range of use cases.

Plans and tiers

OpenFIGI operates without distinct pricing plans or tiers. All users, regardless of their intended use case (commercial or non-commercial), access the same API with the same capabilities. There are no premium subscriptions, enterprise plans, or usage-based charges. This simplified model ensures that all users benefit from the full functionality of the FIGI Identifier Mapping API without having to navigate complex pricing structures or upgrade paths. The uniformity of access means that the only differentiator in terms of usage is adherence to the technical rate limits.

The absence of tiered plans means that features such as bulk lookup, historical data mapping, or specific instrument types are available to all users equally. This inclusive approach simplifies integration for developers, as they do not need to consider different API endpoints or authentication methods based on a chosen plan. The focus remains on providing a single, consistent interface for identifier mapping. The OpenFIGI documentation specifies the technical details of the API, including request formats and response structures, which apply universally to all users. This contrasts with services that might offer varying levels of data granularity or API performance depending on an activated subscription level.

For operations requiring higher throughput than the standard free limits, users are generally advised to optimize their requests or consider architectural patterns that minimize call frequency. While OpenFIGI itself does not offer paid tiers for increased limits, its model encourages efficient use of the API. This unified approach simplifies governance and allows developers to scale their applications within the defined technical boundaries without financial penalties for increased usage, making it a cost-effective solution for many financial data integration challenges. Further details on API usage and best practices are available in the official OpenFIGI API documentation.

Free tier and limits

OpenFIGI's entire service functions as a permanent free tier. There are no paid options to increase limits or unlock features. Access to the API is granted upon registration, and users receive an API key that authenticates their requests. The service is designed to be accessible without direct financial cost to the user, making it a valuable resource for developers and organizations who need to standardize financial instrument identification.

The primary control mechanism for usage is a set of defined rate limits. These limits are in place to manage server load, ensure fair access for all users, and prevent abuse. While the exact numerical limits can be subject to change and are detailed in the official documentation, they typically involve restrictions on the number of requests per minute and/or per day. For example, a common rate limit might allow a certain number of mapping requests within a 60-second window, with additional daily aggregate limits.

Specific rate limits published by OpenFIGI include a general limit of 25 requests per 5-second interval and 250 requests per minute for the mapping endpoint. For the reference data endpoint, the limit is 10 requests per 5-second interval and 100 requests per minute. Batch requests are also subject to limits, with a maximum of 100 instruments per batch request. These limits are applied per API key. Users exceeding these limits will receive HTTP 429 Too Many Requests responses. The stated limits are typically sufficient for development, testing, and many production scenarios, especially when requests are batched and optimized. Developers should implement robust error handling and retry mechanisms with exponential backoff to manage rate limit responses effectively. Comprehensive details on current rate limits are available on the OpenFIGI developer documentation page.

Real-world cost examples

Given that OpenFIGI is entirely free, real-world cost examples revolve around the operational costs associated with integrating and maintaining the API, rather than direct API usage fees. These costs would include developer time, infrastructure for hosting applications that consume the API, and any monitoring or logging solutions implemented.

Scenario 1: Small-scale application for personal use

• Use Case: A personal portfolio tracker that maps security tickers to FIGIs daily for a small set of holdings.
• API Calls: 10-20 requests per day to update a personal portfolio of 10-20 securities.
• Direct Cost: $0.00.
• Indirect Costs: Minimal. Primarily the developer's time to write the integration code (e.g., a Python script). Hosting might be on a free tier cloud service or a local machine, incurring no additional infrastructure costs.
• Feasibility: Easily within OpenFIGI's free rate limits.

Scenario 2: Startup using OpenFIGI for data standardization

• Use Case: A fintech startup building a platform that requires standardized identifiers for thousands of securities. They need to map new securities as they are added and periodically re-verify existing ones.
• API Calls: Potentially thousands of requests per day, batched for efficiency. For example, 5,000 unique securities updated daily, using batch requests of 100 instruments each, would require 50 API calls to the mapping endpoint per day.
• Direct Cost: $0.00.
• Indirect Costs: Developer time for initial integration, setting up a robust queuing and retry mechanism to handle rate limits, and ongoing maintenance. Cloud infrastructure costs for running the service (e.g., AWS Lambda, Google Cloud Run) would be incurred based on compute and storage usage, not API calls. These costs are typically in the range of tens to hundreds of dollars per month depending on scale and complexity.
• Feasibility: Achievable by carefully managing request volume, utilizing batching, and implementing retry logic. For very high-volume, real-time needs exceeding thousands of calls per minute, a dedicated commercial solution might be considered, but OpenFIGI often suffices with proper design.

Scenario 3: Academic research project

• Use Case: Researchers needing to map a large dataset of historical security identifiers (e.g., CUSIPs, ISINs) to FIGIs for analysis. This might involve a one-time bulk mapping of tens of thousands to millions of identifiers.
• API Calls: Spikes of high volume for initial mapping, then infrequent smaller requests for new data. A dataset of 100,000 securities mapped in batches of 100 would mean 1,000 API calls. If executed over several hours or days, this would comfortably fit within daily rate limits.
• Direct Cost: $0.00.
• Indirect Costs: Researcher or developer time for scripting the data ingestion and mapping process. Compute resources for running the mapping scripts.
• Feasibility: Highly feasible. The free nature makes it ideal for academic budgets. The mapping process can be designed to run asynchronously over an extended period to stay within rate limits.

In all scenarios, the direct financial cost of using the OpenFIGI API remains zero. Any costs incurred are related to the development, deployment, and operational overhead of the consuming application, which would be present regardless of the API's pricing model.

How the pricing compares

OpenFIGI's free pricing model stands in stark contrast to the offerings of most commercial financial data providers. Traditional vendors in this space typically employ subscription-based models, usage-based pricing, or a combination thereof, often with significant costs associated with data access and redistribution rights.

Here's a comparison of OpenFIGI's model against typical alternatives:

Alternatives like Refinitiv and FactSet offer extensive financial data services that go far beyond identifier mapping, including real-time market data, historical prices, fundamental data, news, and analytics. These services are typically enterprise-grade and come with significant costs, often requiring direct engagement with their sales teams for custom quotes. Similarly, SIX Financial Information provides a suite of financial data and services, including instrument data, pricing, and corporate actions, also at a premium cost.

The key differentiator for OpenFIGI is its specialized focus on the identifier mapping problem and its commitment to being a free, open standard, under the sponsorship of Bloomberg L.P. While it doesn't offer the breadth of data found in commercial platforms, its zero-cost model for its specific function makes it an invaluable tool for developers and organizations who need reliable and standardized security identifiers without incurring direct financial data costs. For many use cases, OpenFIGI effectively addresses the need for identifier mapping, allowing budgets to be allocated to other aspects of application development or data analysis.

Therefore, when evaluating OpenFIGI, it's crucial to understand that its competitive advantage lies in its cost-free, focused utility rather than attempting to compete directly on the sheer volume or variety of data offered by comprehensive, paid financial information platforms. It serves as an excellent complementary tool to other data sources, or as a standalone solution for projects specifically requiring robust identifier resolution.