मुख्य सामग्रीकडे जा
APIS

तुमच्या API ला कोण call करत आहे ते समजून घ्या.

प्रत्येक API request मध्ये अॅक्टर संदर्भ जोडा: कोणता client कॉल करत आहे, पुरावा किती मजबूत आहे, आणि तुमच्या API ने त्यावर काय करावे, मार्गानुसार.

लवकर प्रवेश मिळवाते कसे कार्य करते ते अन्वेषित करा
example-app.test · actor result

POST /api/v1/orders

एजंटbasis: inferred

पुरावा

browser context नसलेला आणि automated request pattern असलेला API-key traffic

तुमची policy: order तयार करण्यापूर्वी अधिक मजबूत credential मागा

API key ही identity नाही, आणि identity म्हणजे permission नाही.

बहुतेक API traffic अशा credential सह येतो जे कोणते account पैसे देत आहे हे सांगते, पण कोणता client कॉल करत आहे किंवा त्याला कोणी निर्देश दिला हे नाही. काही clients त्यांच्या requests स्वाक्षरी करतात, अनेक फक्त नाव जाहीर करतात, आणि अनेक काहीच सांगत नाहीत.

Proof of Actor प्रत्येक API ने उत्तर द्याव्या लागणाऱ्या तीन प्रश्नांना वेगळे करते, त्यामुळे प्रत्येकाला योग्य evidence आणि योग्य control मिळतो.

तीन वेगळे प्रश्न
  • कोण कॉल करत आहे?अॅक्टर ओळख: signature, declaration किंवा inference
  • कोणते credential?तुमचा API key, OAuth token किंवा session
  • ते काय करू शकते?तुमचे authorization आणि policy

Proof of Actor पहिल्या प्रश्नाचे उत्तर देते. तुमचा stack उरलेले दोन सांभाळतो.

API टीम्स actor संदर्भासह काय करतात

  • स्वाक्षरी केलेले clients ओळखा

    प्रकाशित keys विरुद्ध request signatures तपासा आणि ती request कोणत्या operator ची आहे ते पहा.

  • declarations ना declarations म्हणूनच वागवा

    स्वतः जाहीर केलेली client नावे नोंदवा आणि ती verified identity पासून वेगळी ठेवा.

  • प्रत्येक मार्गासाठी धोरणे

    कमी-प्रभावी reads ला मुक्तपणे परवानगी द्या आणि writes तसेच उच्च-प्रभावी endpoints साठी अधिक मागा.

  • प्रत्येक caller पहा

    कोणते clients कोणते endpoints वापरतात, unknown ones सहित, ते समजून घ्या.

  • credentials वेगळी ठेवा

    API keys आणि OAuth अजूनही access ठरवतात. Actor context कोण calling करत आहे ते जोडतो.

  • Unknown साठी योजना

    प्रत्येक route नुसार, caller कडून वापरण्याजोगा पुरावा नसल्यास काय होईल ते ठरवा.

01 · शोधा

प्रत्येक request मधील पुरावा.

सर्व्हर, edge आणि HTTP API एकत्रीकरणे request signatures, declared client details आणि request context वाचतात, आणि प्रत्येकाला त्याच्या आधारासह लेबल करतात.

  • प्रकाशित कींविरुद्ध पडताळलेल्या HTTP संदेश स्वाक्षऱ्या.
  • घोषणा म्हणून नोंदवलेली घोषित client नावे.
  • तुमच्या server, gateway किंवा edge कडून request context घ्या.
signals · last request per source
  • request signaturevalid · sample-crawler.exampleverified
  • client घोषणा"research-assistant/2.1"declared
  • ब्राउझर परस्परक्रियाpointer + keyboard eventsinferred
  • समर्थित signals नाहीतroute not instrumentedunknown

02 · समजून घ्या

कोणता endpoint कोण वापरतो ते जाणून घ्या.

प्रत्येक route वरील actor mix पहा, कोणते operators तुम्हाला सर्वाधिक call करतात, आणि unknown callers कुठे जास्त आहेत ते पहा.

  • route आणि operator नुसार कॉलर.
  • प्रत्येक classification मागील पुरावा.
  • प्रत्येक endpoint साठी unknown rate.
route नुसार ट्रॅफिक · 7 दिवस
  • /dashboardअज्ञात 7%
  • /api/v1/catalogअज्ञात 15%
  • /support/ticketsअज्ञात 8%
  • /signupअज्ञात 21%
माणूसमाणूस + AIएजंटअज्ञात

03 · मार्गी लावा

प्रभावाशी जुळणारी नियंत्रणे.

मार्ग-स्तरीय धोरणे लिहा: Verified agents साठी संरचित प्रतिसाद, Declared clients साठी मानक मर्यादा, उच्च-प्रभावी कृतींसाठी अधिक मजबूत credentials.

  • मार्ग, class आणि basis नुसार धोरणे.
  • जिथे गरज असेल तिथे अधिक मजबूत credentials वापरा.
  • निरीक्षण करा, preview करा, मग enforce करा.
policy · example-app.test
  • /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 मागा.

  • पुरावा नसलेला client

    Request

    GET /api/v1/catalog

    परिणाम

    अज्ञातbasis: unknown

    तुमचा निर्णय

    read-only मार्ग: default rate limit सह allow करा.

जोखीम न घेता rollout करा

टीम्स observation mode मध्ये सुरू करतात आणि एकेक route नुसार पुढे जातात.

  1. 01

    प्रत्येक route चे निरीक्षण करा

    तुमच्या API च्या पुढे middleware किंवा HTTP API जोडा. स्वाक्षऱ्या, declarations आणि Unknown कॉलर्स प्रत्येक route नुसार नोंदवले जातात.

  2. 02

    route policies पूर्वावलोकन करा

    agent rate limits किंवा step-up credentials वास्तविक traffic वर लागू होण्यापूर्वी त्यांनी काय केले असते ते तपासा.

  3. 03

    परिणामानुसार enforce करा

    reads खुले ठेवा, writes अधिक कडक करा, आणि access चे नियंत्रण API keys आणि OAuth कडेच ठेवा.

तुमच्या stack सोबत कार्य करते

  • संस्थापक संघ

    वेब सर्व्हर मध्यस्तर (Node.js)

    server-side

    server-rendered apps आणि APIs साठी request-level signals.

  • संस्थापक संघ

    Next.js

    सर्व्हर-साइड आणि edge

    page आणि API routes साठी middleware.

  • संस्थापक संघ

    ब्राउझर स्क्रिप्ट

    फक्त browser संकेत

    browser sessions मधून मिळालेले interaction signals, server-side integration सोबत.

  • संस्थापक संघ

    Cloudflare आणि edge runtimes

    Edge

    requests तुमच्या origin पर्यंत पोहोचण्यापूर्वी edge वरील signals.

  • संस्थापक संघ

    सामान्य HTTP API

    कोणताही stack

    request context एका API कडे पाठवा आणि त्याचा basis असलेला result मिळवा.

  • संस्थापक संघ

    MCP सर्व्हर

    MCP

    MCP tool calls साठी अॅक्टर संदर्भ.

  • रोडमॅप

    WordPress

    Plugin

    WordPress साइट्ससाठी प्लगइन.

  • रोडमॅप

    native mobile

    iOS आणि Android

    native iOS आणि Android SDKs.

onboarding दरम्यान प्रत्येक founding team सोबत integrations प्रत्यक्ष स्वरूपात दिल्या जातात. वेगळा stack वापरत आहात? अर्ज करताना आम्हाला कळवा.

अधिक जाणून घ्या

Detection आणि Limitations वाचा

वारंवार विचारले जाणारे प्रश्न

clients ने त्यांच्या requests वर स्वाक्षरी करणे आवश्यक आहे का?

नाही. स्वाक्षरी केलेल्या requests सर्वात मजबूत evidence देतात, पण Proof of Actor declarations आणि inferences देखील नोंदवते, प्रत्येक त्यांच्या basis सह labeled असते, आणि पुरेसे नसल्यास Unknown अहवालित करते.

वैध signature म्हणजे client ला कृती करण्याची परवानगी आहे असे मानायचे का?

नाही. ते दाखवते की request प्रकाशित identifier शी जोडलेल्या key ने स्वाक्षरी केली होती. तो operator काय करू शकतो हे तुमची authorization आणि policy ठरवतात.

ते API keys किंवा OAuth ची जागा घेते का?

नाही. access अजूनही credentials नियंत्रित करतात. Proof of Actor कोण किंवा काय कॉल करत आहे हे जोडते, त्यामुळे तुम्ही त्यावर अधिक चांगल्या policies लागू करू शकता.

आपण प्रत्येक endpoint साठी वेगवेगळे नियम सेट करू शकतो का?

होय. धोरणे प्रति मार्ग लिहिली जातात, त्यामुळे read-only endpoints आणि उच्च-प्रभावी writes यांना वेगळ्या प्रकारे हाताळता येते.

त्याची किंमत किती आहे?

निवडलेल्या founding developer teams ना agreed usage limits अंतर्गत 12 महिन्यांपर्यंत मोफत सेवा मिळू शकते.

तुमच्या API ला कोण call करत आहे ते जाणून घ्या.

Proof of Actor founding developer program मध्ये सामील व्हा.

लवकर प्रवेश मिळवाविकसक केंद्र

आधी बोलणे पसंत आहे? founders शी बोला