API மற்றும் webhooks மூலம் உங்கள் சொந்த மென்பொருளை இணையுங்கள்

அந்தக் கருவிக்குத் தேவையான அனுமதிகளுடன் மட்டும் ஒரு key-ஐ உருவாக்குங்கள்

அமைப்புகள் → API & webhooks → Key-ஐ உருவாக்கு. அதற்கு நபரின் பெயரை அல்ல, கருவியின் பெயரை வையுங்கள் — பல மாதங்கள் கழித்து இந்தப் பட்டியலிலும் பாதுகாப்புப் பதிவிலும் நீங்கள் பார்ப்பது அந்தப் பெயரைத்தான். பிறகு அனுமதிகளை டிக் செய்யுங்கள், தேவையானவற்றை மட்டும்: படிக்க மட்டுமே முடிந்த key-ஐக் கொண்டு எதையும் எழுத வைக்க முடியாது.

• leads:read — லீடுகள், நிலைகள், முடிவுகளைப் படிக்க
• leads:write — லீடுகளை உருவாக்க, புதுப்பிக்க, நீக்க, குறிப்புகள் சேர்க்க
• calls:read — அழைப்பு வரலாற்றைப் படிக்க
• users:read — இந்தப் பணியிடத்தில் உள்ள நபர்களைப் படிக்க
• webhooks:manage — webhooks-ஐ உருவாக்க, நீக்க

இப்போதே நகலெடுங்கள் — அது ஒருமுறை மட்டுமே காட்டப்படும்

Key lk_live_ என்று தொடங்கும்; அதை உருவாக்கியவுடன் வரும் உரையாடல் பெட்டியில் சரியாக ஒருமுறை மட்டுமே தோன்றும். அதன் hash மட்டுமே சேமிக்கப்படுகிறது, எனவே பிறகு யாராலும் அதைத் திரும்பப் படிக்க முடியாது; உங்கள் keys-ஐ வேறுபடுத்தி அறிய பட்டியல் முதல் சில எழுத்துகளைக் காட்டுகிறது. அதைத் தொலைத்துவிட்டால், அந்த key-ஐ ரத்து செய்து புதியதை வழங்குவதுதான் தீர்வு. ஒரு key ஒரு முகவருக்கு அல்ல, பணியிடத்துக்குச் சொந்தமானது — உங்கள் லீடுகளில் ஒரு பகுதியை மட்டுமே பார்க்கும் ஒருங்கிணைப்பு பாதித் தரவை மட்டும் ஒத்திசைத்து, உடைந்ததுபோலத் தோன்றும் — அது எழுதும் அனைத்தும் பாதுகாப்புப் பதிவில் அந்த key-இன் பெயரில் பதிவாகும்.

அடிப்படை URL-உம் முதல் அழைப்பும்

அமைப்புகள் → API & webhooks உங்கள் அடிப்படை URL-ஐக் காட்டுகிறது — இன்று அது https://api.lumakol.com/api/v1 — ஒவ்வொரு கோரிக்கையிலும் key ஒரு bearer token ஆகச் செல்கிறது. முதலில் செய்ய வேண்டிய அழைப்பு GET /ping: key எந்தப் பணியிடத்துக்குச் சொந்தமானது, அது என்ன அனுமதிகளைக் கொண்டுள்ளது என்று அது பதிலளிக்கிறது; உண்மையான குறியீடு எதையும் எழுதும் முன்பே key, header, முகவரி மூன்றும் சரி என்று அது நிரூபிக்கிறது. ஒவ்வொரு endpoint, புலம், பிழைக் குறியீடும் API குறிப்பில் பட்டியலிடப்பட்டுள்ளன: அமைப்புகள் → API & webhooks → API குறிப்பு (நீங்கள் உள்நுழைந்திருக்க வேண்டும்).

• curl https://api.lumakol.com/api/v1/ping -H "Authorization: Bearer lk_live_…"

உங்கள் லீடுகளைப் படியுங்கள்

GET /leads ஒரு பக்க லீடுகளையும் நீங்கள் எதிர்பார்க்கும் வடிகட்டிகளையும் தருகிறது: stage, owner, source, tag, உரைத் தேடலுக்கு q, ஒரே நேரத்தில் 200 வரை limit. பதில் வெறும் பட்டியல் அல்ல, ஒரு object — லீடுகள் data-வில் இருக்கும், அதனுடன் next_cursor, has_more இருக்கும்.

• curl "https://api.lumakol.com/api/v1/leads?limit=100" -H "Authorization: Bearer lk_live_…"
• GET /leads/find ஒரு லீடை கைபேசி எண், மின்னஞ்சல் அல்லது நீங்களே அமைத்த external_id மூலம் கண்டுபிடிக்கிறது
• GET /stages, GET /dispositions உங்கள் சொந்த பைப்லைன், முடிவுப் பட்டியல்களின் ids-ஐத் தருகின்றன

பக்கமிடுதல், ஒரு நகலை ஒத்திசைவில் வைத்திருத்தல்

ஒரு பக்கத்தின் next_cursor-ஐ cursor ஆகத் திருப்பி அனுப்புங்கள், has_more false ஆகும் வரை மீண்டும் செய்யுங்கள்; cursor நிலையானது, எனவே நீங்கள் பக்கம் பக்கமாகப் படிக்கும்போது மாறும் லீடுகளால் எந்த வரியும் தவறிப்போகாது. தொடர் ஒத்திசைவுக்கு, கடைசியாக எப்போது இயக்கினீர்கள் என்பதை நினைவில் வைத்து, அடுத்த முறை அதை updated_since ஆக அனுப்புங்கள் — அதன் பிறகு மாறியவை மட்டுமே கிடைக்கும், அவற்றையும் அதே முறையில் பக்கம் பக்கமாகப் படிக்கலாம். ஒவ்வொரு key-உம் நிமிடத்துக்கு 60 கோரிக்கைகள் செய்யலாம்; ஒரு பணியிடம் அதன் எல்லா keys-இலும் சேர்த்து நிமிடத்துக்கு 120, நாளுக்கு 10,000. API keys கட்டணத் திட்டங்களில் கிடைக்கும், இலவச சோதனைக் காலத்தில் கிடைக்காது. பதில்களில் RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset headers இருக்கும்; 429 பதிலுடன் Retry-After வரும்; Remaining பூஜ்ஜியத்தை அடைந்தால், சுழற்சியில் மீண்டும் மீண்டும் முயலாமல் reset வரை காத்திருங்கள்.

ஒரு webhook-ஐச் சேருங்கள்

அமைப்புகள் → API & webhooks → Webhook-ஐச் சேர். URL https ஆகவும் இணையத்திலிருந்து அணுகக்கூடியதாகவும் இருக்க வேண்டும் — தனிப்பட்ட அல்லது உள் முகவரி சேமிக்கும்போதே மறுக்கப்படும், ஒவ்வொரு அனுப்புதலுக்கும் முன் மீண்டும் சரிபார்க்கப்படும்; எனவே பின்னர் DNS-ஐ மாற்றிக் காட்டினாலும் அது தப்பாது. உங்களுக்கு வேண்டிய நிகழ்வுகளை டிக் செய்து, பிறகு சோதி மூலம் ஒரு மாதிரி அனுப்புதலை வரிசையில் சேர்த்து, அதை நம்புவதற்கு முன் உங்கள் receiver வேலை செய்கிறது என்று உறுதிசெய்யுங்கள். அனுப்புதல்கள் ஒவ்வொரு பத்து வினாடிக்கும் சரிபார்க்கப்படும் ஒரு வரிசையிலிருந்து அனுப்பப்படுகின்றன; எனவே உடனடியாக அல்ல, சில வினாடிகளுக்குள் எதிர்பாருங்கள்.

• lead.created — கையால், API மூலம், படிவம், லீட் மூலம், இணையதள அரட்டை அல்லது தவறிய அழைப்பு மூலம் ஒரு லீட் சேர்க்கப்படுகிறது (கோப்பு இறக்குமதி மூலம் அல்ல)
• lead.updated — ஆப்பில், API மூலம் அல்லது தானியக்க விதி மூலம் ஒரு லீட் திருத்தப்படுகிறது (அழைப்பு முடிவைப் பதிவு செய்தால் அதற்குப் பதிலாக call.logged அனுப்பப்படும்)
• lead.stage_changed — ஒரு லீட் வேறொரு பைப்லைன் நிலைக்கு நகர்கிறது
• lead.assigned — ஒரு லீட் ஒருவரிடம் ஒப்படைக்கப்படுகிறது, அல்லது திரும்பப் பெறப்படுகிறது
• call.logged — ஒரு அழைப்புக்கு முடிவு பதிவு செய்யப்படுகிறது
• follow_up.due — உரிமையாளர் உள்ள ஒரு லீடுக்கு 15 நிமிடங்களுக்குள் தொடர் அழைப்பு வர இருக்கிறது

கையொப்பத்தைச் சரிபாருங்கள்

ஒவ்வொரு கோரிக்கையிலும் நான்கு headers இருக்கும்: X-LumaKol-Event, X-LumaKol-Delivery, X-LumaKol-Timestamp, X-LumaKol-Signature. கையொப்பம் என்பது sha256= என்பதைத் தொடர்ந்து வரும், timestamp, ஒரு முற்றுப்புள்ளி, மூல body ஆகியவற்றின் HMAC-SHA256; அதன் key நீங்கள் webhook-ஐ உருவாக்கியபோது காட்டப்பட்ட signing secret — அது whsec_ என்று தொடங்கும். நீங்கள் மீண்டும் serialise செய்த JSON மீது அல்ல, உண்மையில் பெற்ற bytes மீது அதை மீண்டும் கணக்கிடுங்கள்; constant-time ஒப்பீடு மூலம் இரண்டையும் ஒப்பிடுங்கள்; timestamp சமீபத்தியதாக இல்லாத எதையும் நிராகரியுங்கள். பொருந்தாத கோரிக்கை எங்களிடமிருந்து வந்ததல்ல.

• கையொப்பமிடப்படும் சரம்: timestamp, ஒரு முற்றுப்புள்ளி, பிறகு body — அதே வரிசையில்
• X-LumaKol-Delivery மறுமுயற்சிகளிலும் மாறாது: அதைச் சேமித்து, மீண்டும் வருவதைப் புறக்கணியுங்கள்; ஏனெனில் எங்கள் பக்கத்தில் நேரம் கடந்த அனுப்புதல், உங்கள் சர்வர் அதை முடித்திருந்தாலும் மீண்டும் முயலப்படும்
• “புதிய secret” key-ஐச் சுழற்றுகிறது, பழையது உடனே வேலை செய்வதை நிறுத்திவிடும்; எனவே முதலில் உங்கள் receiver-ஐப் புதுப்பியுங்கள்

அனுப்புதல் பதிவும் மறுமுயற்சிகளும்

ஒரு webhook-இன் கீழ் உள்ள “சமீபத்திய அனுப்புதல்கள்” திறந்தால், கடைசி அனுப்புதல்களை நிகழ்வு, அவை சென்றடைந்தனவா, உங்கள் சர்வர் திருப்பிய status code அல்லது எங்களுக்கு ஏற்பட்ட பிழை, எப்போது என்ற விவரங்களுடன் பார்க்கலாம். 2xx அல்லாத எதுவும் — redirect கூடத் தோல்வியாகவே கணக்கிடப்படும் — ஐந்து நிமிடம், பதினைந்து நிமிடம், ஒரு மணி நேரம், மூன்று மணி நேரம், ஆறு மணி நேரம், மீண்டும் ஆறு மணி நேரம் கழித்து மீண்டும் முயலப்படும்: சுமார் பதினாறு மணி நேரத்தில் ஏழு முயற்சிகள்; எனவே சிறிது நேரம் செயலிழந்த receiver எதையும் இழக்காது, நாள் முழுவதும் செயலிழந்ததற்கு இறுதியில் கைவிடப்படும். status code அல்லது பிழை மட்டுமே வைக்கப்படும், உங்கள் response body அல்ல. அது வெற்றிபெறும் வரை, அல்லது நீங்கள் அதை அணைத்து மீண்டும் இயக்கும் வரை, webhook தன் கடைசித் தோல்வியைக் காட்டிக்கொண்டே இருக்கும்.

• சுவிட்ச் ஒரு webhook-ஐ நீக்காமல் இடைநிறுத்துகிறது; மீண்டும் deploy செய்யும்போது உங்களுக்குத் தேவையானது இதுதான்
• அனுப்புதல் வரிசைகள் பிழைதிருத்த உதவி மட்டுமே, ஆவணப் பதிவு அல்ல — சுமார் இரண்டு வாரங்களுக்குப் பிறகு அவை அழிக்கப்படும்
• ஒரு webhook-ஐ நீக்கினால் அதற்காக வரிசையில் இன்னும் உள்ளவை அனைத்தும் கைவிடப்படும்

தேவை முடிந்ததும் key-ஐ ரத்து செய்யுங்கள்

ரத்து செய் அந்த key-ஐப் பயன்படுத்தும் அனைத்தையும் உடனே நிறுத்துகிறது, அதைத் திரும்பப் பெற முடியாது — வடிவமைப்பின்படியே இடைநிறுத்தம் என்று எதுவும் இல்லை. ஒரு கருவி ஓய்வுபெறும்போது, அதை அமைத்தவர் வெளியேறும்போது, அல்லது ஒரு key கசிந்திருக்கலாம் என்று சந்தேகம் வரும் அந்தக் கணமே ரத்து செய்யுங்கள்; பிறகு புதியதை வழங்கி அதைக் கருவியில் ஒட்டுங்கள். ஒவ்வொரு key-உம் கடைசியாக எப்போது பயன்படுத்தப்பட்டது என்று பட்டியல் காட்டுகிறது; இனி எதற்கும் தேவைப்படாத key-ஐக் கண்டுபிடிக்க இதுவே விரைவான வழி.