আপোনাৰ API-লৈ কোনে call কৰিছে সেয়া বুজক।
প্ৰত্যেক API request লৈ এক্টৰ প্ৰসংগ যোগ কৰক: কোনটো client call কৰিছে, evidence কিমান শক্তিশালী, আৰু আপোনাৰ API-য়ে সেই অনুসৰি কি কৰিব লাগে, ৰুট অনুসৰি।
POST /api/v1/orders
প্ৰমাণ
browser context নথকা আৰু automated request pattern থকা API-key traffic
আপোনাৰ policy: order সৃষ্টিৰ আগতে অধিক শক্তিশালী credential বিচাৰক
API key এটা পৰিচয় নহয়, আৰু পৰিচয় permission নহয়।
বেছিভাগ API traffic এনে credentialৰে আহে যিয়ে কোন accountে ধন দিছে সেইটো কয়, কিন্তু কোন client কল কৰিছে বা কাকদৰে নিৰ্দেশ দিয়া হৈছে সেইটো নহয়। কিছুমান clientে নিজৰ request sign কৰে, বহুতে কেৱল এটা নাম ঘোষণা কৰে, আৰু বহুতে একো নকয়।
Proof of Actor-এ প্ৰতিটো API-এ উত্তৰ দিবলগীয়া তিনিটা প্ৰশ্ন পৃথক কৰে, যাতে প্ৰতিটোতে সঠিক evidence আৰু সঠিক control থাকে।
- কোন call কৰি আছে?এক্টৰ পৰিচয়: signature, declaration বা inference
- কোন credential?আপোনাৰ API key, OAuth token বা session
- ই কি কৰিব পাৰে?আপোনাৰ authorization আৰু policy
Proof of Actor-এ প্ৰথমটোৰ উত্তৰ দিয়ে। আপোনাৰ stack-এ বাকী দুটা ৰাখে।
API team সকলে actor context লৈ কি কৰে
স্বাক্ষৰিত clients চিনাক্ত কৰক
প্ৰকাশিত key ৰ সৈতে request signature পৰীক্ষা কৰক আৰু কোনো request কোন operator ৰ অন্তৰ্গত সেয়া চাওক।
declaration-সমূহক declaration হিচাপেই গণ্য কৰক
স্ব-ঘোষিত client নামসমূহ record কৰক, আৰু সিহঁতক verified identity-ৰ পৰা পৃথক ৰাখক।
route প্ৰতি policy
low-impact read-সমূহ freely অনুমতি দিয়ক আৰু write আৰু high-impact endpoint-ৰ ক্ষেত্ৰত অধিক বিচাৰক।
প্ৰতিটো caller দেখক
কোন client-এ কোন endpoint ব্যৱহাৰ কৰে, Unknown endpoint-সহ, সেয়া বুজক।
credentials পৃথকে ৰাখক
API key আৰু OAuth এ এতিয়াও access সিদ্ধান্ত কৰে। Actor context এ কোনে call কৰিছে সেয়া যোগ কৰে।
Unknown-ৰ বাবে পৰিকল্পনা
প্ৰত্যেক route অনুসৰি caller-এ কোনো ব্যৱহাৰযোগ্য evidence নেদিলে কি হ’ব সেইটো সংজ্ঞায়িত কৰক।
01 · চিনাক্ত কৰক
প্ৰত্যেক request-ৰ পৰা evidence।
সাৰ্ভাৰ, edge আৰু HTTP API ইন্টিগ্ৰেশনে request signatures, declared client details আৰু request context পঢ়ে, আৰু প্ৰতিটোক তাৰ ভিত্তি অনুসৰি চিহ্নিত কৰে।
- প্ৰকাশিত keyৰ বিপৰীতে HTTP message signature যাচাই কৰা হয়।
- ঘোষণা হিচাপে নথিভুক্ত কৰা declared client nameসমূহ।
- আপোনাৰ server, gateway বা edge-ৰ পৰা request context সংগ্ৰহ কৰক।
- request signaturevalid · sample-crawler.exampleverified
- গ্ৰাহক ঘোষণা"research-assistant/2.1"declared
- ব্ৰাউজাৰ পাৰস্পৰিক ক্ৰিয়াpointer + keyboard eventsinferred
- কোনো supported signal নাইroute not instrumentedunknown
02 · বুজক
কোনে কোন endpoint ব্যৱহাৰ কৰে জানক।
প্ৰতিটো route-ত actor mix দেখক, কোন operators-এ আপোনালৈ সৰ্বাধিক call কৰে, আৰু unknown callers ক'ত কেন্দ্ৰীভূত হয় দেখক।
- route আৰু operator অনুসৰি callers।
- প্ৰতিটো classification-ৰ পৃষ্ঠভূমিৰ evidence।
- প্ৰতি endpoint-ত Unknown rate।
- /dashboardঅজ্ঞাত 7%
- /api/v1/catalogঅজ্ঞাত 15%
- /support/ticketsঅজ্ঞাত 8%
- /signupঅজ্ঞাত 21%
03 · ৰাউট কৰক
প্ৰভাৱৰ সৈতে মিল থকা নিয়ন্ত্ৰণ।
route-স্তৰৰ policy লিখক: verified agent ৰ বাবে structured response, declared client ৰ বাবে standard limit, উচ্চ-প্ৰভাৱী action ৰ বাবে অধিক শক্তিশালী credential।
- route, class আৰু basis অনুসৰি policy।
- যেতিয়া প্ৰয়োজন, অধিক শক্তিশালী credential-লৈ আগবাঢ়ক।
- Observe কৰক, preview কৰক, তাৰপাছত enforce কৰক।
- /api/v1/catalogenforceএজেন্টঅনুমতি · structured API
- /support/ticketsenforceমানুহ + AIঅনুমতি · AI-assisted হিচাপে label কৰক
- /account/*previewঅজ্ঞাতবিদ্যমান checks বজাই ৰাখক
- /api/v1/orderspreviewএজেন্টঅধিক শক্তিশালী credential আবশ্যক কৰক
উদাহৰণ সিদ্ধান্তসমূহ
request ৰ পৰা result লৈ, তাৰ পাছত আপোনাৰ সিদ্ধান্তলৈ।
এটা verified agent এ আপোনাৰ catalog পঢ়ে
Request
GET /api/v1/catalog
ফলাফল
এজেন্টbasis: verifiedআপোনাৰ সিদ্ধান্ত
agent rate limit আৰু structured response-ৰ সৈতে অনুমতি দিয়ক।
এটা automated client order দিয়ে
Request
POST /api/v1/orders
ফলাফল
এজেন্টbasis: inferredআপোনাৰ সিদ্ধান্ত
order সৃষ্টিৰ আগতে app-ৰ অধিক শক্তিশালী credential বিচাৰক।
কোনো evidence নথকা client
Request
GET /api/v1/catalog
ফলাফল
অজ্ঞাতbasis: unknownআপোনাৰ সিদ্ধান্ত
Read-only route: default rate limit-সহ allow কৰক।
risk নোহোৱাকৈ rollout কৰক
দলসমূহ observation mode-ত আৰম্ভ কৰে আৰু route অনুসৰি আগবাঢ়ে।
- 01
প্ৰতিটো route observe কৰক
আপোনাৰ API-ৰ আগত middleware বা HTTP API যোগ কৰক। signature, declaration আৰু Unknown caller-সকল প্ৰতিটো route অনুযায়ী ৰেকৰ্ড কৰা হয়।
- 02
route policy preview কৰক
প্ৰয়োগ হোৱাৰ আগতে real traffic-ত agent rate limit বা step-up credential-এ কি কৰিলেহেঁতেন সেয়া চাওক।
- 03
প্ৰভাৱ অনুসৰি enforce কৰক
read খোলা ৰাখক, write অধিক কঠোৰ কৰক, আৰু access-ৰ নিয়ন্ত্ৰণ API key আৰু OAuth-ৰ হাতত ৰাখক।
আপোনাৰ stack-ৰ সৈতে কাম কৰে
- প্ৰতিষ্ঠাপক দলসমূহ
Web server middleware (Node.js)
Server-side
server-rendered apps আৰু APIs-ৰ বাবে request-level signals।
- প্ৰতিষ্ঠাপক দলসমূহ
Next.js
সাৰ্ভাৰ-পক্ষ আৰু edge
পৃষ্ঠা আৰু API routeৰ বাবে middleware।
- প্ৰতিষ্ঠাপক দলসমূহ
ব্ৰাউজাৰ স্ক্ৰিপ্ট
কেৱল browser signals
server-side integration ৰ সৈতে browser sessions ৰ interaction signals।
- প্ৰতিষ্ঠাপক দলসমূহ
Cloudflare আৰু edge runtime
Edge
Request আপোনাৰ origin-ত পোৱাৰ আগতে edge-ত signal।
- প্ৰতিষ্ঠাপক দলসমূহ
সাধাৰণ HTTP API
যিকোনো stack
এটা API-লৈ request context পঠিয়াওক আৰু তাৰ basis সহ এটা result গ্ৰহণ কৰক।
- প্ৰতিষ্ঠাপক দলসমূহ
MCP ছাৰ্ভাৰ
MCP
MCP tool calls ৰ বাবে এক্টৰ প্ৰসংগ।
- Roadmap
WordPress
Plugin
WordPress site-ৰ বাবে plugin।
- Roadmap
স্থানীয় মোবাইল
iOS আৰু Android
Native iOS আৰু Android SDKs।
প্ৰতিটো founding team ৰ সৈতে onboarding সময়ত integrations হাতে-কলমে দিয়া হয়। অন্য stack ব্যৱহাৰ কৰিছে নেকি? আবেদন কৰোঁতে আমাক জনাওক।
সঘনাই সোধা প্ৰশ্নসমূহ
client-এ তেওঁলোকৰ request sign কৰিব লাগেনে?
নহয়। signed requestে আটাইতকৈ শক্তিশালী evidence দিয়ে, কিন্তু Proof of Actorয়ে declaration আৰু inferenceও record কৰে, প্ৰতিটোৰে নিজৰ basis label থাকে, আৰু যথেষ্ট নাথাকিলে Unknown report কৰে।
valid signature মানেই client-এ কাম কৰিবলৈ অনুমতি পোৱা বুলি ধৰা হয় নে?
নহয়। ই দেখুৱায় যে requestটো published identifierৰ সৈতে সংযুক্ত keyৰে sign কৰা হৈছিল। সেই operatorে কি কৰিব পাৰিব সেয়া আপোনাৰ authorization আৰু policyয়ে সিদ্ধান্ত কৰে।
ইয়ে API key বা OAuth-ৰ ঠাই লয় নে?
নহয়। access এতিয়াও credentialেই নিয়ন্ত্ৰণ কৰে। Proof of Actorয়ে কোন বা কি কল কৰিছে সেয়া যোগ কৰে, যাতে আপুনি ওপৰত উন্নত policy প্ৰয়োগ কৰিব পাৰে।
প্ৰতিটো endpoint অনুসৰি পৃথক নিয়ম স্থাপন কৰিব পাৰোনে?
হয়। policy প্ৰতি route অনুসৰি লিখা হয়, সেয়ে read-only endpoint আৰু উচ্চ-প্ৰভাৱী write সমূহক বেলেগকৈ ব্যৱহাৰ কৰিব পাৰি।
ইয়াৰ খৰচ কিমান?
বাছনি কৰা founding developer team-সমূহে সহমত কৰা usage limit-ৰ ভিতৰত 12 months পর্যন্ত বিনামূল্যে পাব পাৰে।
আপোনাৰ API ক কোনে call কৰিছে জানক।
Proof of Actor founding developer program-ত যোগদান কৰক।
আগতে কথা পাতিবলৈ পচন্দ কৰেনে? Founding team-ৰ সৈতে কথা পাতক