Indexing Tools BYOK: Use Your Own Keys

Indexing tools BYOK options let you submit URLs through your own Google and IndexNow credentials instead of a shared vendor key. This guide is for site owners, SEOs, and developers who want direct quota control, clearer logs, and lower cost per URL. You will learn how these tools connect to both ecosystems, how to set them up safely, and how to operate them week to week without leaking secrets or tripping limits.

The core idea is simple. IndexNow is an open protocol co-developed by Microsoft Bing and Yandex that reaches Bing, Yandex, Naver, Seznam, and related supporters. The Google Indexing API is a separate Google only endpoint for JobPosting and BroadcastEvent pages that uses URL_UPDATED and URL_DELETED notices. A BYOK tool stores your keys, sends submissions under your identity, and shows per key results. If you are new to the Google side, start with the Google Indexing API setup guide before you connect anything to a third party tool.

Key takeaways

BYOK indexing tools submit under your own Google service account and your own IndexNow key, so quotas, logs, and errors belong to you.
Google and IndexNow cover different engines, so a good tool keeps auth, queues, and retry rules separate per track.
Your own keys cut per URL fees and remove the shared quota bottleneck, but you take on rotation and monitoring.
Least privilege access, secret storage, and a small test batch come before any bulk submission.
Sitemaps, canonical tags, and internal links still decide whether a submitted URL stays indexed.

Table of contents

What BYOK means for indexing tools
How indexing tools use your own Google API credentials
How indexing tools use your own IndexNow key
Indexing tools BYOK compared by workflow
Cost control with your own keys
Security checklist before you connect a key
Operating a BYOK indexing workflow week to week
Choosing a BYOK indexing tool without regret
FAQ
Sources
Further reading

Indexing tools BYOK dashboard connecting own Google and IndexNow keys through one view

What BYOK means for indexing tools

Bring your own key, usually shortened to BYOK, means the software provides the workflow while you provide the credentials. In indexing, that means you create the Google Cloud service account, enable the Indexing API, verify ownership in Search Console, and paste or upload the JSON key into the tool. For IndexNow, you generate a key string, host the matching text file at your site root, and enter the same key into the tool. The tool never submits through a shared pool. Every request carries your identity, counts against your quota, and returns logs you can match to your own consoles.

This split matters because indexing quotas are per identity. When many customers share one vendor key, one heavy sender can slow everyone else, and failures are hard to attribute. With your own keys, the IndexNow documentation response codes map directly to your configuration. A 403 points to your key file. A 422 points to your URL list. A 429 points to your send rate. On the Google side, a 403 points to Search Console permissions for your service account, and a 429 points to your project quota. That direct mapping shortens debugging from days to minutes.

BYOK also changes the cost model. Traditional indexing services charge per URL or per credit because they absorb API risk and shared quota across customers. A BYOK tool charges for software, storage, and convenience, while the API calls themselves run under your free quotas. IndexNow submissions carry no per call fee from the engines. Google Indexing API calls carry no per call fee from Google within quota, though engineering time, Cloud project hygiene, and monitoring still cost attention. For sites that submit hundreds or thousands of URLs per month, owning the keys is usually cheaper after the first setup hour.

There is a trade off. You take on key lifecycle work. Service account JSON files must be stored safely, rotated on a schedule, and removed from old laptops and chat threads. IndexNow key files must stay reachable at the root whenever you submit, including after redesigns, migrations, and CDN changes. If you lose the service account or delete the Cloud project, submissions stop with auth errors until you reconnect. A good BYOK tool reduces this burden with expiry reminders, permission checks, and clear reconnect steps, but it cannot remove the responsibility entirely.

How to tell a true BYOK tool from a shared key service

Ask three questions before you sign up. First, can you view and replace the exact key material the tool uses. A true BYOK product shows the service account email, the IndexNow key name, and the last verification timestamp. Second, do quotas and errors match your own consoles. Send a small test batch, then compare the tool log with Search Console and server logs for the same URLs. Third, can you leave with your keys intact. Revoking tool access should stop future submissions without breaking your Cloud project or your IndexNow file. If a vendor cannot answer these plainly, treat it as a shared key service with BYOK marketing.

For teams, BYOK also clarifies ownership. The site owner holds the Cloud project and the domain root. The SEO lead holds submission policy, meaning which content types get submitted and how fast. The developer holds integration, meaning CMS hooks and deploy triggers. The tool sits in the middle as a shared surface with role based access, not as the owner of credentials. Document who can add keys, who can rotate them, and who can press bulk send. That one page prevents most incidents.

Common confusion comes from the phrase API key. Google uses a service account JSON with OAuth scopes, not a simple string key. IndexNow uses a simple key string plus a hosted text file. Some tools also accept a Bing Webmaster API key for URL submission through Bing Webmaster Tools, which is separate from IndexNow and carries its own quotas. Keep these three credentials distinct in your notes. Label each entry with engine, scope, expiry, and storage location so future teammates do not mix them.

In practice, own api key indexing means any byok indexing tool acts as key based indexing software that never pools quota, so each send traces cleanly to your project and host.

How indexing tools use your own Google API credentials

Google track setup in a BYOK tool follows the same steps you would do manually, only with a form and a test button. You create a Google Cloud project, enable the Indexing API, create a service account, download the JSON key, and add the service account email as an owner or full user on the verified Search Console property. Then you upload the JSON into the tool or paste it into a secrets field. The tool exchanges the key for a short lived access token at send time and calls the publish endpoint with URL_UPDATED or URL_DELETED for each canonical URL. For endpoint shape and token flow, see the Google Indexing API usage guide.

A careful tool never asks for broader scopes than needed. It requests the indexing scope, stores the JSON encrypted at rest, and never prints the private key in logs or UI previews. It shows only the client email, project ID, and key ID. It lets you scope submissions to specific properties so one key cannot submit for unrelated domains. It also separates Google quota from IndexNow quota in the dashboard, because the two systems enforce limits independently. If a product mixes both tracks into one credit counter, treat the numbers as marketing and verify against your own consoles.

Eligible content types deserve honest handling. Google documents the Indexing API for JobPosting pages and for BroadcastEvent pages inside VideoObject markup, typically livestreams. It does not document the API for normal blog posts or product pages. Many teams still submit general pages and report faster discovery, but that use sits outside the documented scope and carries policy and quota risk. A responsible BYOK tool states this plainly, lets you tag content types, and defaults news, jobs, and livestreams to the Google track while routing general pages to IndexNow plus sitemaps. Read how the two protocols divide coverage in this overview of how IndexNow and the Google API compare.

Submission mechanics are one URL per request on the Google track. There is no supported batch of hundreds of URLs in a single Google call the way IndexNow allows up to 10,000 URLs per POST. A BYOK tool therefore needs a queue with pacing, deduplication, and backoff. It should normalize each URL to canonical form, drop duplicates within a window, and space sends to stay under per minute and per day limits. On 429 responses it should pause that track with exponential backoff and jitter, honor any wait hint, and resume with smaller concurrency. It should log the notification type, timestamp, response code, and a request identifier per URL so you can reconcile with Search Console crawl stats.

Permission errors are the most common stall. A 403 usually means the service account lacks rights on the exact property, including protocol, subdomain, and path prefix mismatches. A tool should surface the property it attempted, the service account email, and a direct checklist: verify property, confirm owner role, confirm API enabled, confirm token scope, then retry one URL. Token errors point to clock skew, revoked keys, or a deleted project. Quota errors point to pacing. A good UI separates these three families instead of showing a generic failed label.

Connection checklist for the Google track

Use this order and test with one URL before any batch. Create the Cloud project and note the project ID. Enable the Indexing API and note the timestamp. Create the service account and download JSON once to a vault, not to email or chat. Add the service account email to Search Console with full rights on the exact property. Upload the JSON to the BYOK tool over a secure session. Send one URL_UPDATED for a real canonical page, then check the tool log and Search Console within the hour for a fetch. Only then enable CMS automation. Record rotation date and owner on the same page as the property list.

Key rotation without downtime follows a simple overlap. Create a second key for the same service account, add it to the tool, test one submission, then disable the old key after a day of clean sends. Never delete the only working key on a Friday afternoon. Keep the Cloud project, property delegation, and tool configuration under the same team calendar so expiry never surprises a launch.

How indexing tools use your own IndexNow key

IndexNow auth is lighter than Google auth but easier to break by accident. You generate a random key string, save it, and publish a plain text file at the site root named after the key, containing the key as its content. You then enter the same key into the BYOK tool along with your domain. Each submission POST carries the host, key, and URL list to an IndexNow endpoint. Engines verify ownership by fetching the key file, so the file must stay public, fast, and stable. Full field rules live in the IndexNow protocol documentation.

A BYOK tool should validate the key file before the first send and recheck it on a schedule. It should fetch the file the same way an engine would, confirm status 200 and exact content match, and warn about redirects, blocks in robots rules, CDN caching, or authentication walls. It should also enforce one key per host unless you intentionally share a key across properties, and it should keep a history of key changes with timestamps. When you rotate, the tool should support an overlap window where both old and new files stay live until sends confirm on the new key.

Payload rules are strict and simple. The tool must send only canonical, indexable, fully qualified URLs under the verified host, with correct percent encoding and without fragments, session IDs, or tracking parameters. It must cap each request at the documented maximum and split larger batches into sequential POSTs with pacing. It must never resubmit unchanged URLs on a timer just to look active. IndexNow is a change signal, not a ranking lever. Engines still decide crawl and index outcomes based on quality, links, and site signals.

Response handling separates healthy tools from noisy ones. A 200 or 202 means accepted, not indexed. A 400 means malformed payload. A 403 means key mismatch. A 422 means invalid URLs in the batch. A 429 means too many requests. The tool should map each code to a fix, quarantine bad URLs instead of retrying them blindly, and back off the whole track on 429. Per URL status inside a batch matters, because one bad entry should not block nine thousand good ones. Logs should show batch ID, per URL outcome, and next action.

Hosting pitfalls cause most IndexNow failures in BYOK setups. Root file removed during redesign, key file cached with stale content behind a CDN, mixed www and non www hosts, country based blocking, and overly strict firewall rules all produce 403 style symptoms. A good tool checks the file from an external fetch, not only from inside your network, and alerts when the public fetch differs. It also reminds you after migrations to reverify before enabling auto submit.

Connection checklist for the IndexNow track

Generate the key with a password manager or random generator, not a memorable word. Publish the text file at the root and confirm public 200 with exact content. Enter the key and host into the tool, keeping www and apex consistent with canonical. Send one changed URL, confirm 202, and confirm the key file fetch in server logs. Enable CMS triggers only after that single success. Schedule a monthly recheck and a post deploy check after any hosting change.

Indexing tools BYOK compared by workflow

BYOK products cluster into four workflow styles, and the right choice depends on team size and change volume. Dashboard submitters suit small teams that publish a few times per week and want a manual review step. You paste URLs or upload a CSV, the tool validates canonical and key status, then sends under your keys with per URL results. CMS plugins suit WordPress and similar stacks where every publish event should trigger a background submission without human clicks. Pipeline senders suit developers who want deploy hooks and CI checks to submit only changed canonical URLs after a successful build. API first platforms suit agencies and multi site operators that need workspaces, roles, and audit exports across many properties.

Compare candidates on eight practical points rather than marketing claims. First, credential transparency, meaning visible service account email, key name, verification time, and one click rotation. Second, track separation, meaning Google and IndexNow queues, quotas, logs, and backoff stay independent. Third, URL hygiene, meaning canonical normalization, parameter stripping, duplicate suppression, and indexability checks before send. Fourth, pacing controls, meaning per minute limits, daily caps, concurrency settings, and automatic backoff on 429. Fifth, observability, meaning per URL timestamps for publish, send, response code, and later fetch or impression joins. Sixth, access control, meaning roles for key managers, senders, and viewers plus an audit trail. Seventh, data handling, meaning encrypted storage, region notes, and clear deletion on offboarding. Eighth, exit path, meaning revoke tool access without breaking your Cloud project or key file.

Manual dashboards look simple but fail at scale when editors forget to submit or paste staging URLs. CMS plugins look automatic but can flood quotas during bulk edits, imports, or theme changes unless they debounce and filter to published canonicals. Pipeline senders look robust but need careful diff logic so every deploy does not resubmit the whole sitemap. API platforms look complete but add per seat cost and setup time that small sites do not need. Match the style to publish frequency, then verify with a two week trial on one property before rolling out to the rest.

Ask for a live failure demo during evaluation. Have the vendor show a 403 from a revoked Search Console grant, a 422 from a bad URL inside a batch, and a 429 from intentional over pacing, plus the exact UI path to fix each. Products that only demo happy path success often hide weak error handling. Also ask how the tool treats non canonicals, noindexed pages, soft 404s, and redirected URLs. The correct answer is to block or warn before send, not to submit everything and report green checks.

Pricing deserves a small model, not a guess. Estimate monthly changed canonical URLs per property, multiply by tracks used, and divide by working days to get daily send volume. Compare the BYOK subscription plus your internal maintenance time against a per URL service for the same volume. Most single site publishers break even quickly with BYOK because engine quotas are free and the software fee is flat. Multi site agencies should model per workspace fees and seat fees separately, plus rotation labor per quarter. Keep a 20 percent buffer for launches and migrations that spike change volume.

Cost control with your own keys

Your own keys remove per URL tolls but introduce attention costs. The budget has four lines: software subscription, setup labor, ongoing monitoring, and incident response. Setup labor is usually two to four hours for the first property, including Cloud project, Search Console delegation, IndexNow file, tool connection, and a ten URL test. Each additional property on the same patterns takes under an hour. Ongoing monitoring is a weekly ten minute log review plus a monthly quota and rotation check. Incident response is rare when checks run, but budget a half day per quarter for auth refreshes, hosting changes, and CMS updates that touch triggers.

Volume planning keeps you inside free quotas without drama. List content types that truly change: new posts, updated guides, new products, price or availability changes, job postings, livestream pages, and removed pages that need URL_DELETED. Exclude faceted filters, paginated archives beyond canonical, staging URLs, and parameter variants. Assign each type to tracks: jobs and livestreams to Google plus IndexNow where eligible, general changed canonicals to IndexNow plus sitemap refresh, removals to Google URL_DELETED plus redirects and sitemap pruning. This routing table prevents the most common waste, which is submitting everything everywhere on every edit.

Pacing math stays simple. If you change 200 URLs on a publish day, split IndexNow into one or two POSTs and space Google notices across minutes, not seconds. If you migrate 20,000 URLs, stage them over days in priority order, starting with revenue pages and updated hubs, then supporting pages. Log daily send counts per track and compare to quota dashboards. When you approach 70 percent of a daily cap, queue the remainder for the next window instead of forcing retries. Backoff with jitter handles bursts, but a calendar beats a retry storm.

Measurement closes the cost loop. For each batch, record publish time, send time, response code, first bot fetch from server logs, and first impression from Search Console or Bing Webmaster Tools. A small control set of similar but unsubmitted URLs helps you read whether faster fetches came from the ping or from normal crawling. If submitted URLs fetch consistently sooner without extra errors, the spend of time is justified. If fetch times match controls, shift effort to sitemaps, internal links, and content quality before increasing send volume.

Watch for hidden cost traps. Shared seats with bulk send rights can flood quotas during imports. Staging domains connected with production keys can submit non canonicals. Auto submit on save, rather than on publish, can ping drafts repeatedly. CDN or firewall changes can break key file fetches and turn every send into a 403 retry loop. Each trap is cheap to prevent with filters and checks, and expensive to clean after a week of noisy logs.

When comparing vendors, shortlist self serve indexing tools and api key indexing platforms that show per key quotas separately, since pooled counters hide which property caused a spike.

Security checklist before you connect a key

Treat indexing credentials like any production secret. Store the Google JSON in a vault or secrets manager, never in email, chat, screenshots, or repo files. Limit who can view and replace keys to one or two owners. Use least privilege on the Cloud project and on Search Console properties. Prefer separate service accounts per business unit or per site group so revoking one does not halt everything. Record creation date, expiry policy, storage location, and rotation owner on the same page as the property inventory. The BYOK security checklist before you paste your key anywhere gives a compact pass you can reuse for each new property.

Before you connect, verify the tool security baseline. Confirm encrypted storage at rest and in transit, masked display of private key material, scoped submissions per property, role based access, and an audit log of key adds, rotations, sends, and revocations. Confirm data region and retention for logs that contain URLs, because URL lists can reveal launch plans. Confirm how to revoke cleanly: removing tool access should stop future sends immediately while leaving your Cloud project and IndexNow file intact for direct use. If any answer is vague, pause and get it in writing.

In daily use, apply five rules without exception. Never paste a service account JSON into a public form, demo, or support chat. Never commit keys to git, even private repos, without a secrets manager. Never reuse one service account across unrelated clients. Never grant Search Console ownership to personal addresses that leave with staff. Never auto submit from staging or preview branches. Each rule maps to real incidents where teams lost days to quota burn or had to rotate keys under deadline.

Rotation deserves a calendar entry, not a memory. Rotate Google service account keys every 90 to 180 days and IndexNow keys at least yearly or after staff changes. Use overlap: add the new credential, test one send, monitor for a day, then disable the old one. Keep both IndexNow files live during overlap so in flight batches verify cleanly. After rotation, update the vault, the tool record, and the owner page in one pass. Log the change with timestamp and operator name so audits trace every send to a known key generation.

Incident response stays calm when written in advance. If a key leaks, revoke it in the Cloud console or replace the IndexNow key immediately, then check tool logs for sends after the leak timestamp. If submissions spike unexpectedly, pause automation, inspect CMS import logs and deploy history, and quarantine the trigger that caused the flood. If 403 errors rise across tracks, check property delegation and key file reachability before changing code. Keep vendor support contact and console links on the same incident page so response takes minutes.

Operating a BYOK indexing workflow week to week

A steady weekly rhythm beats heroic bulk sends. Publish events flow into one intake queue, normalization keeps one entry per canonical URL, routing assigns Google or IndexNow or both with a reason code, pacing spaces sends per track, and logging records outcomes for review. Editors publish normally. Developers maintain triggers. The SEO owner reviews exceptions once per week. For a full dual track picture, compare this setup with the two API workflow covering Google and IndexNow together.

Daily automation handles the normal path. On publish or update of a canonical page, the CMS or deploy hook adds the URL to the intake with content type, timestamp, and change reason. A filter drops drafts, noindexed pages, non canonical variants, and non 200 responses. Deduplication collapses repeats within 24 to 72 hours so ten edits to one guide produce one send, not ten. The router applies the content type table: jobs and livestreams to both tracks where eligible, general updates to IndexNow plus sitemap, removals to URL_DELETED plus redirect and sitemap cleanup. Pacing spreads sends, backoff handles 429, and quarantine holds 422 cases for human review.

Weekly review takes about fifteen minutes with the right dashboard. Check send counts per track against quota, error rate by code, oldest unprocessed queue age, key file status, and Search Console delegation health. Sample ten sent URLs and confirm fetch or impression movement within a few days. Review quarantined URLs and fix patterns at the source, such as a template emitting trailing slash duplicates or a feed including expired jobs. Note decisions in one log line per week so trends stay visible across staff changes.

Monthly tasks keep the base healthy. Reverify IndexNow key files from an external fetch. Confirm service account access on every property, especially after domain moves or Search Console cleanups. Prune sitemaps of 404s, redirects, and non canonicals, because dirty sitemaps make clean pings harder to interpret. Review internal links to updated hubs so crawlers find changes through navigation as well as pings. Rotate any credential nearing its policy date. After any migration, redesign, or CDN switch, rerun the one URL test per track before re enabling bulk automation.

Indexing tools BYOK queue with separate Google and IndexNow lanes and per key logs

Logs are the product, not an accessory. Each entry should carry canonical URL, content type, track, notification type or payload batch ID, send timestamp, response code, and next action. Join these rows weekly with server log fetches and Search Console impressions to see whether pings shortened time to fetch. Keep thirty to ninety days of history for trend reads and incident review. Export a monthly CSV to the site archive so knowledge survives tool changes.

Edge cases need explicit policy. For paginated series, submit only the canonical hub unless individual pages changed. For translated pages, submit each canonical locale URL under its verified host with correct hreflang in place. For out of stock products, do not ping repeatedly; submit once on status change and let the page and sitemap carry the steady state. For deleted pages, send URL_DELETED on the Google track where eligible, submit the removal through Search Console or Bing tools as needed, and keep the redirect plus sitemap pruning as the durable fix. Write each rule once in the runbook so editors do not improvise under deadline.

Choosing a BYOK indexing tool without regret

Start from your constraints, not feature lists. Count properties, monthly changed URLs, CMS type, deploy frequency, team roles, and audit needs. A single WordPress blog with weekly posts needs a plugin plus a simple dashboard, not a multi workspace platform. A job board with hourly postings needs queue depth, deduplication, and per type routing. An agency with forty client sites needs workspaces, roles, key inventory, and exports more than it needs bulk CSV buttons. Write these numbers on one page before any trial so demos map to reality.

Run a two week trial on one representative property with a fixed script. Week one, connect both tracks, verify key file and Search Console grant, and send ten changed canonical URLs. Record response codes, fetch times, and any manual fixes. Week two, enable CMS or deploy triggers, publish normally, and watch queue age, duplicate rate, and error rate. Require zero auth surprises, clear 429 handling, and per URL logs you can match to consoles. If the tool needs support help for basic connection, expect heavier help later at scale.

Read the failure paths before the pricing page. Confirm behavior for revoked Search Console access, deleted Cloud project, expired JSON, missing IndexNow file, 422 bad URLs inside a large batch, and sustained 429. Confirm bulk import guards, staging filters, and dry run mode. Confirm audit exports and retention. Confirm revoke and offboarding steps. A product that answers these in the UI, not only in docs, will save more time than a cheaper product with thin error states.

For background on the protocols behind any demo, keep the IndexNow protocol notes and the Google setup notes open during evaluation. They help you spot when a vendor overstates coverage, especially any claim that IndexNow submits to Google. Google does not support IndexNow. Any tool that suggests one ping covers Google through IndexNow misunderstands the ecosystem or oversimplifies. The correct story is two tracks, two auth models, and one clean intake feeding both.

Decide with a short scorecard the whole team can read. Score credential transparency, track separation, URL hygiene, pacing, observability, access control, data handling, and exit path from one to five. Multiply audit and security scores for regulated work. Total the rest normally. Choose the highest total that fits budget and trial behavior, not the longest feature list. Record the decision, trial numbers, and rotation owners in the runbook so the next review starts from evidence.

indexing tools byok diagram: indexing tools use your, indexing tools byok compared, security checklist before you

FAQ

What does BYOK mean in an indexing tool?

It means you connect your own Google service account and your own IndexNow key, and the tool submits under your identity. Quotas, logs, and errors map to your consoles. You pay for software convenience while API usage runs under your own free quotas. You also own rotation, permission checks, and monitoring. A true byok submitter shows exact key material, verification time, and one click replace, while a generic bring key index tool claim should be checked against those three proofs.

Do I still need Search Console and a key file with BYOK?

Yes. The Google track needs a Cloud project with the Indexing API enabled plus service account rights on the verified property. The IndexNow track needs a public key text file at the site root that matches the key in the tool. Without these, submissions fail with 403 style errors. Connect and test one URL per track before enabling automation.

Does BYOK make indexing faster than shared key services?

Speed comes from clean signals and prompt submission, not from key ownership alone. Your own keys remove shared quota contention and make errors easier to fix, which often shortens time to fetch. Content quality, sitemaps, canonical hygiene, and internal links still decide outcomes. Use a small control set of unsubmitted URLs to read whether pings shortened fetch time on your site.

Can one ping cover Google and Bing through BYOK?

No. Google uses the Indexing API plus sitemaps and Search Console flows. Bing, Yandex, Naver, Seznam, and related supporters use IndexNow plus Bing Webmaster flows. An index tool own keys setup should fan one publish event out to both tracks with separate auth and pacing, since tools use own apis per engine rather than one shared credential. Any claim that IndexNow submits to Google contradicts current engine support and should be treated as a warning sign.

How often should keys be rotated?

Rotate Google service account keys every 90 to 180 days and IndexNow keys at least yearly or after staff changes and hosting moves. Use overlap by adding the new credential, testing one send, monitoring for a day, then disabling the old one. Keep both IndexNow files live during overlap. Record dates and owners in one inventory page.

What should I test before bulk sending with my own keys?

Send one canonical URL per track and confirm accepted codes, then confirm a bot fetch in server logs. Check canonical normalization, parameter stripping, and filters for drafts and noindexed pages. Confirm backoff on 429 and quarantine on 422 with a deliberate bad URL in a test batch. Mature byok index platforms also expose dry run mode for this check. Only then enable CMS triggers, and start with new and updated canonicals before any migration backlog.

Sources

https://www.indexnow.org/documentation
https://developers.google.com/search/apis/indexing-api/v3/using-api
https://www.bing.com/webmasters/help

Indexing Tools That Let You Use Your Own API Keys