പ്രധാന ഉള്ളടക്കത്തിലേക്ക് കടക്കുക
APIS

നിങ്ങളുടെ API-യെ ആരാണ് വിളിക്കുന്നത് എന്ന് മനസ്സിലാക്കുക.

ഓരോ API അഭ്യർത്ഥനയിലും ആക്ടർ കോൺടെക്‌സ്‌റ്റ് ചേർക്കുക: ഏത് client വിളിക്കുന്നു, തെളിവ് എത്ര ശക്തമാണ്, അതിനെക്കുറിച്ച് നിങ്ങളുടെ API എന്ത് ചെയ്യണം, റൂട്ടനുസരിച്ച്.

Early Access നേടുകഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്ന് പര്യവേക്ഷണം ചെയ്യുക
example-app.test · actor result

POST /api/v1/orders

ഏജന്റ്basis: inferred

തെളിവ്

browser context ഇല്ലാത്തതും automated request pattern ഉള്ളതുമായ API-key ട്രാഫിക്

നിങ്ങളുടെ policy: order സൃഷ്ടിക്കുന്നതിന് മുമ്പ് കൂടുതൽ ശക്തമായ credential ആവശ്യപ്പെടുക

ഒരു API key identity അല്ല, identity permission അല്ല.

മിക്ക API traffic-ും ഏത് account ആണ് പണമടയ്ക്കുന്നത് എന്ന് പറയുന്ന ഒരു credential-ോടെ വരുന്നു, ഏത് client ആണ് വിളിക്കുന്നത് അല്ലെങ്കിൽ ആരാണ് അതിന് നിർദേശം നൽകിയതെന്ന് അല്ല. ചില clients അവരുടെ requests ഒപ്പിടുന്നു, പലരും ഒരു പേര് മാത്രം പ്രഖ്യാപിക്കുന്നു, പലരും ഒന്നും പറയുന്നില്ല.

ഓരോ API-യും ഉത്തരം നൽകേണ്ട മൂന്ന് ചോദ്യങ്ങളെ Proof of Actor വേർതിരിക്കുന്നു, അതിനാൽ ഓരോന്നിനും ശരിയായ evidence ഉം ശരിയായ control ഉം ലഭിക്കുന്നു.

വേറെ വേറെ മൂന്ന് ചോദ്യങ്ങൾ
  • ആരാണ് വിളിക്കുന്നത്?ആക്ടർ ഐഡന്റിറ്റി: ഒപ്പ്, പ്രഖ്യാപനം അല്ലെങ്കിൽ അനുമാനം
  • ഏത് credential?നിങ്ങളുടെ API key, OAuth token അല്ലെങ്കിൽ session
  • അത് എന്ത് ചെയ്യാൻ സാധ്യതയുണ്ട്?നിങ്ങളുടെ authorization and policy

Proof of Actor ആദ്യത്തേതിന് മറുപടി നൽകുന്നു. മറ്റുരണ്ടത് നിങ്ങളുടെ stack-ിൽ തന്നെ തുടരും.

API ടീമുകൾ actor context ഉപയോഗിച്ച് ചെയ്യുന്നത്

  • ഒപ്പിട്ട ക്ലയന്റുകളെ തിരിച്ചറിയുക

    പ്രസിദ്ധീകരിച്ച keys നോടു അപേക്ഷകളുടെ signatures താരതമ്യം ചെയ്ത്, ഒരു അപേക്ഷ ഏത് operator ന്റെതാണെന്ന് കാണുക.

  • declarations-നെ declarations ആയി തന്നെ പരിഗണിക്കുക

    സ്വയം പ്രഖ്യാപിച്ച client പേരുകൾ രേഖപ്പെടുത്തുകയും, അവയെ verified identity-യിൽ നിന്ന് വേറിട്ടുവയ്ക്കുകയും ചെയ്യുക.

  • ഓരോ റൂട്ടിനുമുള്ള നയങ്ങൾ

    low-impact reads സ്വതന്ത്രമായി അനുവദിക്കുക, writes, high-impact endpoints എന്നിവയിൽ കൂടുതൽ ചോദിക്കുക.

  • ഓരോ caller-നെയും കാണുക

    unknown ones ഉൾപ്പെടെ ഏത് clients ഏത് endpoints ഉപയോഗിക്കുന്നു എന്ന് മനസ്സിലാക്കുക.

  • credentials വേറിട്ടു സൂക്ഷിക്കുക

    API keys-നും OAuth-നും ഇപ്പോഴും access തീരുമാനിക്കുന്നു. Actor context ആരാണ് വിളിക്കുന്നത് എന്ന് ചേർക്കുന്നു.

  • Unknown വേണ്ടി പദ്ധതി

    ഒരു caller ഉപയോഗിക്കാവുന്ന തെളിവൊന്നും നൽകാത്തപ്പോൾ എന്ത് സംഭവിക്കണം എന്ന് ഓരോ route-ലും നിർവചിക്കുക.

01 · കണ്ടെത്തുക

ഓരോ request-ിൽ നിന്നുമുള്ള evidence.

സർവർ, എഡ്ജ്, HTTP API ഇന്റഗ്രേഷനുകൾ അഭ്യർത്ഥനാ സിഗ്നേച്ചറുകൾ, പ്രഖ്യാപിച്ച ക്ലയന്റ് വിശദാംശങ്ങൾ, അഭ്യർത്ഥനാ കോൺടെക്സ്റ്റ് എന്നിവ വായിച്ച്, ഓരോന്നിനെയും അതിന്റെ ആധാരത്തോടെ ലേബൽ ചെയ്യുന്നു.

  • പ്രസിദ്ധീകരിച്ച keys-നെതിരെ സ്ഥിരീകരിച്ച HTTP message signatures.
  • Declared client names declarations ആയി രേഖപ്പെടുത്തിയിരിക്കുന്നു.
  • നിങ്ങളുടെ server, gateway അല്ലെങ്കിൽ edge-യിൽ നിന്ന് request context നേടുക.
സിഗ്നലുകൾ · ഓരോ ഉറവിടത്തിനും അവസാന അഭ്യർത്ഥന
  • അഭ്യർത്ഥന സിഗ്നേച്ചർvalid · sample-crawler.exampleverified
  • Client പ്രഖ്യാപനം"research-assistant/2.1"declared
  • ബ്രൗസർ ഇടപെടൽpointer + keyboard eventsinferred
  • supported signals ഇല്ലroute not instrumentedunknown

02 · മനസ്സിലാക്കുക

ഏത് endpoint ആണ് ആരാണ് ഉപയോഗിക്കുന്നത് എന്ന് അറിയുക.

ഓരോ route-ലുമുള്ള actor mix കാണുക, ഏത് operators ആണ് നിങ്ങളെ കൂടുതലായി ബന്ധപ്പെടുന്നത്, unknown callers എവിടെയാണ് കേന്ദ്രീകരിക്കുന്നത് എന്നതും കാണുക.

  • route അനുസരിച്ചും operator അനുസരിച്ചും callers.
  • ഓരോ വർഗ്ഗീകരണത്തിന്റെയും പിന്നിലെ തെളിവ്.
  • ഓരോ endpoint-നുമുള്ള unknown നിരക്ക്.
route അനുസരിച്ചുള്ള traffic · 7 days
  • /dashboardഅജ്ഞാതം 7%
  • /api/v1/catalogഅജ്ഞാതം 15%
  • /support/ticketsഅജ്ഞാതം 8%
  • /signupഅജ്ഞാതം 21%
മനുഷ്യൻമനുഷ്യൻ + AIഏജന്റ്അജ്ഞാതം

03 · വഴിമാറിക്കുക

സ്വാധീനത്തിന് യോജിച്ച നിയന്ത്രണങ്ങൾ.

route-level policies എഴുതുക: verified agents നു structured responses, declared clients നു standard limits, high-impact actions നു കൂടുതൽ ശക്തമായ credentials.

  • റൂട്ട്, class, basis എന്നിവ പ്രകാരമുള്ള നയങ്ങൾ.
  • അത് പ്രധാനപ്പെട്ടപ്പോൾ കൂടുതൽ ശക്തമായ credentials-ലേക്ക് മാറുക.
  • നിരീക്ഷിക്കുക, preview ചെയ്യുക, തുടർന്ന് enforce ചെയ്യുക.
policy · example-app.test
  • /api/v1/catalogenforceഏജന്റ്അനുവദിക്കുക · structured API
  • /support/ticketsenforceമനുഷ്യൻ + AIഅനുവദിക്കുക · AI-assisted ആയി ലേബൽ ചെയ്യുക
  • /account/*previewഅജ്ഞാതംനിലവിലുള്ള checks നിലനിർത്തുക
  • /api/v1/orderspreviewഏജന്റ്കൂടുതൽ ശക്തമായ credential ആവശ്യപ്പെടുക

ഉദാഹരണ തീരുമാനങ്ങൾ

request മുതൽ result വരെ, പിന്നീട് നിങ്ങളുടെ decision വരെ.

  • ഒരു 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 route: default rate limit ഉപയോഗിച്ച് allow ചെയ്യുക.

അപകടം കൂടാതെ പുറത്തിറക്കുക

ടീമുകൾ observation mode-ൽ ആരംഭിച്ച് route by route ആയി മുന്നോട്ട് പോകുന്നു.

  1. 01

    ഓരോ route-ഉം observe ചെയ്യുക

    നിങ്ങളുടെ API-യുടെ മുൻപിൽ middleware അല്ലെങ്കിൽ HTTP API ചേർക്കുക. signatures, declarations, Unknown callers എന്നിവ ഓരോ route-നുമാണ് രേഖപ്പെടുത്തുന്നത്.

  2. 02

    route policies preview ചെയ്യുക

    അവ പ്രയോഗിക്കുന്നതിന് മുൻപ്, യഥാർത്ഥ traffic-ിൽ agent rate limits അല്ലെങ്കിൽ step-up credentials എന്ത് ചെയ്തേനെന്നത് പരിശോധിക്കുക.

  3. 03

    പ്രഭാവം അനുസരിച്ച് enforce ചെയ്യുക

    reads തുറന്നുവെയ്ക്കുക, writes കൂടുതൽ കർശനമാക്കുക, access നിയന്ത്രിക്കുന്നത് API keys ഉം OAuth ഉം ആക്കുക.

നിങ്ങളുടെ stack നൊപ്പം പ്രവർത്തിക്കുന്നു

  • Founding ടീമുകൾ

    വെബ് സർവർ മിഡിൽവെയർ (Node.js)

    Server-side

    server-rendered apps-നും APIs-നും വേണ്ടി request-level signals.

  • Founding ടീമുകൾ

    Next.js

    സർവർ-സൈഡും എഡ്ജും

    page, API routes എന്നിവയ്ക്കുള്ള middleware.

  • Founding ടീമുകൾ

    ബ്രൗസർ script

    ബ്രൗസർ signals മാത്രം

    ഒരു server-side integration നോടൊപ്പം browser sessions-ൽ നിന്നുള്ള interaction signals.

  • Founding ടീമുകൾ

    Cloudflareയും edge runtimeകളും

    Edge

    അഭ്യർത്ഥനകൾ നിങ്ങളുടെ origin-ലേക്ക് എത്തുന്നതിന് മുമ്പ് എഡ്ജിലെ സിഗ്നലുകൾ.

  • Founding ടീമുകൾ

    സാമാന്യ HTTP API

    ഏതെങ്കിലും stack

    ഒരു API-ലേക്ക് request context അയച്ച്, അതിന്റെ basis സഹിതം ഒരു result സ്വീകരിക്കുക.

  • Founding ടീമുകൾ

    MCP സർവർ

    MCP

    MCP ടൂൾ കോളുകൾക്കായുള്ള ആക്ടർ കോൺടെക്‌സ്‌റ്റ്.

  • റോഡ്‌മാപ്പ്

    WordPress

    Plugin

    WordPress സൈറ്റുകൾക്കുള്ള പ്ലഗിൻ.

  • റോഡ്‌മാപ്പ്

    നേറ്റീവ് മൊബൈൽ

    iOS and Android

    Native iOS, Android SDKs.

ഓരോ founding team-നോടുമൊപ്പം onboarding സമയത്ത് integrations കൈകാര്യം ചെയ്ത് നൽകുന്നു. വേറൊരു stack ആണോ ഉപയോഗിക്കുന്നത്? അപേക്ഷിക്കുമ്പോൾ ഞങ്ങളോട് പറയുക.

കൂടുതൽ അറിയുക

Detection & Limitations വായിക്കുക

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

clients അവരുടെ requests sign ചെയ്യേണ്ടതുണ്ടോ?

ഇല്ല. ഒപ്പിട്ട requests ആണ് ഏറ്റവും ശക്തമായ evidence നൽകുന്നത്, എന്നാൽ Proof of Actor declarations, inferences എന്നിവയും രേഖപ്പെടുത്തുന്നു, ഓരോന്നിനും അതിന്റെ basis ലേബൽ ചെയ്യുന്നു, മതിയായതു ഇല്ലെങ്കിൽ Unknown റിപ്പോർട്ട് ചെയ്യുന്നു.

ഒരു valid signature ഉണ്ടെന്നത് client-ന് പ്രവർത്തിക്കാൻ അനുവാദമുണ്ട് എന്നർത്ഥമാണോ?

ഇല്ല. request ഒരു published identifier-ുമായി ബന്ധപ്പെട്ട key ഉപയോഗിച്ച് ഒപ്പിട്ടതാണെന്ന് അത് കാണിക്കുന്നു. ആ operator എന്ത് ചെയ്യാമെന്ന് നിങ്ങളുടെ authorization, policy എന്നിവയാണ് തീരുമാനിക്കുന്നത്.

ഇത് API keys അല്ലെങ്കിൽ OAuth മാറ്റിസ്ഥാപിക്കുമോ?

ഇല്ല. credentials തന്നെയാണ് access നിയന്ത്രിക്കുന്നത്. Proof of Actor വിളിക്കുന്നത് ആര് അല്ലെങ്കിൽ എന്താണ് എന്ന് ചേർക്കുന്നു, അതിനാൽ നിങ്ങൾക്ക് മുകളിൽ കൂടുതൽ നല്ല policies പ്രയോഗിക്കാം.

ഓരോ endpoint നും വ്യത്യസ്ത നിയമങ്ങൾ നമുക്ക് സജ്ജീകരിക്കാമോ?

അതെ. Policies ഓരോ route നും പ്രത്യേകം എഴുതുന്നതിനാൽ, read-only endpoints ഉം high-impact writes ഉം വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യാം.

അതിന്റെ ചെലവ് എത്രയാണ്?

തിരഞ്ഞെടുത്ത founding developer teams-ന് ധാരണയായ usage limits-ിനുള്ളിൽ 12 മാസത്തോളം free ലഭിക്കാം.

നിങ്ങളുടെ API-യെ വിളിക്കുന്നത് ആരാണെന്ന് അറിയുക.

Proof of Actor founding developer program-ിൽ ചേരുക.

Early Access നേടുകഡെവലപ്പർ ഹബ്

ആദ്യം സംസാരിക്കണമോ? സ്ഥാപകരുമായി സംസാരിക്കുക