મુખ્ય સામગ્રી પર જાઓ
APIS

તમારા APIને કોણ call કરી રહ્યું છે તે સમજો.

દરેક API request માં એક્ટર કોન્ટેક્સ્ટ ઉમેરો: કયો ક્લાયંટ કૉલ કરી રહ્યો છે, પુરાવા કેટલી મજબૂત છે, અને તમારું 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 call કરી રહ્યો છે અથવા તેને કોણે સૂચના આપી છે તે નહીં. કેટલાક clients તેમની requests sign કરે છે, ઘણા માત્ર નામ જાહેર કરે છે, અને ઘણા કંઈ જ કહેતા નથી.

Proof of Actor દરેક APIએ જવાબ આપવાના ત્રણ પ્રશ્નોને અલગ કરે છે, જેથી દરેકને યોગ્ય evidence અને યોગ્ય control મળે.

ત્રણ અલગ પ્રશ્નો
  • કોણ call કરી રહ્યું છે?એક્ટર ઓળખ: સહી, ઘોષણા અથવા અનુમાન
  • કયા credential?તમારી API key, OAuth token અથવા session
  • તે શું કરી શકે છે?તમારી authorization અને policy

Proof of Actor પ્રથમનો જવાબ આપે છે. તમારી stack બાકીના બે રાખે છે.

API ટીમો actor context સાથે શું કરે છે

  • હસ્તાક્ષરિત clients ને ઓળખો

    પ્રકાશિત keys સામે request signatures તપાસો અને જુઓ કે request કયા operator ની છે.

  • declarationsને declarations તરીકે જ માનવો

    સ્વઘોષિત client names નોંધો અને તેમને verified identity થી અલગ રાખો.

  • દરેક રૂટ માટે policies

    low-impact reads ને સ્વતંત્ર રીતે મંજૂરી આપો અને writes અને high-impact endpoints માટે વધુ માહિતી માંગો.

  • દરેક caller જુઓ

    કયા clients કયા endpoints વાપરે છે તે સમજો, જેમાં unknown onesનો પણ સમાવેશ થાય છે.

  • credentials ને અલગ રાખો

    API keys અને OAuth હજુ પણ access નક્કી કરે છે. actor context ઉમેરે છે કે કોણ call કરી રહ્યું છે.

  • Unknown માટે યોજના

    દરેક route મુજબ, જ્યારે caller કોઈ usable evidence આપે નહીં ત્યારે શું થાય તે નિર્ધારિત કરો.

01 · Detect

દરેક requestમાંથી evidence.

સર્વર, એજ અને HTTP API ઇન્ટિગ્રેશનો request signatures, declared client details અને request context વાંચે છે, અને દરેકને તેના આધાર સાથે લેબલ કરે છે.

  • પ્રકાશિત keys સામે HTTP message signaturesનું verification થયું છે.
  • ઘોષણા તરીકે નોંધાયેલા declared client names.
  • તમારા server, gateway અથવા edgeમાંથી request context મેળવો.
સંકેતો · પ્રત્યેક સ્ત્રોત માટે છેલ્લી વિનંતી
  • request signaturevalid · sample-crawler.exampleverified
  • client declaration"research-assistant/2.1"declared
  • બ્રાઉઝર ઇન્ટરૅક્શનpointer + keyboard eventsinferred
  • કોઈ supported signals નથીroute not instrumentedunknown

02 · Understand

કોણ કયો endpoint વાપરે છે તે જાણો.

દરેક route પર actor mix જુઓ, કયા operators તમને સૌથી વધુ call કરે છે, અને unknown callers ક્યાં એકત્રિત થાય છે તે જુઓ.

  • route અને operator મુજબ callers.
  • દરેક classification પાછળનું evidence.
  • દર endpoint દીઠ Unknown rate.
route મુજબ traffic · 7 days
  • /dashboardઅજ્ઞાત 7%
  • /api/v1/catalogઅજ્ઞાત 15%
  • /support/ticketsઅજ્ઞાત 8%
  • /signupઅજ્ઞાત 21%
માનવમાનવ + AIએજન્ટઅજ્ઞાત

03 · Route

અસરને અનુકૂળ નિયંત્રણો.

route-level policies લખો: verified agents માટે રચિત પ્રતિસાદ, declared clients માટે માનક મર્યાદાઓ, અને high-impact actions માટે વધુ મજબૂત credentials.

  • રૂટ, class અને basis મુજબ policies.
  • જ્યારે મહત્વ હોય ત્યારે વધુ મજબૂત credentials પર જાઓ.
  • observe કરો, 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 વાંચે છે

    અરજી

    GET /api/v1/catalog

    પરિણામ

    એજન્ટbasis: verified

    તમારો નિર્ણય

    agent rate limit અને structured response સાથે મંજૂરી આપો.

  • એક automated client order મૂકે છે

    અરજી

    POST /api/v1/orders

    પરિણામ

    એજન્ટbasis: inferred

    તમારો નિર્ણય

    order બનાવતા પહેલાં app નું વધુ મજબૂત credential માંગો.

  • પુરાવા વિના client

    અરજી

    GET /api/v1/catalog

    પરિણામ

    અજ્ઞાતbasis: unknown

    તમારો નિર્ણય

    Read-only રૂટ: default rate limit સાથે allow કરો.

જોખમ વિના rollout કરો

ટીમો observation mode માં શરૂ કરે છે અને route પ્રમાણે આગળ વધે છે.

  1. 01

    દરેક route observe કરો

    તમારા APIની આગળ middleware અથવા HTTP API ઉમેરો. Signatures, declarations અને Unknown કોલર્સ દરેક route મુજબ નોંધાય છે.

  2. 02

    route policies preview કરો

    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

    સર્વર-સાઇડ અને એજ

    page અને API routes માટે middleware.

  • સ્થાપક ટીમો

    બ્રાઉઝર સ્ક્રિપ્ટ

    માત્ર browser signals

    server-side integration સાથે browser sessions માંથી interaction signals.

  • સ્થાપક ટીમો

    Cloudflare અને edge runtimes

    Edge

    તમારા origin સુધી requests પહોંચે તે પહેલાં edge પર સિગ્નલો.

  • સ્થાપક ટીમો

    સામાન્ય HTTP API

    કોઈપણ stack

    request context ને API પર મોકલો અને તેના આધાર સાથેનું પરિણામ મેળવો.

  • સ્થાપક ટીમો

    MCP સર્વર

    MCP

    MCP tool calls માટે એક્ટર કોન્ટેક્સ્ટ.

  • રોડમૅપ

    WordPress

    Plugin

    WordPress sites માટે plugin.

  • રોડમૅપ

    મૂળભૂત મોબાઇલ

    iOS અને Android

    Native iOS અને Android SDKs.

Onboarding દરમિયાન દરેક founding team સાથે integrations હેન્ડ્સ-ઓન રીતે આપવામાં આવે છે. અલગ stack વાપરો છો? તમે apply કરો ત્યારે અમને કહો.

વારંવાર પૂછાતા પ્રશ્નો

શું clients ને તેમની requests sign કરવાની જરૂર છે?

ના. signed requests સૌથી મજબૂત evidence આપે છે, પરંતુ Proof of Actor declarations અને inferences પણ નોંધે છે, દરેકને તેના basis સાથે labeled કરે છે, અને પૂરતું ન હોય ત્યારે Unknown રિપોર્ટ કરે છે.

શું valid signatureનો અર્થ એ છે કે clientને કાર્ય કરવાની મંજૂરી છે?

ના. તે બતાવે છે કે request published identifier સાથે જોડાયેલી keyથી signed હતી. તે operator શું કરી શકે તે તમારા authorization અને policy નક્કી કરે છે.

શું તે API keys અથવા OAuthને બદલે છે?

ના. credentials હજી પણ access નિયંત્રિત કરે છે. Proof of Actor કોણ અથવા શું call કરી રહ્યું છે તે ઉમેરે છે, જેથી તમે તેના ઉપર વધુ સારી policies લાગુ કરી શકો.

શું આપણે દરેક endpoint માટે અલગ નિયમો ગોઠવી શકીએ?

હા. Policies route પ્રમાણે લખાય છે, તેથી read-only endpoints અને high-impact writesને અલગ રીતે સંભાળી શકાય છે.

તેનો ખર્ચ કેટલો છે?

પસંદ કરેલ founding developer teams agreed usage limits અંદર up to 12 months free મેળવી શકે છે.

તમારા API ને કોણ call કરે છે તે જાણો.

Proof of Actor founding developer program માં જોડાઓ.

પહેલાં વાત કરવી પસંદ કરો છો? સ્થાપકો સાથે વાત કરો