Bring Your Own Key (BYOK): How to Ship an App Without a Market Data Redistribution License

The same email reaches us about once a month, and the answer is a model called BYOK. A developer has built a desktop app, a mobile app, or a charting indicator for options or stock traders. They want to ship it. Then they read about OPRA fees or equity licensing and learn that a market data redistribution license costs thousands of dollars a month before the first customer pays.

So they ask: “What if each of my users signs up for their own Market Data account and pastes their own API key into my app? Does that make it legal?”

The answer is yes, and it has a name: Bring Your Own Key, or BYOK. As of September 2026 we have answered that question in ten separate threads since January, from a desktop options analyzer, an iPhone position tracker, a NinjaTrader indicator, a wheel-strategy phone app, and a Spanish-language web app for a trading community. Three of them are in production on this model today. For an app that shows current prices, it is the cheapest compliant way to ship, and it costs you nothing in licensing fees.

One thread shows the whole process. In August 2026 the developer of a Windows desktop app for options traders wrote to ask whether each of his users could subscribe to us directly and paste their own key into his program. We said yes, on one condition, and explained the condition. Two days later he wrote back: he had finished the integration, removed his previous data provider from the product entirely, and every request now went from our servers to the user’s desktop with the user’s own token. The whole thread was three messages and no contract.

The condition is an architectural rule, and the rest of this guide is about building inside it.

What Is BYOK?

Bring Your Own Key (BYOK) is an app design in which each user holds their own Market Data subscription and API key, so the data travels from us to that user and never through you.

Under a conventional data license, there are two parties: the data vendor and you. You buy the data and you show it to your users, which means you redistribute market data. Market data redistribution is the delivery of exchange data to other people by anyone other than the exchange or its licensed vendor, in raw or derived form. The exchanges attach vendor agreements, per-user fees, subscriber agreements, monthly reporting, and audits to that status.

Under BYOK there are still two parties in the data relationship, but you are not one of them. The two parties are Market Data and your end user:

1. Your user creates their own Market Data account and chooses their own plan.
2. Your user completes our account verification and, for real-time data, signs the exchange subscriber agreement with us.
3. Your user receives their own API key and enters it into your application.
4. Your application calls our API from the user’s own device, using the user’s own key.
5. We deliver the data directly to that user’s device, under that user’s entitlement.

You provide the software, and we deliver the data to the user under our own exchange licenses. Your app is a client that the user runs. You never take delivery of the market data, so you never become a redistributor, and none of the redistributor obligations attach to you.

The One Rule: Never Take Possession of the Data

The test is architectural:

The data must travel directly from our servers to your end user’s device, and it must be processed on that device. It cannot pass through infrastructure that you control.

Which market the data came from changes nothing in that test. Options and equities pass or fail it together, and so does anything your app calculates from either.

What the market changes is the paperwork we carry for you: an OPRA Vendor Agreement for options, an equity redistribution license for stocks. BYOK removes the need for both, on the same terms.

If your server sits anywhere in the path between us and the user, you have taken possession of the data, and the moment you take possession you are a redistributor. Storing it, charging for it, or reformatting it makes no difference, and neither does whose API key made the request. A request made from your server with the user’s key is still a response that landed on your server.

The exchanges define redistribution this way, and we cannot waive it.

Which Obligations Move to Us Under BYOK?

The compliance obligations do not disappear under BYOK. They transfer to us, because we are the vendor delivering the data to each user. For an app that shows options data, that means you do not carry:

• An OPRA Vendor Agreement, or the $1,500 a month redistributor fee that comes with it. Fees in this guide are OPRA’s published schedule as of September 2026.
• Per-user display fees for real-time data: $1.25 a month for each non-professional user and $31.50 for each professional.
• Non-display use fees, which OPRA charges a product that runs calculations on real-time data on its own servers, whether or not the result is ever shown: $2,000 a month per category of use.
• Subscriber agreements collected and stored from every user.
• Professional versus non-professional classification of your users. The exchanges charge a professional, broadly anyone who trades for a living or holds a securities registration, 25 times the non-professional display fee, and the vendor has to decide which each user is. Professional status explained covers the test.
• Monthly subscriber reporting to OPRA.
• Exchange audits.

For an app that shows stock data, the same applies to the equity feeds, and to the equity redistribution license you would otherwise need before you could redistribute market data at all. The figures are from our stock licensing guide:

All of it stays on our side, at no charge to you. The only cost in the system is your users’ own subscriptions, which they would pay for any market data tool they chose to run.

Which Architectures Avoid Market Data Redistribution

Developers apply the rule to many designs, and some of them fail the test in ways that are not obvious. This table covers the cases we are asked about most often.

Developers sometimes propose the server-side variants with genuine care: the server “acts only as the user’s agent,” results are “stored against that user and never shared,” the key is “never exposed.” None of that changes the answer. The nightly-sweep row above is a real case from August 2026: a developer screening roughly 2,400 US symbols every night asked whether a server fetching with each user’s own key was still BYOK, because a phone cannot make 2,400 requests before the open. It was not, and he chose historical data instead, which carries no exchange fee at all. If you need a server in the data path, BYOK is not your model, and the section at the end of this guide covers what is.

Not every distribution model is a fit for BYOK, and not every one is a fit for a self-service Market Data plan. Our sales team works with every developer who asks, and we have partnerships in place for the models we do not serve ourselves. Whichever way your product needs to move data, get in touch before you build and we will direct you to the path that fits.

Calculations, Derived Values, and Local Storage

A common worry is whether your app is allowed to do anything with the data beyond display it. It is. Under BYOK, the user is entitled to the data, and your app is the tool they use to work with it.

• You may run calculations on the data, as long as they run on the user’s device. Greeks, implied volatility surfaces, gamma exposure levels, unusual-volume rankings, portfolio valuations, backtests over the user’s own history: all fine, all on the client.
• You may keep the results inside your app. Computed levels, a cache of recent responses, and historical snapshots can persist in the app’s own storage on the user’s machine and be drawn on historical charts later. They cannot leave the app: no export, no save-to-file, no copy to another program. See the section on keeping data inside the app.
• You may show the raw data too. You do not need to hide chains, quotes, or Greeks behind derived values. We are the licensed vendor delivering that data to the user, so the user is allowed to see it in your app.
• You may not centralize any of it. The calculation that would be fine on the user’s laptop is redistribution the moment you move it to your server, even if only the derived output ever reaches the user.

How to Build the Integration

1. Onboarding: two sign-ups, and say so

Your user has to create a Market Data account in addition to whatever account they have with you. Be upfront about it. The apps that do this well show a short setup screen that explains why the key is needed, links to our sign-up page, and provides a field to paste the key.

Set expectations about verification. Before we activate real-time data on a paid plan, our compliance team verifies each user’s identity and employment against a public profile or a CV, and completes the check within one business day of receiving the information. OPRA audits the classification and bills a vendor retroactively for every user it got wrong, so we check every user rather than trust a checkbox. Tell users about the step during onboarding, and it stays a one-day delay instead of a support ticket.

Users our compliance team classifies as professionals will not receive real-time data on a self-service plan. Your app should handle a delayed or historical entitlement gracefully rather than assume every key returns live quotes. If your product is aimed primarily at financial professionals, BYOK is not the right fit, and you should contact us to discuss the alternatives.

2. The key stays on the device

Treat the user’s API key the way you would treat their brokerage password:

• Store it in the operating system’s credential store, or encrypted at rest on the device.
• Never transmit it to a server you control, and never log it.
• Let the user replace or remove it from within your app.

A key that never leaves the device is also a key that no server of yours can use by mistake.

3. Requests come from the device, with your app identified

Every API request must originate from the user’s device, and every request must carry a unique User-Agent header that names your application and version. A chain request from a desktop app looks like this:

curl -H "Authorization: Bearer <the user's token>" \
     -H "User-Agent: strikefinder/2.3.1" \
     "https://api.marketdata.app/v1/options/chain/AAPL/?mode=cached"

The user agent is what lets us see, on our end, which of our users are using your application. That matters for two reasons. It lets us attribute your users to you under the affiliate program described below, even when they did not arrive through your link. And we are planning to give BYOK developers a way to review the API activity of users running their app, so that you can support your own users without asking them to forward error messages. An app that already sends its own user agent will be ready for that the day it ships.

4. Use cached mode for option chains

Every plan is measured in credits, a daily allowance that each request draws down. On a paid plan a live option chain costs one credit for every contract in the response, so a full SPX chain of 22,718 contracts costs 22,718 credits in a single request. The same request with mode=cached costs one credit, whatever the size of the chain. Cached responses come from a layer we refresh for every customer and may be a few seconds to several minutes old, which is what most display and analysis workloads need. On the free plan the parameter is ignored: every request returns the previous session’s data at one credit per thousand contracts, so cost is rarely the constraint there. See the option chain endpoint documentation for the credit table.

5. The data stays inside your app

BYOK works because each user’s key delivers data to that user, for use inside the tool they are running. The data cannot leave that tool. This is the rule that decides whether BYOK is available to your product at all, so read it as a hard boundary rather than a guideline:

• No export. Your app may not write market data to a file, a clipboard, a spreadsheet, a database the user can open, or any format that lets the data be used outside your app. That includes CSV downloads, “save chain” buttons, copy-to-clipboard on a quote table, and sync features to other programs.
• No onward delivery. Your app may not expose the data through an API, a feed, a webhook, a plugin interface, or a scripting hook that another program can call.
• No sharing between users. Do not build features that pass quotes, chains, or derived values from one user to another, through your systems or through the app itself.
• One person, one account, one key. A key may not be used by several people. This applies inside a company too: a business owner and their QA tester each need their own account.

BYOK is not available to apps that are designed for data export. A tool whose purpose is to get market data into a spreadsheet, a database, a file, or another program is a redistribution product, whatever key it runs on. If that describes your app, contact us and talk to sales about commercial licensing before you build on this model.

We verify BYOK apps annually. Once your app is in use, we review it each year to confirm the data still stays inside it and the rules above still hold. Build with that review in mind, and it will take a few minutes.

6. Work with our account-sharing controls, never against them

The exchanges license market data to one person per subscription, and enforcing that is a condition of our own licenses. Our API uses technical measures to detect and prevent account sharing, including limits on simultaneous use of one key from more than one place. Those measures apply to every request your app makes, and your users will encounter them if they try to run one key on several machines at once.

Two things follow for you as the developer:

• Your app has to enforce the same rule on its side. Do not build multi-seat, team, or “share this login” features around a single key. Do not pool keys, rotate keys, or route requests in a way that makes several people look like one subscriber. If your product needs multiple users on one purchase, that is a commercial license, not BYOK.
• Work with the controls, and talk to us when they do not fit. Our terms do not allow an app to work around account-sharing detection or the other controls we operate for the exchanges, and an app built that way cannot stay on BYOK. If your product needs something those controls do not allow, talk to our sales team about commercial licensing. That is a conversation we have every week, and sales will find the licensing path that fits.

7. Design around the plan your user chose

Under BYOK, the user picks the data plan, not you. Your app should work sensibly across all of them:

This is also your free tier, if you want one. Every Market Data account includes the Free Forever plan and a 30-day free trial of the paid plans, so a free edition of your app can run on a user’s free key at no data cost to you. Users who want faster data upgrade their own plan with us, and if you are an affiliate, you earn on that upgrade.

Budget credits accordingly. A free-plan user has 100 credits a day, and a 1,000-contract chain refreshed every 15 seconds spends that in 25 minutes. Poll at intervals that suit the user’s plan and prefer cached requests.

Handle the three responses a user’s plan can produce, with a message rather than a blank screen: a 429 when the day’s credits are spent, a 402 when the plan does not include the data or parameter requested, and a 403 when one key has sent requests from two IP addresses inside five minutes, which is the account-sharing control from step 6 and clears itself after five minutes with no requests. A missing entitlement raises no error at all: the API returns the freshest data the user is entitled to, so an app that expects live quotes should read the timestamps rather than assume.

Testing While You Build

You will want a Market Data account of your own during development. A few things to know:

• Your account is one seat. You can use it to build and test, but you cannot share its data or its key with anyone, including colleagues and testers. Each person on your team who needs to see data needs their own account.
• As an app developer, our compliance team may classify you as a professional user. If it does, we can only supply historical data to your account. The functionality and the response shape are identical to what a verified non-professional user’s key returns in real time, so your integration is fully testable. The live data arrives for your users once they complete their own entitlement.
• You can keep building on a personal plan as long as the data stays with you. You do not need a commercial arrangement to develop the product. You need one only if you decide to take possession of the data at launch.

Monetization

The affiliate program pays 40% of the subscription revenue from every user you refer, for as long as they remain a customer. Place your affiliate link on the onboarding screen where the user creates their Market Data account, and every user who upgrades to a paid plan pays you as well as us. If your app has a free edition that runs on our free plan, that edition is monetized too, because every user of it is a potential upgrade.

You are welcome to identify Market Data as your supported data provider and to use “Powered by Market Data” in your app and on your product pages.

Two things we are asked about that we do not offer: there is no white-label or per-seat redistribution plan, because BYOK is the plan for client-side apps, and there is no standing discount code for a partner’s users. Our annual plans already cost 60% less than twelve monthly payments, as the plan table above shows, and we would rather keep pricing simple than issue coupons that end up on coupon sites.

What BYOK Costs You

BYOK has no licensing cost. What it has instead is a set of steps your users take on your behalf, and each one is a place where some of them will drop off.

• Two sign-ups. Your user creates an account with you and an account with us. Some users will not.
• Verification before real-time data. A paid user who has just entered a key sees delayed data until we have verified them, which takes up to one business day. Say so during onboarding.
• You do not control the data plan. A user on the free plan gets the previous session’s data and 100 credits. If your app’s core feature needs real-time quotes, that user will have a poor experience until they upgrade, and the upgrade decision is theirs.
• Nothing runs without the user’s device. Background alerts, scheduled scans, cross-user aggregates, and leaderboards all need a server, and a server disqualifies the model.
• Support is split. When a request fails, the cause may be on our side, on the user’s plan, or in your app. A clear user agent and clear error messages keep that manageable.

When BYOK Is the Wrong Model

If your product needs a server in the data path, you have two options.

Use historical data only. The exchanges charge no redistribution fees for historical data, meaning data from a completed session once the next session has opened, so a server-side product built entirely on historical data avoids the OPRA and equity redistribution fees. Delayed data does not qualify: a 15-minute delayed feed on a server avoids the per-user display fees but still needs the OPRA Vendor Agreement and the $1,500 a month that comes with it. Data becomes historical at the open of the next trading session, and the calendar day does not matter:

A product that shows “yesterday’s” data at 6:00 AM is showing delayed data and is fee-liable until the bell. The stock licensing guide covers what historical, delayed, and derived equity data each cost, and the OPRA guide does the same for options.

Get a commercial license. If you need current data on a server, you need to be licensed as a redistributor. That is a budgeting decision, $1,500 a month to OPRA before any per-user fee, and it is the right one for a funded product with a centralized architecture. Contact us and we will walk through your architecture with you and direct you to the right path. We have partnerships for the models we do not serve ourselves, including exchange licensing for redistribution, so there is a way forward for every kind of product.

The one shape that fits neither path as written is the hybrid: a server that fetches with each user’s key on their behalf. The exchanges define redistribution by where the data lands, so that design is a redistribution product whatever its intent, and the commercial path above is the one that serves it. Sales will help you get there.

BYOK Compliance Checklist

Before you launch, confirm every line:

• Each user creates their own Market Data account and enters their own API key.
• Your app never uses a shared, embedded, or app-wide API key.
• Every API request originates on the user’s device.
• No server you control receives, relays, caches, or stores market data.
• All calculations on market data run on the user’s device.
• Your app stores the API key on the device, never transmits it to you, and never logs it.
• No feature moves market data or derived values from one user to another through your systems.
• Nothing in the app exports, saves, copies, or delivers market data outside the app, and the app’s purpose is not data export.
• The app enforces one person per key on its side, and nothing in it is designed to work around our account-sharing controls.
• Every request carries a unique User-Agent identifying your app and version.
• Your app requests option chains with mode=cached unless the user’s plan and use case call for live requests.
• Onboarding explains the second sign-up, the verification step, and what each plan delivers.
• The app degrades gracefully on delayed, historical, or quota-limited keys.
• Your development and test accounts are one per person and shared with nobody.

Ask Before You Build

If you are unsure whether your design qualifies, contact us before you write the integration. Two sentences are usually enough: where the requests originate, and where the data goes after it arrives.