তুলনা

Proof of Actor বনাম API bot সুৰক্ষা: keys এ ক'ত খৰচ হৈছে বুজায়, actor context এ ক'ত কাম কৰা হৈছে বুজায়

API gateway, WAF bot rules, API keys আৰু rate limits এ আপোনাৰ API উপলব্ধ আৰু দায়বদ্ধ কৰি ৰাখে। কিন্তু এটা অনুৰোধ app-ত থকা এজন ব্যক্তি, সহায়কৰ সৈতে কাম কৰা এজন ব্যক্তি, নে এটা autonomous agent ৰ পৰা আহিছে সেয়া ক'বলৈ সিহঁত নিৰ্মিত হোৱা নাছিল। APIসমূহৰ বাবে bot management আৰু Proof of Actor কেনেকৈ তুলনীয়, আৰু দুয়োটা কেনেকৈ একেলগে কাম কৰে, সেয়া ইয়াত দেখুওৱা হৈছে।

Early Access লওক ই কেনেকৈ কাম কৰে অন্বেষণ কৰক

দ্বাৰা Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

চুটি উত্তৰ

APIসমূহৰ বাবে bot management এ আপোনাৰ endpointসমূহ সুৰক্ষিত কৰে: gateway এ keys authenticate কৰে, WAF bot rules এ অপব্যৱহৃত traffic filter কৰে, আৰু rate limits এ volume সীমিত কৰে। Proof of Actor এ এটা ভিন্ন স্তৰ যোগ কৰে, আপোনাৰ API-ক ক'ব পাৰে যে প্ৰতিটো caller Human, Human + AI, Agent নে Unknown, আৰু তাৰ evidence-সহ, যাতে আপোনাৰ code এ প্ৰতিটোৰ সৈতে সঠিকভাৱে কাম কৰিব পাৰে। বেছিভাগ দলেই দুয়োটা ব্যৱহাৰ কৰে।

APIসমূহৰ traffic model আগতে সহজ আছিল। এজন developer এ register কৰিছিল, key পাইছিল, integration লিখিছিল, আৰু সেই integration এ schedule অনুসৰি বা কোনো user এ কিবা ক্লিক কৰোঁতে আপোনাৰ endpointসমূহ call কৰিছিল। APIসমূহৰ বাবে bot management সেই modelৰ ওপৰত গঢ় লৈ উঠিছিল: key authenticate কৰা, volume সীমিত কৰা, স্পষ্টভাৱে অপব্যৱহৃত traffic filter কৰা, আৰু সেৱা সকলোৰে বাবে উপলব্ধ ৰখা।

সেই model এতিয়াও বৈধ, আৰু তাৰ বাবে নিৰ্মিত tools এতিয়াও গুৰুত্বপূর্ণ। সলনি হৈছে callসমূহৰ পিছফালে কোন আছে। একেটা API key এ এতিয়া আপোনাৰ customer ৰ app ব্যৱহাৰ কৰা এজন ব্যক্তি, কাম কৰিবলৈ AI assistant ক কৈ দিয়া এজন ব্যক্তি, আৰু ৰাতিৰ ভিতৰত multi-step task চলোৱা autonomous agent ৰ অনুৰোধ বহন কৰিব পাৰে। আপোনাৰ বিদ্যমান controls এ এটা key আৰু এটা request rate দেখে। আপোনাৰ product, support আৰু policy সিদ্ধান্তসমূহে প্ৰায়ে তাতকৈ অধিক জানিব লাগে।

Proof of Actor এ সেই খালী ঠাই পূৰণ কৰে। ই আপোনাৰ API-ক প্ৰতিটো অনুৰোধত কোন বা কি কাম কৰি আছে সেয়া ক'য় আৰু evidence উল্লেখ কৰে, তাৰ পাছত সিদ্ধান্ত আপোনাৰ code-ৰ ওপৰত এৰি দিয়ে। এই পৃষ্ঠাই ইয়াক API bot সুৰক্ষাৰ মুখ্য স্তৰসমূহৰ সৈতে তুলনা কৰে যাতে আপুনি প্ৰতিটো ক'ত লাগে সেয়া দেখিব পাৰে।

সংক্ষিপ্ত ৰূপ

	API bot সুৰক্ষা	Proof of Actor
মুখ্য প্ৰশ্ন	এই অনুৰোধ অনুমোদিত নে, authenticated নে আৰু সীমাৰ ভিতৰত আছে নে?	কোন বা কি কাম কৰি আছে, আৰু evidence কি?
সাধাৰণ স্তৰ	API gateway, WAF bot rules, API keys, rate limits	আপোনাৰ API বা MCP server-ৰ ভিতৰত actor classification
চিনাক্ত কৰে	key-ৰ মালিক account বা integration	প্ৰতিটো অনুৰোধৰ পিছফালে থকা actor: Human, Human + AI, Agent বা Unknown
output	Allow, reject, throttle; কেতিয়াবা bot score	এটা class আৰু এটা basis: verified, declared, inferred বা unknown
অস্পষ্ট traffic	key বৈধ হ'লে সাধাৰণতে allow কৰা হয়, অথবা rule দ্বাৰা reject কৰা হয়	Unknown, route অনুসৰি আপুনি বাছি লোৱা fallback-সহ
response কোনে সিদ্ধান্ত লয়	Gateway আৰু WAF configuration	আপোনাৰ application code
install কৰাৰ পাছত default	Enforcement	Observation; আপুনি policy যোগ নকৰা পৰ্যন্ত একো সলনি নহয়
কিহত সৰ্বোত্তম	Availability, abuse filtering, quotas, accountability	প্ৰতিটো actor-ৰ সৈতে সঠিকভাৱে কাম কৰা আৰু API ব্যৱহাৰ বুজি পোৱা

তলৰ অংশসমূহে প্ৰতিটো অংশ ব্যাখ্যা কৰে।

API bot সুৰক্ষাই ভালকৈ কি কৰে

প্ৰতিটো স্তৰে কি কাম কৰে সেয়া স্পষ্ট হোৱা উচিত, কাৰণ Proof of Actor সকলোৰে কাষে কাষে থাকিবলৈ ডিজাইন কৰা, কাকো সলনি কৰিবলৈ নহয়।

API gateway

Gateway আপোনাৰ API-ৰ মুখ্য প্ৰৱেশদ্বাৰ। ই connection terminate কৰে, API keys বা tokens authenticate কৰে, অনুৰোধসমূহ সঠিক service লৈ route কৰে, quotas enforce কৰে আৰু প্ৰায়ে billing আৰু analytics-ৰ বাবে ব্যৱহাৰ record কৰে। ই "এই caller-ক ভিতৰলৈ যাবলৈ দিয়া হৈছে নে, আৰু কোন দরজাৰে?" প্ৰশ্নটোৰ উত্তৰ দ্ৰুত আৰু স্থিৰভাৱে প্ৰতিটো endpoint-ত দিয়ে।

WAF bot rules

Bot rules থকা web application firewall এ traffic পৰীক্ষা কৰি পৰিচিত attack pattern আৰু অপব্যৱহৃত automation বিচাৰে। ই injection চেষ্টা filter কৰিব পাৰে, অপব্যৱহাৰৰ ইতিহাস থকা উৎসৰ traffic block কৰিব পাৰে, আৰু scraping বা credential attack যেন দেখি তেনে অনুৰোধ challenge বা drop কৰিব পাৰে। যি traffic কেতিয়াও আপোনাৰ code লৈ নাযাব লাগে, তাৰ বিৰুদ্ধে এয়াই আপোনাৰ সৰ্বোত্তম প্ৰতিৰক্ষা।

API keys আৰু tokens

Keys আৰু tokens এ আপোনাক accountability দিয়ে। প্ৰতিটো অনুৰোধ এটা account ৰ সৈতে map হয়, সেয়ে আপুনি জানে কোন integration এ call কৰিলে, আপুনি access revoke কৰিব পাৰে, আৰু ব্যৱহাৰ attribute কৰিব পাৰে। Scoped tokens এ আৰু আগুৱাই যায় আৰু caller এ কি কৰিব পাৰে সেয়া সীমিত কৰে।

Rate limits

Rate limits এ availability সুৰক্ষিত কৰে। সিহঁতে এটা integration ক সকলোৰে বাবে ধাৰ্য কৰা capacity খাই পেলাবলৈ নোৱাৰে, আৰু brute-force আৰু enumeration চেষ্টাসমূহ মন্থৰ কৰে। Per-key আৰু per-route limit এটা মানক, ফলপ্ৰসূ control।

একেলগে এই স্তৰসমূহে সুৰক্ষা আৰু accountability সম্পৰ্কীয় প্ৰশ্নসমূহ খুব ভালকৈ উত্তৰ দিয়ে। সিহঁত ৰাখক।

যি প্ৰশ্নৰ বাবে সিহঁত নিৰ্মিত হোৱা নাছিল

সেই স্তৰসমূহৰ কোনোটোৱেই এটা authenticated অনুৰোধৰ পিছফালে কোন ধৰণৰ actor আছে সেয়া ক'বলৈ নিৰ্মিত নহয়। এটা বৈধ key এ কোন account এ integration-ৰ মালিক সেয়া কয়। ই এইবোৰ নকয়:

এই নিৰ্দিষ্ট call টো আপোনাৰ customer ৰ app-ত button টিপা এজন ব্যক্তিৰ পৰা আহিছিল নে,
এজন ব্যক্তিয়ে কোনো AI assistant ক action কৰিবলৈ কৈছিল নে,
কোনো autonomous agent এ দীঘলীয়া task ৰ এটা পদক্ষেপ হিচাপে call কৰিছিল নে,
বা কোনেও নিশ্চিতকৈ ক'ব নোৱাৰে নে।

এই পাৰ্থক্যটো প্ৰতি মাহে আৰু অধিক গুৰুত্বপূর্ণ হৈ উঠিছে। এটা API যি CRM integration, scheduling tool বা developer platform serve কৰে, increasingly একেটা key-ৰ মাজেৰে agent traffic পায় যি human-driven appসমূহকো serve কৰে। যদি আপুনি agents ক structured response দিব বিচাৰে, agents-দ্বাৰা চালিত উচ্চ-প্ৰভাৱযুক্ত write-ৰ বাবে confirmation বিচাৰে, AI-assisted submission লেবেল কৰিব বিচাৰে, বা কেৱল আপোনাৰ API ব্যৱহাৰৰ কিমান অংশ agent-driven সেয়া জুখিব বিচাৰে, তেন্তে actor context লাগিব।

Proof of Actor এ এটা API-লৈ কি যোগ কৰে

প্ৰতিটো interaction-ৰ বাবে Proof of Actor এ চাৰিটা class-ৰ এটা প্ৰতিবেদন কৰে:

Human: observable signal-এ human-directed interaction দেখুৱায়।
Human + AI: এজন ব্যক্তিয়ে AI সহায়ত interaction নিৰ্দেশ কৰিছে, যি supported integration ৰ জৰিয়তে declared বা observed হৈছে।
Agent: automated বা agent-origin interaction।
Unknown: evidence এ নিৰ্ভৰযোগ্য সিদ্ধান্ত সমৰ্থন নকৰে।

প্ৰতিটো result-এ evidence basis ও কয়:

Verified: উদাহৰণস্বৰূপে, প্ৰকাশিত key-ৰ বিপৰীতে checked কৰা HTTP Message Signature (RFC 9421)।
Declared: client বা আপোনাৰ নিজৰ application এ তাক উল্লেখ কৰিছে।
Inferred: আচৰণগত বা প্ৰাসংগিক signal, inference বুলি স্পষ্টভাৱে লেবেল কৰা।
Unknown: কোনো নিৰ্ভৰযোগ্য basis নাই।

APIসমূহৰ বাবে verified basis বিশেষভাৱে উপযোগী। নিজৰ অনুৰোধ স্বাক্ষৰ কৰা agents-সমূহক তেওঁলোকৰ প্ৰকাশিত key-ৰ সৈতে পৰীক্ষা কৰিব পাৰি, আৰু এয়াই IETF Web Bot Auth কামৰ পিছফালৰ পদ্ধতি। Background-ৰ বাবে Web Bot Auth for product teams explainer চাওক, আৰু implementation দিশৰ বাবে verifying signed agent requests guide চাওক।

ইয়াত এটা সীমা গুৰুত্বপূর্ণ। বৈধ signature এ কোন key এ অনুৰোধ স্বাক্ষৰ কৰিলে সেয়া প্ৰমাণ কৰে। ই agent এ action কৰিবলৈ অধিকৃত সেয়া প্ৰমাণ নকৰে। Authorization আপোনাৰ API-ৰ নিজস্ব access control-তেই থাকে। agent authorization entry এ পাৰ্থক্যটো ব্যাখ্যা কৰে।

Scores আৰু keys বনাম actor evidence

কিছুমান bot protection product এ প্ৰতিটো অনুৰোধত এটা score যোগ কৰে। Block সিদ্ধান্তৰ বাবে score কাৰ্যক্ষম। API product সিদ্ধান্তৰ বাবে সেয়া কম উপযোগী, কাৰণ ই কোৱা নাই যে বৈধ অনুৰোধটো human-driven আছিল নে agent-driven, আৰু ই verified fact আৰু inference পৃথকও নকৰে।

API keys-ৰ বিপৰীত সীমা আছে। সিহঁত ownership-ৰ ক্ষেত্ৰত নিখুঁত, কিন্তু actor সম্পৰ্কে নীৰৱ। এজন customer ৰ key এ এটা ঘণ্টাৰ ভিতৰত চাৰিওটা class বহন কৰিব পাৰে।

Proof of Actor এ দুয়োটা পাৰ্থক্য দৃশ্যমান ৰাখে। আপোনাৰ API-এ key-ৰ পৰা account দেখে, Proof of Actor-ৰ পৰা actor class দেখে, আৰু তাক সমৰ্থন কৰা basis দেখে। প্ৰতিটো স্তৰে নিজৰ সৰ্বোত্তম প্ৰশ্নটোৰ উত্তৰ দিয়ে।

প্ৰতিটোটা ক'ত চলে

Gateway আৰু WAF আপোনাৰ network-ৰ edge ত বা আপোনাৰ serviceসমূহৰ সন্মুখত চলে। সুৰক্ষা আৰু quotas-ৰ বাবে সেই স্থান সঠিক।

Proof of Actor আপোনাৰ API logic য'ত থাকে তাত চলে। Founding দলসমূহে Node.js middleware, Next.js, আপুনি নিয়ন্ত্ৰণ কৰা edge layer, generic HTTP API, বা MCP server integration-ৰ জৰিয়তে integrate কৰিব পাৰে। সম্পূর্ণ তালিকাৰ বাবে integrations চাওক। কাৰণ ই আপোনাৰ application-ৰ ভিতৰত চলে, সেয়ে আপোনাৰ API-এ যি জানে সেয়া ব্যৱহাৰ কৰিব পাৰে: route, workflow, client এ নিজকে ঘোষণা কৰিছে নে নাই, আৰু signature verify হৈছে নে নাই।

Routing সিদ্ধান্ত আপোনাৰ code-তেই থাকে

Proof of Actor default হিচাপে একো block নকৰে। ই observation mode ত আৰম্ভ হয়, সেয়ে ইয়াক install কৰিলে আপোনাৰ API কিদৰে respond কৰে তাত কোনো সলনি নহয়। আপুনি প্ৰতিটো endpoint-ত actor mix দেখে, individual result-ৰ evidence পৰ্যালোচনা কৰে, আৰু আপোনাৰ Unknown rate চায়।

যেতিয়া আপুনি সাজু হয়, আপুনি route, actor class আৰু basis অনুসৰি application-defined policy লিখে। সাধাৰণ outcomeসমূহ হৈছে:

Allow: অনুৰোধটো সাধাৰণভাৱে serve কৰক।
Adapt: verified agent-ৰ বাবে structured বা reduced response দিয়ক।
Challenge: এটা অতিৰিক্ত confirmation step বিচাৰক, উদাহৰণস্বৰূপে উচ্চ-প্ৰভাৱযুক্ত write-ৰ বাবে human approval।
Review: action টো কোনো ব্যক্তিয়ে পৰীক্ষা কৰিবলৈ queue কৰক।
Rate-limit: এটা নিৰ্দিষ্ট route-ত এটা নিৰ্দিষ্ট class আৰু basis-ৰ বাবে tighter limit প্ৰয়োগ কৰক।

আপুনি enforcement কৰাৰ আগতে বাস্তৱ traffic-ৰ বিপৰীতে policy preview কৰিব পাৰে, তাৰপাছত route অনুসৰি enforcement কৰিব পাৰে। rolling out actor-aware policies safely guide-এ প্ৰক্ৰিয়াটো আলোচনা কৰে, আৰু protecting sensitive actions without blocking agents এ সাধাৰণ pattern দেখুৱায়।

Unknown API caller সামলোৱা

প্ৰতিটো API-এ এনে traffic পায় যাক confidence-সহ classify কৰিব নোৱাৰি। পৰম্পৰাগত controls-ৰ সৈতে, এটা বৈধ key মানে সাধাৰণতে অনুৰোধটো পাৰ হয়, আৰু অবৈধ key মানে নহয়। মাজত একো নাই।

Proof of Actor এ আপোনাক এটা স্পষ্ট Unknown result দিয়ে আৰু route অনুসৰি fallback বাছি ল'বলৈ দিয়ে। Read-only catalog endpointসমূহ খোলা থাকিব পাৰে। Account changeসমূহে আপোনাৰ বিদ্যমান অধিক কঠোৰ checks বজাই ৰাখিব পাৰে। Bulk exportসমূহ review লৈ যাব পাৰে। অধিক জানিবলৈ handling Unknown traffic আৰু unknown automated traffic চাওক।

সিহঁত কেনেকৈ একেলগে কাম কৰে

এটা শক্তিশালী API setup-এ প্ৰতিটো স্তৰক নিজৰ কামৰ বাবে ব্যৱহাৰ কৰে:

Edge ত, WAF এ অপব্যৱহৃত আৰু malformed traffic filter কৰে।
Gateway ত, keys authenticate হয়, quotas enforce হয় আৰু ব্যৱহাৰ record হয়।
API-ৰ ভিতৰত, Proof of Actor এ পাৰ হোৱা প্ৰতিটো অনুৰোধ classify কৰে আৰু তাৰ basis কয়।
আপোনাৰ handlerসমূহত, policy এ class আৰু basis ব্যৱহাৰ কৰি response বাছি লয়: human-driven call-ৰ বাবে normal handling, verified agent-ৰ বাবে structured response, agent-driven উচ্চ-প্ৰভাৱযুক্ত write-ৰ বাবে confirmation step, Unknown-ৰ বাবে fallback।
Analytics ত, আপোনাৰ দল দেখে কোন actor class এ কোন endpoint আৰু workflow ব্যৱহাৰ কৰে, gateway-ৰ পৰা account data-ৰ সৈতে মিলাই।

এই stack-ত একোৱেই duplicate হোৱা নাই। Gateway এ account জানে, WAF এ threat pattern জানে, আৰু Proof of Actor এ actor জানে।

কেতিয়া কিহত গুৰুত্ব দিয়া উচিত

আপোনাৰ মূল সমস্যা abuse, availability বা unmetered usage হলে প্ৰথমে API bot সুৰক্ষা-ত গুৰুত্ব দিয়ক: auth endpoint-ৰ বিপৰীতে credential attack, আগ্ৰাসী scraping, বা এটা integration এ অন্যসমূহক starvation কৰা।

আপোনাৰ মূল প্ৰশ্ন যদি caller-সমূহৰ বিষয়ে হয় তেন্তে Proof of Actor-ত গুৰুত্ব দিয়ক: আপোনাৰ API traffic-ৰ কিমান অংশ agent-driven, কোন agents এ কোন endpoint কল কৰে, human-driven আৰু agent-driven ব্যৱহাৰ ক'ত পৃথক, আৰু কোন route-এ actor-aware policy বিচাৰে। APIs use case আৰু AI agent identification for APIs অধিক গভীৰকৈ যায়।

প্ৰোডাকশ্যন API চলোৱা বেছিভাগ দলেই দুয়োটাৰ উত্তৰ লাগে।

আৰম্ভ কৰক

Proof of Actor private beta ত আছে। নিৰ্বাচিত founding developer দলসমূহে সহমত হোৱা usage সীমাৰ ভিতৰত 12 months পৰ্যন্ত বিনামূলীয়া access পাব পাৰে, automatic billing নোহোৱাকৈ। early access-ৰ বাবে আবেদন কৰক আৰু আপোনাৰ API আৰু যিসকল caller-ক আপুনি বুজিব বিচাৰে সেইবোৰৰ বিষয়ে আমাক কওক।

ডেভেলপারসকলৰ বাবে

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record

{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}

class: Human, Human + AI, Agent বা Unknown।
basis: প্ৰমাণ কিমান শক্তিশালী: verified, declared, inferred বা unknown।
evidence: ফলাফলৰ পিছৰ signal, যাতে আপোনাৰ দলক কাৰণ দেখা যায়।

observation mode-ত আৰম্ভ কৰক: আপোনাৰ log-ৰ কাষে ফলাফল record কৰক আৰু আপুনি policy বাছি নলৈকে একো সলনি নকৰিব। Node.js integration guide পঢ়ক

সঘনাই সোধা প্ৰশ্নসমূহ

Proof of Actor এ মোৰ API gateway বা WAF ক সলনি কৰে নে?

নহয়। আপোনাৰ gateway এতিয়াও keys authenticate কৰে আৰু quotas enforce কৰে, আৰু আপোনাৰ WAF এতিয়াও অপব্যৱহৃত traffic filter কৰে। Proof of Actor আপোনাৰ APIৰ ভিতৰত চলে আৰু যি অনুৰোধ পাৰ হয় সেইবোৰলৈ actor context যোগ কৰে। আপোনাৰ বিদ্যমান controls বজাই ৰাখক।

যদি প্ৰতিটো caller-ৰ API key থাকে, তেন্তে actor context কিয় লাগে?

API key এ integration ৰ মালিক account ক চিনাক্ত কৰে। কিন্তু ই কোৱা নাই যে কোনো নিৰ্দিষ্ট অনুৰোধ customer ৰ app ত ক্লিক কৰা এজন ব্যক্তি, AI assistant ব্যৱহাৰ কৰা এজন ব্যক্তি, নে কোনো task চলাই থকা autonomous agent ৰ দ্বাৰা চালিত হৈছিল। Proof of Actor এ তাৰ basis-সহ সেইটো প্ৰতিবেদন কৰে।

Proof of Actor এ মোৰ API কল কৰা কোনটো agent সেয়া verify কৰিব পাৰেনে?

যেতিয়া কোনো client এ HTTP Message Signatures (RFC 9421) ৰ সৈতে নিজৰ অনুৰোধ স্বাক্ষৰ কৰে আৰু নিজৰ key প্ৰকাশ কৰে, Proof of Actor এ signature পৰীক্ষা কৰে আৰু verified basis প্ৰতিবেদন কৰে। বৈধ signature এ কোন key এ অনুৰোধ স্বাক্ষৰ কৰিলে সেয়া প্ৰমাণ কৰে। ই agent ক action কৰিবলৈ অধিকৃত বুলি প্ৰমাণ নকৰে, সেয়ে authorization আপোনাৰ code তেই থাকে।

Proof of Actor এ মোৰ API traffic rate-limit বা block কৰিবলৈ আৰম্ভ কৰিব নেকি?

নহয়। ই observation mode ত আৰম্ভ হয় আৰু default হিচাপে একো block নকৰে। Rate-limit হৈছে এটা outcome যি আপুনি policy ত বাছি ল'ব পাৰে, route, actor class আৰু basis-ৰ ভিত্তিত, আৰু enforcement আপোনাৰ নিজৰ code ত থাকে।

এটা API ত Proof of Actor কেনেকৈ যোগ কৰিম?

Founding দলসমূহে Node.js middleware, Next.js, এটা edge integration, বা generic HTTP API ব্যৱহাৰ কৰিব পাৰে। MCP server-ৰ বাবে নিজৰ integration আছে। বিস্তাৰৰ বাবে integrations page চাওক।

যি caller-সমূহক আমি classify কৰিব নোৱাৰোঁ, তেওঁলোকৰ কি হয়?

তেওঁলোকক Unknown হিচাপে প্ৰতিবেদন কৰা হয়, এটা first-class result হিচাপে। আপুনি প্ৰতিটো route-ৰ বাবে fallback বাছি ল'ব পাৰে, উদাহৰণস্বৰূপে read-only endpoint ত allow কৰা আৰু write endpoint ত আপোনাৰ অধিক কঠোৰ checks বজাই ৰখা।

আপোনাৰ app ক কোনে ব্যৱহাৰ কৰিছে জানক।

এটা সৰু founding developer দলৰ বাবে private beta।

Early Access লওক মূল্য তালিকা চাওক

আগতে কথা পাতিবলৈ পচন্দ কৰেনে? Founding team-ৰ সৈতে কথা পাতক