Eagle Eye Video API
Check the Eagle Eye API and authentication flow for the required customer scope. Review media access, event retrieval and retention before implementation.
Sources and scopeSource record 25 August 2026
Technical source record: 25 August 2026. Check the linked documentation for current product requirements.
Inherited check dated 10 September 2026. Supporting evidence for this inherited check has not been independently confirmed.
Recorded scope: The Eagle Eye API v3 getting started page was checked for OAuth authorisation code onboarding, application registration and redirect requirements. No cloud account operations were performed.
Public Eagle Eye developer documentation reviewed on 25 August 2026; exact account entitlements, service hosts, rate limits, media codecs, retention, device support, and endpoint schemas require the live v3 reference and authorised tenant.
On this page
Overview#
Vendor APIs / VMS and cloud video / Eagle Eye Networks
Eagle Eye Networks publishes a Video API v3 for cloud video integrations. The current documentation covers OAuth based authorisation, camera/resources, live and recorded media, events and alerts, Server Sent Events (SSE), webhooks, and list pagination. V3 identity is materially different from older V2 API key patterns; new work should follow the current v3 contract.
Documented scope and access#
| Area | Publicly documented contract | Access boundary |
|---|---|---|
| Developer application | Client registration and credentials through the developer programme | Account/approval and secret custody required |
| User delegated authorisation | OAuth 2.0 Authorisation Code flow and user consent | Application acts only within granted customer/user authority |
| Service integration | A vendor enabled machine to machine option can issue a non rotating refresh token after a user completes authorisation | This is not OAuth client credentials; eligibility, authorisation, token custody, revocation, and scope remain account controlled |
| Camera/resources | Enumerate authorised cameras and related resources | Customer account, permissions and pagination apply |
| Media | Live and recorded viewing modes with documented media/session workflows | Codec, time range, entitlement, concurrency and token lifetime apply |
| Events | Query/event model plus SSE and webhook subscription approaches | Delivery/replay behaviour must be designed from the selected guide |
Authentication and authorisation#
Use V3 OAuth; don't copy a V2 key example into a V3 application. For user facing integrations, use Authorisation Code with state validation and the exact registered redirect URI. Keep the client secret and token exchange in a confidential backend, not browser JavaScript or a mobile package. Store access/refresh credentials in an approved secret store and never log them.
The documented machine to machine path is still established through user authorisation and, when enabled by Eagle Eye, returns a non rotating refresh token for the service. It isn't the OAuth client credentials grant. Treat that refresh token as a long lived high value secret, define explicit revocation/offboarding, and don't describe it as automatic workload identity.
The account supplies region/service routing information. Don't hard code a host copied from another customer or geography. Bind authorisation to the customer account and validate that returned resources remain within the expected tenant.
Use the narrowest scopes/permissions and separate media playback/export from administration or camera control. User consent isn't a substitute for the application’s own role and purpose checks.
Cameras, pagination, and reconciliation#
The camera list reference documents pagination. Follow response links/cursors and the endpoint’s declared limit semantics rather than inventing page arithmetic. Treat identifiers as opaque. Cache only with an expiry and re enumerate after authorisation, site or camera changes.
No stable public global request rate number was verified for this page. Obtain current limits from the developer account/reference and implement 429 and transient error backoff without hiding sustained quota or authorisation failures.
Events, SSE, and webhooks#
Choose SSE for a managed long lived client connection and webhooks when Eagle Eye should deliver to a controlled HTTPS receiver. For either:
- establish event types and filters from the current schema;
- persist event ID, source time, ingest time, camera/account and correlation;
- expect reconnect and duplicate delivery unless the contract explicitly says otherwise;
- detect gaps and reconcile using query APIs within the documented retention window;
- authenticate webhook origin using the vendor documented mechanism;
- acknowledge only after durable acceptance;
- bound payload, retries, queue depth and processing time.
Never infer “person present” or “alarm handled” solely from event delivery.
Media boundary#
Use the documented live/recorded media workflow and session lifetime. Don't construct media URLs, share session tokens, disable TLS validation or make a private stream publicly cacheable. Bound requested time ranges, concurrent sessions and local buffers. Preserve original evidence through the platform’s supported export path; a decoded frame or browser recording isn't equivalent.
Lifecycle and compatibility#
Monitor the developer portal for V3 changes and V2 retirement guidance. Record client type, consent/scopes, account/region, API documentation revision, media mode and event delivery contract. Treat mutable limits and hosts as configuration discovered from the authorised environment.
Primary sources#
- Video API v3 getting started, current API generation and onboarding.
- Using the API, authentication and application access model.
- Event subscriptions, SSE and webhook approaches.
- Events, alerts, and notifications, event domain entry point.
- Watch live video, documented media workflows.
- List cameras, resource and pagination reference.