உங்கள் புதிய Google API Key ஏன் 400 'API Key Not Valid' பிழையைக் காட்டுகிறது (மேலும் காத்திருப்பது ஏன் அதைச் சரிசெய்கிறது)

ஒரு புதிய Google API key-ஐ உருவாக்கும் தருணத்தில் ஒரு குறிப்பிட்ட வகையான குழப்பம் ஏற்படுகிறது. சில வினாடிகளுக்கு முன்புதான் Cloud Console, gcloud CLI, அல்லது AI Studio வழியாக அதை உருவாக்கினீர்கள் — அதை உங்கள் பயன்பாட்டில் (app) நகலெடுத்து, முதல் கோரிக்கையை அனுப்புகிறீர்கள், முடிவுக்குப் பதிலாக இதைப் பெறுகிறீர்கள்:

{
  "error": {
    "code": 400,
    "message": "API key not valid. Please pass a valid API key.",
    "status": "INVALID_ARGUMENT"
  }
}

நீங்கள் அதைத் தவறாக நகலெடுத்தீர்கள், தவறான புலத்தில் (field) ஒட்டினீர்கள் அல்லது தவறான வகை key-ஐ உருவாக்கினீர்கள் என்று நீங்கள் முதலில் நினைக்கலாம். பத்து முறைகளில் ஒன்பது முறை, அவற்றில் எதுவும் உண்மையல்ல. Key சரியாகத்தான் உள்ளது. Google இன்னும் அதைச் செயல்படுத்தி (activate செய்து) முடிக்கவில்லை. ஒரு புதிய key-ஐ ஒவ்வொரு edge node-உம் அங்கீகரிப்பதற்கு முன்பு, அது Google-ன் உலகளவில் விநியோகிக்கப்பட்ட API front-end முழுவதும் பரவ (propagate ஆக) வேண்டும். முதல் ஒரு சில நிமிடங்களுக்கு, சில கோரிக்கைகளுக்கு அந்த key இல்லாதது போலவே தோன்றும்.

இந்தப் பதிவு அந்த propagation delay-ஐப் பற்றியது — இது ஏன் நடக்கிறது, இதைத் தவறாகக் கண்டறிவது ஏன் இவ்வளவு எளிதாக உள்ளது, மற்றும் ஒரு புதிய Google key தூக்கி எறியும் மற்ற மூன்று பிழைகளிலிருந்து இதை எவ்வாறு வேறுபடுத்துவது என்பதைப் பற்றியது.

2026-இல் இது ஏன் இப்போது முக்கியமானது

இரண்டு விஷயங்கள் இந்தச் சிறிய தாமதத்தை முன்பை விட அதிக நேரம் வீணடிக்கும் ஒரு பெரிய காரணியாக மாற்றியுள்ளன.

முதலில், AI மூலம் உருவாக்கும் அனைவரும் இப்போது Google API keys-ஐ உருவாக்குகிறார்கள் — Gemini API ஆனது Google Cloud-ன் ஏனைய பகுதிகளைப் போலவே அதே Generative Language API மற்றும் அதே key அமைப்பில் இயங்குகிறது. Keys தொடர்ந்து உருவாக்கப்படுகின்றன: ஒரு புதிய பக்கத் திட்டம் (side project), ஒரு புதிய billing account, இலவச-வரம்பு வரம்பிலிருந்து (free-tier limit) தப்பிக்க ஒரு புதிய project.

இரண்டாவதாக, அந்த key உருவாக்கத்தின் பெரும்பகுதி இப்போது தானியங்கிமயமாக்கப்பட்டுள்ளது (automated). Provisioning scripts, gcloud services api-keys create, மற்றும் infrastructure-as-code pipelines ஆகியவை ஒரு key-ஐ உருவாக்கி, அதே ஓட்டத்தில் உடனே பயன்படுத்துகின்றன. அந்த create-then-use வடிவம் சரியாக propagation window-க்குள் விழுகிறது, எனவே நேற்று வேலை செய்த ஒரு deployment இன்று 400 பிழையுடன் தோற்கிறது, அது பார்க்க உடைந்த key போலத் தோன்றும்.

உடனடியாக key-ஐ மீண்டும் உருவாக்கி (regenerate செய்து) மீண்டும் முதலிலிருந்து தொடங்குவதற்குப் பதிலாக, இந்தத் தாமதத்தைப் புரிந்து கொள்வதுதான் இரண்டு நிமிட காத்திருப்புக்கும் இரண்டு மணி நேர வீண் வேலைக்கும் இடையே உள்ள வித்தியாசம்.

உண்மையில் என்ன நடக்கிறது

Google-ன் API endpoints உலகளவில் விநியோகிக்கப்பட்ட front-end இலிருந்து வழங்கப்படுகின்றன. நீங்கள் ஒரு key-ஐ உருவாக்கும் போது, ஒவ்வொரு node-உம் அதை ஏற்கும் முன் அந்தப் பதிவேடு (record) அந்த fleet முழுமைக்கும் நகலெடுக்கப்பட (replicate ஆக) வேண்டும். Replicate செய்து முடிக்கும் வரை, புதுப்பிக்கப்படாத node-ஐ அடையும் கோரிக்கைக்கு key செல்லுபடியாகாது (valid அல்ல) என்று கூறப்படும் — ஏனெனில் அந்த node-இல், அது உண்மையிலேயே இன்னும் செல்லுபடியாகும் நிலையில் இல்லை.

இது சாதாரண eventual consistency, ஒரு கோளாறு அல்ல. உங்களிடம் உள்ள key உண்மையானது மற்றும் சரியானது. அது ஒரே நேரத்தில் எல்லா இடங்களிலும் நேரலையில் (live) இல்லை, அவ்வளவே. இந்த நேரம் வழக்கமாக இரண்டு நிமிடங்களுக்கும் குறைவாக இருக்கும், ஆனால் ஐந்து அல்லது அதற்கு மேற்பட்ட நிமிடங்களுக்கும் நீடிக்கலாம், மேலும் இதை உங்களால் கட்டாயப்படுத்தவோ அல்லது விரைவுபடுத்தவோ முடியாது. நீங்கள் காத்திருக்கிறீர்கள், பின்னர் அது வேலை செய்கிறது.

வலை: நான்கு வெவ்வேறு பிழைகள், ஒரு அறிகுறி

இது மக்களுக்கு அதிக நேரத்தைச் செலவழிக்கக் காரணம் என்னவென்றால், "எனது புதிய key வேலை செய்யவில்லை" என்பதற்குப் பல வித்தியாசமான காரணங்கள் உள்ளன, மேலும் குழப்பமடைவது எளிது. Status code-ஐ மட்டும் படிக்காமல் error body-ஐயும் படியுங்கள் — உங்களுக்கு உண்மையில் எந்தப் பிரச்சனை உள்ளது என்பதைச் செய்தி தெரிவிக்கும்.

• 400 · "API key not valid. Please pass a valid API key." — Key மிகவும் புதியது மற்றும் இன்னும் propagate ஆகிக் கொண்டிருக்கிறது, அல்லது நீங்கள் ஒட்டிய string தவறானது (துண்டிக்கப்பட்டது, தேவையற்ற இடைவெளி உள்ளது, அல்லது தவறான புலத்திலிருந்து வந்தது). இதுதான் propagation நிகழ்வு.
• 403 · "... API has not been used in project X before or it is disabled." — Key சரியாக உள்ளது, ஆனால் நீங்கள் அழைக்கும் API (Gemini-க்கு, Generative Language API) அந்த project-இல் இயக்கப்படவில்லை (enable செய்யப்படவில்லை). அதை enable செய்துவிட்டு ஒரு நிமிடம் காத்திருக்கவும்.
• 403 · with reason API_KEY_SERVICE_BLOCKED. — Key-இல் உள்ளது API restrictions அவை நீங்கள் அழைக்கும் சேவையைச் சேர்க்கவில்லை. தவறான வழியில் உருவாக்கப்பட்ட keys-இல் இது அடிக்கடி நிகழ்கிறது, இது சம்பந்தமில்லாத ஒரு API-க்கு key-ஐ பூட்டுகிறது. Restriction-ஐ விரிவுபடுத்துங்கள் அல்லது அகற்றுங்கள்.
• 429 · "Too Many Requests." — Key-இல் எந்தத் தவறும் இல்லை; நீங்கள் இலவச-வரம்பு நாளிாந்திரக் கோரிக்கை வரம்பு (free-tier daily request cap) போன்ற rate அல்லது quota limit-ஐ அடைந்துவிட்டீர்கள். அதற்கு billing அல்லது quota reset ஆகும் வரை காத்திருக்க வேண்டும், புதிய key தேவையில்லை.

முதலாவது மட்டுமே காத்திருப்பதன் மூலம் சரியாகும். மற்ற மூன்றிற்கும் குறிப்பிட்ட மாற்றம் தேவை. தவறான ஒன்றைக் கண்டறிவதுதான் ஒரு பிற்பகல் முழுவதையும் வீணடிக்கும் வழியாகும்.

என்ன செய்ய வேண்டும், வரிசையாக

படி ஒன்று: key string சரியாக உள்ளதா என்பதை உறுதிப்படுத்தவும். Propagation-ஐக் குறை கூறுவதற்கு முன், சாதாரணக் காரணத்தை ஒதுக்குங்கள். Key-ன் முன்னும் பின்னும் இடைவெளிகள் இல்லை என்பதையும், நகலெடுக்கும் போது துண்டிக்கப்படவில்லை என்பதையும், உண்மையில் key புலத்திலிருந்துதான் வந்தது என்பதையும் உறுதிப்படுத்திக் கொள்ளுங்கள் — அதனருகில் உள்ள label, nickname, அல்லது email box இலிருந்து அல்ல. தவறான நீளம் அல்லது தவறான அமைப்பைக் கொண்ட key ஒரு propagation பிரச்சனை அல்ல.

படி இரண்டு: இரண்டு 403-களை ஒதுக்குங்கள். உங்களுக்கு ஒரு 403, எதுவென்று படியுங்கள். "...has not been used or is disabled" என்றால் project-இல் API-ஐ enable செய்யவும். API_KEY_SERVICE_BLOCKED என்றால் key restricted என அர்த்தம்; அதை unrestricted என அமைக்கவும் அல்லது குறிப்பிட்ட API-ஐ அதன் அனுமதிக்கப்பட்ட பட்டியலில் சேர்க்கவும். காத்திருப்பதன் மூலம் இவை இரண்டும் தானாகச் சரியாகாது.

படி மூன்று: இது ஒரு 400 புதிதாக உருவாக்கப்பட்ட key-இல் வந்தால், காத்திருக்கவும். String சரியானது என உறுதிசெய்யப்பட்டு, அது 403 இல்லையென்றால், ஒரு 400 "API key not valid" சில நிமிடங்களுக்கு முன் நீங்கள் உருவாக்கிய key-இல் வரும் பிழை நிச்சயம் propagation தான். இதற்கு இரண்டு முதல் ஐந்து நிமிடங்கள் கொடுத்து மீண்டும் முயற்சிக்கவும். மீண்டும் உருவாக்க வேண்டாம் — ஒரு புதிய key அதே நேரத்தை மீண்டும் முதலில் இருந்து தொடங்கும்.

படி நான்கு: அதைக் கண்காணித்துக் கொண்டிருப்பதற்குப் பதிலாக காத்திருப்பதைத் தானியக்கமாக்குங்கள். ஒரு script அல்லது deployment-இல், ஒரு முறை இயக்கி தோல்வியடைய விடாதீர்கள். அது வெற்றியைத் தரும் வரை ஒரு குறிப்பிட்ட இடைவெளியில் — ஒவ்வொரு இருபது முதல் முப்பது வினாடிகளுக்கும் — key-ஐ poll செய்யுங்கள், பிறகு தொடருங்கள். ஒரு சிறிய retry-with-backoff loop ஆனது கணிக்க முடியாத, கையேடு "சிறிது நேரத்தில் மீண்டும் முயற்சிக்கவும்" என்பதை key live ஆகும் போதெல்லாம் வேலை செய்யும் ஒரு தானியங்கி படியாக மாற்றுகிறது.

நன்மைகள்

இதை ஒரு பிழையாகக் கருதாமல் propagation எனக் கருதுவதில் உண்மையான நன்மைகள் உள்ளன. இந்தத் தாமதம் உலகளவில் சீரான key அமைப்பின் ஒரு பக்க விளைவு ஆகும், இது ஒரு key நிலைபெற்ற பிறகு எங்கிருந்தும் நம்பகத்தன்மையுடன் செயல்பட வைக்கிறது. Key, ஒருமுறை propagate ஆன பிறகு, நிலையானது — நீங்கள் காத்திருப்பை ஒரே ஒரு முறை மட்டுமே செய்கிறீர்கள். மேலும் நான்கு error body-களை வேறுபடுத்திப் படிக்கக் கற்றுக்கொள்வது மீண்டும் பயன்படுத்தக்கூடிய ஒரு கண்டறிதல் திறனாகும் (diagnostic skill), இது Gemini-க்கு மட்டுமல்லாமல் ஒவ்வொரு Google Cloud சேவைக்கும் பலனளிக்கும்.

குறைபாடுகள்

இதற்கான செலவுகளும் உண்மையானவை, மேலும் அவை பெரும்பாலும் ergonomics பற்றியவை. "உங்கள் key இன்னும் செயல்படத் தொடங்குகிறது" என்ற வெளிப்படையான சிக்னல் எதுவும் இல்லை — 400 ஆனது ஒரு உண்மையான தவறான key-க்கு நீங்கள் பெறும் செய்திக்கு byte-for-byte ஒரே மாதிரியாக இருக்கும், இதுதான் டெவலப்பர்களை ஒரு சிறந்த key-ஐ மீண்டும் உருவாக்கத் தூண்டுகிறது. தானியங்கு create-then-use ஓட்டங்கள் ஒரு திட்டமிட்ட retry இல்லாமல் அவ்வப்போது முறிவடைகின்றன, இது அவற்றை debug செய்வதை வெறியேற்றுகிறது. மேலும் காத்திருப்பு கணிக்க முடியாதது: சில நேரங்களில் வினாடிகள், சில நேரங்களில் நிமிடங்கள், அதை வற்புறுத்த வழியே இல்லை.

நீங்கள் செயல்படும் முன் ஒரு எச்சரிக்கை

Cloud வழங்குநரின் நடத்தை, பிழைச் செய்திகள் மற்றும் propagation நேரங்கள் மாறும், மேலும் இங்குள்ள விவரங்கள் mid-2026-ஐப் பிரதிபலிக்கின்றன. முக்கியமான எதிலும் இதை இணைப்பதற்கு முன், Google-ன் சொந்த ஆவணங்களுடன் தற்போதைய நடத்தையைச் சரிபார்த்து, முதலில் ஒரு சோதனை திட்டத்தில் (throwaway project) சோதிக்கவும். ஒவ்வொரு வினாடியும் endpoint-ஐ அடிக்கும் ஒரு நெருக்கமான retry loop-ஐ உருவாக்க வேண்டாம் — அதுதான் propagation delay-ஐ rate-limit பிரச்சனையாக மாற்றும் வழியாகும். மேலும் ஒவ்வொரு key-ஐயும் நேரலை இரகசியமாக நடத்துங்கள்: அதை ஒரு சாட், ஸ்கிரீன்ஷாட், label field அல்லது பதிவு செய்யப்பட்ட கட்டளையில் ஒட்டவேண்டாம், மேலும் அது எப்போதாவது வெளிப்பட்டால் உடனடியாக அதை சுழற்றுங்கள் (rotate செய்யுங்கள்).

முடிவுரை

ஒரு 400 "API key not valid" சில கணங்களுக்கு முன் நீங்கள் உருவாக்கிய key-இல் வரும் பிழையானது, பெரும்பாலான நேரங்களில் உடைந்த key அல்ல — அது நேரலையில் சென்று முடிவடையாத ஒரு key ஆகும். String சரியாக உள்ளதா என்பதை உறுதிப்படுத்தவும், இரண்டு 403-கள் மற்றும் 429-ஐ ஒதுக்கவும், பின்னர் உண்மையில் உதவும் ஒரு காரியத்தைச் செய்யுங்கள்: காத்திருங்கள், அல்லது இன்னும் சிறப்பாக அது பதிலளிக்கும் வரை poll செய்யுங்கள். பொறுமை கவர்ச்சியற்றது, ஆனால் key-ஐ மீண்டும் உருவாக்குவது, உங்கள் குறியீட்டை இரண்டாம் பட்சமாக யோசிப்பது மற்றும் ஒரு கப் தேநீர் தயாரிக்க எடுக்கும் நேரத்தில் தானாகவே தீர்க்கப்படும் ஒரு பிரச்சனைக்காக ஒரு பிற்பகலை இழப்பதை விட இது சிறந்தது.

---

அடிக்கடி கேட்கப்படும் கேள்விகள்

ஒரு புதிய Google API key வேலை செய்ய எவ்வளவு நேரம் ஆகும்? வழக்கமாக இரண்டு நிமிடங்களுக்குள், சில நேரங்களில் ஐந்து அல்லது அதற்கு மேற்பட்ட நிமிடங்கள் வரை ஆகும். இது Google-ன் விநியோகிக்கப்பட்ட front-end முழுவதிலும் உள்ள ஒரு propagation delay ஆகும், மேலும் இதைக் கட்டாயப்படுத்த முடியாது — key அனைத்து இடங்களிலும் செயலுக்கு வரும் வரை நீங்கள் காத்திருக்க வேண்டும்.

நான் சரியாக நகலெடுத்த பிறகும் எனது புதிய key ஏன் "API key not valid" என்று சொல்கிறது? ஏனென்றால் அது இன்னும் propagate ஆகிக்கொண்டிருக்கிறது. புதிய key பதிவேட்டை இன்னும் பெறாத ஒரு node-இல், key உண்மையிலேயே அங்கீகரிக்கப்படாது, அதனால் உங்களுக்கு ஒரு 400. Replication முடிந்ததும் அதே கோரிக்கை வெற்றிபெறும்.

இது 400 "API key not valid" தவறான key என்பதற்குச் சமமானதா? செய்தி ஒரே மாதிரியாக இருக்கும், அதுதான் வலை. இதன் பொருள் string உண்மையில் தவறானது (துண்டிக்கப்பட்டது, இடைவெளி, தவறான புலத்தில் உள்ளது) அல்லது key மிகவும் புதியது மற்றும் இன்னும் செயல்பட்டுக் கொண்டிருக்கிறது. முதலில் string-ஐ உறுதிப்படுத்தவும்; அது சரியாக இருந்தால், அது propagation தான்.

Key உடனடியாகத் தோற்றால் நான் அதை மீண்டும் உருவாக்க வேண்டுமா? இல்லை. String சரியாக இருந்தால், மீண்டும் உருவாக்குவது ஒரு புதிய key-ஐ மட்டுமே உருவாக்கும், அது மீண்டும் propagate ஆக வேண்டும். Key மோசமானது என்று கருதுவதற்கு முன் காத்திருக்கவும் அல்லது poll செய்யவும்.

Propagation delay-ஐ ஒரு முடக்கப்பட்ட (disabled) API-யிலிருந்து எவ்வாறு வேறுபடுத்துவது? பிழையைப் படியுங்கள். Propagation என்பது ஒரு 400 "API key not valid." முடக்கப்பட்ட API என்பது ஒரு 403 இது API "has not been used in project X before or is disabled" என்று சொல்கிறது. Restricted key என்பது ஒரு 403 காரணத்துடன் கூடிய API_KEY_SERVICE_BLOCKED. மட்டுமே 400 காத்திருப்பதன் மூலம் சரியாகும்.

ஒரு தானியங்கி deployment-இல் இதை நான் எவ்வாறு கையாள வேண்டும்? உருவாக்கி-உடனே-பயன்படுத்த வேண்டாம். Key-ஐ உருவாக்கிய பிறகு, அது வெற்றியைத் தரும் வரை இருபது முதல் முப்பது வினாடி இடைவெளியில் அதை poll செய்யுங்கள், பிறகு தொடரவும். ஒரு சிறிய retry-with-backoff உங்கள் pipeline-ன் எஞ்சிய பகுதிக்கு propagation window தெரியாதவாறு செய்கிறது.

---

#GoogleCloud #GeminiAPI #APIKeys #gcloud #GoogleAIStudio #CloudDevelopment #DevOps #Debugging #EventualConsistency #InfrastructureAsCode #DeveloperExperience #RateLimits #APIDesign #CloudComputing #Propagation