ಪ್ರಮುಖ ವಿಷಯಕ್ಕೆ ಬಿಟ್ಟುಬಿಡಿ
APIS

ನಿಮ್ಮ API ಅನ್ನು ಯಾರು ಕರೆದುಕೊಳ್ಳುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ.

ಪ್ರತಿ API request ಗೆ Actor ಸಂದರ್ಭವನ್ನು ಸೇರಿಸಿ: ಯಾವ client ಕರೆಮಾಡುತ್ತಿದೆ, ಸಾಕ್ಷ್ಯದ ಬಲ ಎಷ್ಟು, ಮತ್ತು ನಿಮ್ಮ API ಅದಕ್ಕೆ ಏನು ಮಾಡಬೇಕು, ಮಾರ್ಗದಿಂದ ಮಾರ್ಗಕ್ಕೆ.

ಮುಂಗಡ ಪ್ರವೇಶ ಪಡೆಯಿರಿಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಅನ್ವೇಷಿಸಿ
example-app.test · ನಟ ಫಲಿತಾಂಶ

POST /api/v1/orders

ಏಜೆಂಟ್basis: inferred

ಪುರಾವೆ

ಬ್ರೌಸರ್ ಸಂದರ್ಭವಿಲ್ಲದ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ವಿನಂತಿ ಮಾದರಿಯೊಂದಿಗೆ API ಕೀ ಟ್ರಾಫಿಕ್

ನಿಮ್ಮ policy: order ರಚಿಸುವ ಮೊದಲು ಇನ್ನಷ್ಟು ಬಲವಾದ credential ಅನ್ನು ಕೇಳಿ

API key ಒಂದು identity ಅಲ್ಲ, ಮತ್ತು identity ಒಂದು permission ಅಲ್ಲ.

ಹೆಚ್ಚಿನ API traffic ಒಂದು credential ಜೊತೆಗೆ ಬರುತ್ತದೆ, ಅದು ಯಾವ account ಪಾವತಿಸುತ್ತಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಆದರೆ ಯಾವ client ಕರೆ ಮಾಡುತ್ತಿದೆ ಅಥವಾ ಯಾರು ಅದನ್ನು ಸೂಚಿಸಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಹೇಳುವುದಿಲ್ಲ. ಕೆಲವು clients ತಮ್ಮ requestsಗಳನ್ನು sign ಮಾಡುತ್ತವೆ, ಅನೇಕವು ಕೇವಲ ಹೆಸರು ಮಾತ್ರ declare ಮಾಡುತ್ತವೆ, ಮತ್ತು ಅನೇಕವು ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಪ್ರತಿ API ಉತ್ತರಿಸಬೇಕಾದ ಮೂರು ಪ್ರಶ್ನೆಗಳನ್ನು Proof of Actor ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಸರಿಯಾದ ಸಾಕ್ಷ್ಯ ಮತ್ತು ಸರಿಯಾದ ನಿಯಂತ್ರಣ ಸಿಗುತ್ತದೆ.

ಮೂರು ಪ್ರತ್ಯೇಕ ಪ್ರಶ್ನೆಗಳು
  • ಯಾರು ಕರೆ ಮಾಡುತ್ತಿದ್ದಾರೆ?Actor ಗುರುತು: signature, declaration ಅಥವಾ inference
  • ಯಾವ credential?ನಿಮ್ಮ API key, OAuth token ಅಥವಾ session
  • ಇದು ಏನು ಮಾಡಬಹುದು?ನಿಮ್ಮ authorization ಮತ್ತು policy

Proof of Actor ಮೊದಲ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ. ಉಳಿದ ಎರಡು ನಿಮ್ಮ stack ನಲ್ಲಿ ಉಳಿಯುತ್ತವೆ.

API ತಂಡಗಳು actor context ನೊಂದಿಗೆ ಏನು ಮಾಡುತ್ತವೆ

  • ಸಹಿ ಮಾಡಿದ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಗುರುತಿಸಿ

    ಪ್ರಕಾಶಿತ keys ಗಳ ವಿರುದ್ಧ request signatures ಅನ್ನು ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಒಂದು request ಯಾವ operator ಗೆ ಸೇರಿದೆ ಎಂದು ನೋಡಿ.

  • declarations ಅನ್ನು declarations ಆಗಿಯೇ ಪರಿಗಣಿಸಿ

    ಸ್ವಯಂ ಘೋಷಿತ client ಹೆಸರುಗಳನ್ನು ದಾಖಲಿಸಿ, ಮತ್ತು ಅವನ್ನು verified identity ಯಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಿ.

  • ಪ್ರತಿ ಮಾರ್ಗದ ನೀತಿಗಳು

    ಕಡಿಮೆ ಪರಿಣಾಮದ reads ಅನ್ನು ಮುಕ್ತವಾಗಿ ಅನುಮತಿಸಿ ಮತ್ತು writes ಹಾಗೂ ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ endpoints ಗಳಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಪರಿಶೀಲನೆ ಕೇಳಿ.

  • ಪ್ರತಿ ಕರೆಕೋರನನ್ನು ನೋಡಿ

    ಯಾವ clients ಯಾವ endpoints ಅನ್ನು ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು, unknown ones ಸೇರಿ, ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ.

  • credentials ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಡಿ

    API ಕೀಗಳು ಮತ್ತು OAuth ಇನ್ನೂ ಪ್ರವೇಶವನ್ನು ನಿರ್ಧರಿಸುತ್ತವೆ. Actor ಸಂದರ್ಭವು ಯಾರು ಕರೆ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಸೇರಿಸುತ್ತದೆ.

  • ಅಜ್ಞಾತಕ್ಕೆ ಯೋಜನೆ

    ಪ್ರತಿ route ಗೆ, caller ಬಳಸಬಹುದಾದ evidence ನೀಡದಾಗ ಏನು ನಡೆಯಬೇಕು ಎಂದು ನಿರ್ಧರಿಸಿ.

01 · ಪತ್ತೆಮಾಡು

ಪ್ರತಿ request ನಿಂದ evidence.

ಸರ್ವರ್, ಎಡ್ಜ್ ಮತ್ತು HTTP API ಏಕೀಕರಣಗಳು ವಿನಂತಿ ಸಹಿಗಳು, ಘೋಷಿತ ಕ್ಲೈಯೆಂಟ್ ವಿವರಗಳು ಮತ್ತು ವಿನಂತಿ ಸಂದರ್ಭವನ್ನು ಓದಿ, ಪ್ರತಿ ಒಂದನ್ನೂ ಅದರ ಆಧಾರದೊಂದಿಗೆ ಗುರುತಿಸುತ್ತವೆ.

  • ಪ್ರಕಟಿತ keys ಗಳ ವಿರುದ್ಧ ಪರಿಶೀಲಿಸಲಾದ HTTP message signatures.
  • ಘೋಷಣೆಗಳಾಗಿ ದಾಖಲಿಸಿದ declared client names.
  • ನಿಮ್ಮ server, gateway ಅಥವಾ edge ಇಂದ request context ಅನ್ನು ಪಡೆಯಿರಿ.
ಸಂಕೇತಗಳು · ಪ್ರತಿ ಮೂಲದ ಕೊನೆಯ ವಿನಂತಿ
  • ವಿನಂತಿ ಸಹಿvalid · sample-crawler.exampleverified
  • client ಘೋಷಣೆ"research-assistant/2.1"declared
  • browser ಸಂವಹನpointer + keyboard eventsinferred
  • ಬೆಂಬಲಿತ signals ಇಲ್ಲroute not instrumentedunknown

02 · ಅರ್ಥಮಾಡಿಕೊ

ಯಾರು ಯಾವ endpoint ಅನ್ನು ಬಳಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ.

ಪ್ರತಿ route ನಲ್ಲಿ actor mix ಅನ್ನು ನೋಡಿ, ಯಾವ operators ನಿಮ್ಮನ್ನು ಹೆಚ್ಚು ಸಂಪರ್ಕಿಸುತ್ತಾರೆ, ಮತ್ತು unknown ಕರೆಕೋರರು ಎಲ್ಲಿ ಕೇಂದ್ರೀಕರಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನೋಡಿ.

  • route ಮತ್ತು operator ಪ್ರಕಾರ callers.
  • ಪ್ರತಿ ವರ್ಗೀಕರಣದ ಹಿಂದೆ ಇರುವ ಸಾಕ್ಷ್ಯ.
  • ಪ್ರತಿ endpoint ಗೆ Unknown rate.
route ಪ್ರಕಾರ ಟ್ರಾಫಿಕ್ · 7 ದಿನಗಳು
  • /dashboardಅಜ್ಞಾತ 7%
  • /api/v1/catalogಅಜ್ಞಾತ 15%
  • /support/ticketsಅಜ್ಞಾತ 8%
  • /signupಅಜ್ಞಾತ 21%
ಮಾನವಮಾನವ + AIಏಜೆಂಟ್ಅಜ್ಞಾತ

03 · ಮಾರ್ಗೀಕರಿಸು

ಪರಿಣಾಮಕ್ಕೆ ಹೊಂದುವ ನಿಯಂತ್ರಣಗಳು.

route ಮಟ್ಟದ ನೀತಿಗಳನ್ನು ಬರೆಯಿರಿ: verified agents ಗೆ ಸಂರಚಿತ ಪ್ರತಿಕ್ರಿಯೆಗಳು, declared clients ಗೆ ಮಾನಕ ಮಿತಿಗಳು, ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ ಕ್ರಮಗಳಿಗೆ ಇನ್ನಷ್ಟು ಬಲವಾದ credentials.

  • ಮಾರ್ಗ, class ಮತ್ತು ಆಧಾರದ ಪ್ರಕಾರ ನೀತಿಗಳು.
  • ಅದು ಮುಖ್ಯವಾಗಿರುವಾಗ ಇನ್ನಷ್ಟು ಬಲವಾದ credentials ಗೆ ಮುಂದಡಿ ಇಡಿ.
  • ವೀಕ್ಷಿಸಿ, ಮುನ್ನೋಟ ನೋಡಿ, ನಂತರ 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 ಗೆ, ನಂತರ ನಿಮ್ಮ decision ಗೆ.

  • Verified Agent ನಿಮ್ಮ ಕ್ಯಾಟಲಾಗ್ ಅನ್ನು ಓದುತ್ತದೆ

    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 ಅನ್ನು ಕೇಳಿ.

  • ಯಾವುದೇ ಸಾಕ್ಷ್ಯವಿಲ್ಲದ ಕ್ಲೈಂಟ್

    Request

    GET /api/v1/catalog

    ಫಲಿತಾಂಶ

    ಅಜ್ಞಾತbasis: unknown

    ನಿಮ್ಮ ನಿರ್ಧಾರ

    read-only ಮಾರ್ಗ: ಡಿಫಾಲ್ಟ್ rate limit ಜೊತೆಗೆ ಅನುಮತಿಸು.

ಅಪಾಯವಿಲ್ಲದೆ ಬಿಡುಗಡೆ ಮಾಡಿ

ತಂಡಗಳು observation mode ನಲ್ಲಿ ಆರಂಭಿಸಿ route by route ಮುಂದುವರೆಯುತ್ತವೆ.

  1. 01

    ಪ್ರತಿ route ಅನ್ನು observe ಮಾಡಿ

    ನಿಮ್ಮ API ಯ ಮುಂದೆ middleware ಅಥವಾ HTTP API ಅನ್ನು ಸೇರಿಸಿ. ಸಹಿಗಳು, ಘೋಷಣೆಗಳು ಮತ್ತು Unknown ಕರೆಗಾರರು ಪ್ರತಿ route ಗೆ ದಾಖಲಿಸಲಾಗುತ್ತದೆ.

  2. 02

    route policies ಗಳನ್ನು preview ಮಾಡಿ

    ಅವು ಜಾರಿಗೆ ಬರುವ ಮೊದಲು real traffic ಮೇಲೆ agent rate limits ಅಥವಾ step-up credentials ಏನು ಮಾಡುತ್ತಿತ್ತೋ ಪರಿಶೀಲಿಸಿ.

  3. 03

    ಪ್ರಭಾವದ ಆಧಾರದಲ್ಲಿ ಜಾರಿಗೆ ತರು

    reads ಗಳನ್ನು open ಆಗೇ ಇಡಿ, writes ಗಳನ್ನು ಬಿಗಿಗೊಳಿಸಿ, ಮತ್ತು access ನಿಯಂತ್ರಣದಲ್ಲಿ API keys ಮತ್ತು OAuth ಅನ್ನು ಇರಿಸಿ.

ನಿಮ್ಮ stack ಜೊತೆಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ

  • ಸ್ಥಾಪಕ ತಂಡಗಳು

    ವೆಬ್ ಸರ್ವರ್ ಮಧ್ಯವರ್ತಿ (Node.js)

    Server-side

    server-rendered apps ಮತ್ತು APIs ಗಾಗಿ request-level signals.

  • ಸ್ಥಾಪಕ ತಂಡಗಳು

    Next.js

    ಸರ್ವರ್-ಸೈಡ್ ಮತ್ತು ಎಡ್ಜ್

    ಪುಟ ಮತ್ತು API ಮಾರ್ಗಗಳಿಗಾಗಿ middleware.

  • ಸ್ಥಾಪಕ ತಂಡಗಳು

    browser script

    browser signal ಗಳು ಮಾತ್ರ

    server-side integration ಜೊತೆಗೆ browser sessionsಗಳಿಂದ interaction signals.

  • ಸ್ಥಾಪಕ ತಂಡಗಳು

    Cloudflare ಮತ್ತು edge runtimes

    Edge

    ವಿನಂತಿಗಳು ನಿಮ್ಮ ಮೂಲಕ್ಕೆ ತಲುಪುವ ಮೊದಲು ಎಡ್ಜ್‌ನಲ್ಲೇ ಸಂಕೇತಗಳು.

  • ಸ್ಥಾಪಕ ತಂಡಗಳು

    ಸಾಮಾನ್ಯ HTTP API

    ಯಾವುದೇ stack

    ಒಂದು API ಗೆ request context ಕಳುಹಿಸಿ ಮತ್ತು ಅದರ basis ಹೊಂದಿರುವ ಫಲಿತಾಂಶವನ್ನು ಸ್ವೀಕರಿಸಿ.

  • ಸ್ಥಾಪಕ ತಂಡಗಳು

    MCP ಸರ್ವರ್

    MCP

    MCP tool calls ಗಾಗಿ Actor ಸಂದರ್ಭ.

  • ರೋಡ್‌ಮ್ಯಾಪ್

    WordPress

    Plugin

    WordPress ತಾಣಗಳಿಗಾಗಿ ಪ್ಲಗಿನ್.

  • ರೋಡ್‌ಮ್ಯಾಪ್

    ನೆಟಿವ್ ಮೊಬೈಲ್

    iOS ಮತ್ತು Android

    Native iOS ಮತ್ತು Android SDKಗಳು.

ಪ್ರತಿ founding team ಜೊತೆ onboarding ಸಮಯದಲ್ಲಿ integrations ಅನ್ನು hands-on ರೀತಿಯಲ್ಲಿ ಒದಗಿಸಲಾಗುತ್ತದೆ. ಬೇರೆ stack ಬಳಸುತ್ತಿದ್ದೀರಾ? ನೀವು apply ಮಾಡುವಾಗ ನಮಗೆ ತಿಳಿಸಿ.

ಇನ್ನಷ್ಟು ತಿಳಿಯಿರಿ

Detection ಮತ್ತು Limitations ಓದಿ

ಪದೇಪದೇ ಕೇಳಲಾಗುವ ಪ್ರಶ್ನೆಗಳು

Clients ತಮ್ಮ requests ಗೆ sign ಮಾಡಬೇಕೇ?

ಇಲ್ಲ. Signed requests ಅತ್ಯಂತ ಬಲವಾದ evidence ನೀಡುತ್ತವೆ, ಆದರೆ Proof of Actor declarations ಮತ್ತು inferencesಗಳನ್ನು ಕೂಡ ದಾಖಲಿಸುತ್ತದೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಅದರ basis ಲೇಬಲ್ ಇರುತ್ತದೆ, ಮತ್ತು ಸಾಕಷ್ಟು ಇಲ್ಲದಾಗ Unknown ಅನ್ನು ವರದಿಮಾಡುತ್ತದೆ.

ಮಾನ್ಯ signature ಇದ್ದರೆ client ಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಅನುಮತಿ ಇದೆ ಎಂದರ್ಥವೇ?

ಇಲ್ಲ. request ಒಂದು published identifierಗೆ ಸಂಬಂಧಿಸಿದ key ಮೂಲಕ sign ಆಗಿದೆ ಎಂದು ಇದು ತೋರಿಸುತ್ತದೆ. ಆ operator ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿಮ್ಮ authorization ಮತ್ತು policy ನಿರ್ಧರಿಸುತ್ತವೆ.

ಇದು API keys ಅಥವಾ OAuth ಅನ್ನು ಬದಲಾಯಿಸುತ್ತದೆಯೇ?

ಇಲ್ಲ. credentials ಇನ್ನೂ ಪ್ರವೇಶವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತವೆ. Proof of Actor ಕರೆ ಮಾಡುತ್ತಿರುವವರು ಯಾರು ಅಥವಾ ಏನು ಎಂಬುದನ್ನು ಸೇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಮೇಲ್ಮಟ್ಟದಲ್ಲಿ ಉತ್ತಮ policies ಅನ್ವಯಿಸಬಹುದು.

ಪ್ರತಿ endpoint ಗೆ ವಿಭಿನ್ನ ನಿಯಮಗಳನ್ನು ನಾವು ಹೊಂದಿಸಬಹುದೇ?

ಹೌದು. ನೀತಿಗಳನ್ನು ಪ್ರತಿ route ಗೆ ಬರೆಯಲಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ read-only endpoints ಮತ್ತು high-impact writes ಗಳನ್ನು ವಿಭಿನ್ನವಾಗಿ ನಿರ್ವಹಿಸಬಹುದು.

ಇದರ ವೆಚ್ಚ ಎಷ್ಟು?

ಆಯ್ಕೆಮಾಡಲಾದ founding developer teams ಗಳು ಒಪ್ಪಿಗೆಯಾದ ಬಳಕೆ ಮಿತಿಗಳ ಒಳಗೆ up to 12 months free ಪಡೆಯಬಹುದು.

ನಿಮ್ಮ API ಅನ್ನು ಯಾರು ಕರೆದುಕೊಳ್ಳುತ್ತಿದ್ದಾರೆ ಎಂಬುದನ್ನು ತಿಳಿಯಿರಿ.

Proof of Actor founding developer program ಗೆ ಸೇರಿ.

ಮುಂಗಡ ಪ್ರವೇಶ ಪಡೆಯಿರಿಡೆವಲಪರ್ ಕೇಂದ್ರ

ಮೊದಲು ಮಾತನಾಡಲು ಇಷ್ಟವಿದೆಯೆ? ಸ್ಥಾಪಕರೊಂದಿಗೆ ಮಾತನಾಡಿ