-
Notifications
You must be signed in to change notification settings - Fork 1
Expand file tree
/
Copy pathcamera.yaml
More file actions
4706 lines (4592 loc) · 153 KB
/
Copy pathcamera.yaml
File metadata and controls
4706 lines (4592 loc) · 153 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
openapi: '3.0.2'
info:
title: GoodCam API
version: '1.20.0'
description: |
GoodCam devices provide a REST API, RTSP server and they are also able to
advertise themselves in a local network environment using mDNS and DNS-SD.
# Authentication
Most of the HTTP endpoints require authentication via
[HTTP Digest](https://tools.ietf.org/html/rfc7616). The same authentication
is also required by the RTSP server. It is possible to choose between MD5
and SHA-256 digest when the application is being configured for the first
time. It is not possible to switch between MD5 and SHA-256 later without
factory reset because the HTTP Digest standard itself does not provide any
means for digest algorithm negotiation. The only alternative solution would
be providing `WWW-Authenticate` challenges with all supported algorithms.
Such solution would not make much sense from the security point of view
because any potential attacker could simply choose the weakest digest
algorithm available.
The MD5 digest should be considered deprecated and its use should be
avoided. It's supported only for backwards compatibility with
[RFC 2617](https://tools.ietf.org/html/rfc2617) (the former definition of
HTTP Digest). Unfortunately, even modern web browsers currently don't
support other HTTP Digest algorithms than MD5, so in cases when the API is
being consumed by a web browser, it is possible to use the MD5 algorithm or
it is also possible to use an alternative HTTP client supporting the more
recent version of HTTP Digest. The latter option should be preferred if
possible.
Some web browsers also do not support HTTP Digest for WebSocket, which is
being used for WebRTC signaling. In order to overcome this issue, it is
possible to generate access tokens which can be used as a query parameter.
Whenever there is a valid access token within query string of a request URL
(query parameter `x-goodcam-devicetoken`), HTTP Digest authentication will
be skipped.
# Security considerations
Currently, there is no TLS or other forms of encryption being used. The
REST API is available only via plain HTTP. The reasoning behind is simple.
Using TLS in a local network environment is impractical. There are
basically only two options for using TLS in such environments:
1. Registering a domain name that's globally unique (e.g. xyz.com) and
buying a proper TLS certificate from a CA (or using Let's Encrypt). All
devices in the local network would then have to use a local DNS server
which would be resolving the hostname to a local IP address. Note that
there is no CA that would issue a TLS certificate for a hostname that
cannot be verified as globally unique. Doing so would be a serious
security risk.
2. Using a self-signed certificate (either directly or as a custom CA) and
distributing it to all client devices within the local network. All the
client devices would still have to use a hostname to access the API.
Either of these options are rarely used because it isn't easy to set
everything up without certain technical skills and it may also include some
additional costs. Right now there is no other widely-used option for HTTP
encryption within local networks.
**Because of this, the application services (both HTTP and RTSP) should not
be exposed to the Internet or other outside networks.**
TLS support might be implemented in the future for the REST API to make
exposing the API publicly possible, however, the RTSP protocol does not
support TLS, so exposing it would still be a serious security risk. If
needed, the remote access functionality should be implemented using
[GoodCam Cloud](https://goodcam.github.io/goodcam-api/cloud.html) and
WebRTC.
# Service discovery
GoodCam devices advertise themselves using
[mDNS](https://tools.ietf.org/html/rfc6762) and
[DNS-SD](https://tools.ietf.org/html/rfc6763). The service name is
`_goodcam._tcp.local`, so all you need to do to find a GoodCam device in a
local network is to send an mDNS query asking for `PTR` records named
`_goodcam._tcp.local`. Doing so will yield instance names of all GoodCam
devices within the local network. These instance names can be used then to
retrieve `SRV` and `TXT` records of those instances. The `SRV` records will
then contain the device hostnames and ports where the REST API can be
accessed. The `TXT` records will contain the API version and the root for
the REST API endpoints. The API root is `/api/` by default. And, of course,
the device IP addresses can be retrieved by querying the `A` or `AAAA`
records.
## Example
```text
-> mDNS query (QCLASS, QTYPE, QNAME):
ANY PTR _goodcam._tcp.local
<- mDNS response (RR TYPE, RR DATA):
PTR My\ Camera._goodcam._tcp.local
PTR GoodCam._goodcam._tcp.local
PTR GoodCam\ #11._goodcam._tcp.local
-> mDNS query (QCLASS, QTYPE, QNAME):
ANY SRV My\ Camera._goodcam._tcp.local
<- mDNS response (RR TYPE, RR DATA):
SRV 0 0 80 GC12345678ABCD.local
-> mDNS query (QCLASS, QTYPE, QNAME):
ANY TXT My\ Camera._goodcam._tcp.local
<- mDNS response (RR TYPE, RR DATA):
TXT root=/ version=1
-> mDNS query (QCLASS, QTYPE, QNAME):
ANY A GC12345678ABCD.local
<- mDNS response (RR TYPE, RR DATA):
A 192.168.123.123
```
# Initial setup
When a GoodCam device hasn't been set up before (or after factory reset),
the `initialized` property returned by the
[public info endpoint](#tag/basic/operation/get-public-info) will be set to
`false` and all other API endpoints will be redirecting to `/v1/users/`
indicating that there are no user accounts and the initial setup should be
performed.
The setup itself is simple. The API client is only required to create the
first user account (see
[Creating a new user account](#operation/create-user)).
# WiFi cameras
All wifi cameras are in the AP mode by default. Their SSID is concatenation
of "goodcam-" prefix and the corresponding MAC address without colons, e.g.
"goodcam-112233445566". The prefix is hardcoded into the firmware and it
can be changed upon request. The camera should be connected to an existing
WiFi network as a part of the initial setup (see the example below).
# Factory reset
The factory reset is device-specific and the exact procedure may slightly
vary between different IP camera models. However, GoodCam firmware supports
these three methods:
1. Using [the corresponding API endpoint](#operation/factory-reset). This
method is the most convenient, but it requires knowledge of the user
credentials so it cannot be used when the credentials are lost.
2. Using a physical reset button (if available). The button press is
checked only during the device boot sequence, so the following procedure
is required:
1. Power off the device.
2. Press and hold the reset button.
3. Power on the device while still holding the reset button.
4. Release the reset button after around 15 seconds.
5. Wait until the device erases the settings and finishes the boot
sequence. The device should be reset into factory defaults now.
3. Using a special reset file. This method is available only if the IP
camera supports external storage devices (e.g. SD cards). The file must
be created in the root of an external storage device that will be
attached to the IP camera while the camera is running. The file must be
named `factory-reset.txt` and its content is irrelevant; it may be
empty. When the IP camera detects the file, it will perform factory
reset during the next boot sequence. The following procedure is
required:
1. Create the `factory-reset.txt` file in the root of an external
storage device. The storage device must be formatted with the FAT32
filesystem.
2. If the IP camera is not already powered on, power it on and wait
around 30 seconds to make sure the device has finished the boot
sequence.
3. Attach the external storage device to the IP camera and wait a few
seconds for the device to detect the file.
4. Power off the IP camera.
5. **Detach the external storage.**
6. Power on the IP camera again and wait for it to boot up. The device
should be reset into factory defaults now.
# Example: accessing an Ethernet camera in a mobile app
1. Look up all `_goodcam._tcp.local` services using service discovery.
2. List all instance names in the user interface, e.g.:
* My Camera
* GoodCam
* GoodCam #11
3. Allow entering a camera IP address manually (useful in cases when the
service discovery does not work for some reason).
4. After the user taps on a camera, perform the initial setup (if needed)
and log in to the camera (ask the user for credentials).
5. After successful login, allow changing camera settings, displaying video
streams, taking snapshots, etc.
# Example: accessing a WiFi camera in a mobile app
1. Look up all WiFi Access Points with the "goodcam-" prefix (or your
custom prefix) and list them in the user interface.
2. After the user taps on a camera, connect to the corresponding Access
Point.
3. Look up all `_goodcam._tcp.local` services using service discovery.
(Note: There will be only one.)
4. Perform the initial setup (i.e. create the admin user) and log in to the
camera.
5. List available WiFi networks and let user pick one.
6. Connect the camera to the selected network (i.e. update the camera
network settings).
7. Reboot the camera.
8. Connect the mobile device to the same WiFi network and wait until the
camera becomes available.
servers:
- url: 'http://0.0.0.0/api/'
tags:
- name: basic
x-displayName: Basic information and device control
- name: users
x-displayName: User management
- name: network
x-displayName: Network settings
- name: storage
x-displayName: Storage
- name: exposure
x-displayName: Exposure
- name: privacy-mask
x-displayName: Privacy mask
description: |
The privacy mask allows hiding arbitrary regions in the resulting
video. The regions can be specified using a list of triangle
coordinates. More complex shapes can be composed of multiple triangles
if needed. The triangle coordinates are expected to be decimal numbers
from the interval `[0; 1]` where the point `[0; 0]` represents the top
left corner of the video and `[1; 1]` represents the bottom right
corner of the video.
Each triangle is represented by a list of 6 decimal numbers
representing coordinates of the three corresponding triangle vertices.
For example:
```json
[0.1, 0.1, 0.2, 0.2, 0.3, 0.1]
```
represents a triangle with the following `[x, y]` vertices:
```text
[0.1, 0.1]
[0.2, 0.2]
[0.3, 0.1]
```
- name: osd
x-displayName: OSD
- name: streaming
x-displayName: Streaming
description: |
This section describes configuration of audio/video streams as well as
protocols for retrieving the streams.
Currently there is a support for MJPEG and H.264 video and G.711, PCM
and Opus audio. Other codecs may be added in the future. Not all devices
support all of the codecs. You can get a list of supported codecs using
the API endpoint for
[getting stream limits](#operation/get-stream-limits).
Keep in mind that some encodings are not supported in certain media
containers or streaming protocols. This matrix shows which codecs are
supported where:
| | MJPEG | H.264 | G.711 | PCM | Opus |
| ---- |:-----:|:-----:|:-----:|:---:|:----:|
| **RTSP** | | ● | ● | ● | ● |
| **WebRTC**<sup>1</sup> | | ● | ● | ● | ● |
| **Fragmented MP4 over HTTP**<sup>2</sup> | ● | ● | ● | ● | ● |
| **MJPEG over HTTP** | ● | | | | |
1. *Even though we technically support these codecs in WebRTC, web
browsers are not required to implement all of them. The list of codecs
supported by web browsers can be found
[here](https://developer.mozilla.org/en-US/docs/Web/Media/Formats/WebRTC_codecs).*
2. *Please note that not all players, especially web browsers, support
all of these codecs in the fragmented MP4 container.*
### Media buffer and RTSP/2.0
The media buffer feature is supported only if indicated by the
`media_buffer` flag (see
[getting basic device info](#operation/get-basic-info) for more
information). If enabled, the buffer keeps the last `N` seconds of video
in memory as configured by the `retention` property. The buffered video
can be retrieved using RTSP/2.0 as an initial part of a live stream. This
gives the client a short window of history in cases where it is important
to see what happened _just before now_ (e.g. when recording an incident
into a cloud storage).
Do not confuse the media buffer with recording. The media buffer is just
a short window containing the last `N` seconds of video. There is no
permanent storage. The buffer is cleared on every camera reboot and on
every change of the corresponding stream settings. The buffer has a
limited capacity that depends on the camera model. Usually, it should be
enough to store around 30 seconds of H.264 video with reasonable bitrate.
The lower the bitrate, the more video can be stored in the buffer.
The RTSP/2.0 protocol support should be considered experimental. However,
all RTSP/2.0 features related to the media buffer are considered stable.
The use of media buffer is indicated by the `Random-Access` media
property in the `SETUP` response and the available range is indicated by
the `Media-Range` property. To start streaming from a given position,
simply set the `Range` header in the `PLAY` request. To fetch contents of
the media buffer at a given maximum speed, use the `Speed` header. (Note
that the live video following the contents of the buffer will always be
delivered at `1.0x` speed.) See the
[RTSP/2.0 specification](https://datatracker.ietf.org/doc/html/rfc7826)
for more information.
- name: audio-output
x-displayName: Audio output
- name: recording
x-displayName: Recording
description: |
Each recording, when enabled, corresponds to a single background task
responsible for storing video from a given stream into a given storage.
The video is being stored in form of short video segments. When the
storage gets full, the oldest video segment will be deleted to make space
for new video. The endpoints below provide convenient way for accessing
the recorded video.
When recording to an SD card, make sure that the card is formatted before
you enable the recording. MBR/DOS format with a single primary partition
containing a FAT32 (LBA) file system is required. You can use
[the formatting endpoint](#tag/storage/operation/format-sd-card) to
format your SD card.
**IMPORTANT:** Do not move, rename, delete or modify files in the
storage! This could easily damage the recording index.
- name: motion-detection
x-displayName: Motion detection
description: |
The motion detection engine, if enabled, continuously evaluates video
frames with constant rate of 5 evaluations per second. The API can be
used to configure the motion detection engine and to retrieve motion
detection metadata or to send motion detection events.
The motion detection metadata can be retrieved using WebSocket as a
continuous stream of JSON objects, each describing a single evaluation
(see [Getting motion detection metadata stream](#operation/motion-detection-stream) for more info).
The motion detection engine recognizes internally two states for every
configured hook:
* idle
* alert
By default, each hook is in the _idle_ state. If there is a motion, the
hook immediately transitions to the _alert_ state. If there is no
motion for at least a given amount of time (this can be configured using
the `reset_delay` parameter), the hook transitions back to the _idle_
state.
Whenever a hook transitions to the _alert_ state, a new motion detection
event is generated (unless delayed using the `trigger_delay` parameter).
The event is then sent to the hook target (see below). In situations when
the hook would stay in the _alert_ state for a long time, follow-up
events can be generated. The delay until the next follow-up event can be
configured using the `resend_delay` parameter.
### For webhooks
If the configured HTTP method is POST and the request body isn't
specified, the default body will be a JSON object containing the
following properties:
* `alert_id` - Sequential ID of the motion detection alert. The ID is
incremented on each transition of the hook from the _idle_ state to the
_alert_ state. The ID will be reset to zero on each restart of the
motion detection engine. This includes camera reboots and changes of
the motion detection settings.
* `event_id` - Sequential ID indicating how many events with this alert
ID have been already generated. The first event will have its event
ID set to zero. Each follow-up event (if configured) will then have
the event ID greater than zero.
* `regions` - The most recent list of image regions where motion was
detected (see [Getting motion detection metadata stream](#operation/motion-detection-stream) for more info).
- name: cloud
x-displayName: Cloud client
description: |
The cloud client works as a gateway for remote access to the camera. The
client is responsible for maintaining a permanent connection with a cloud
service. The connection itself is done using HTTP upgrade and
documentation of the corresponding protocol is available
<a href="https://github.com/GoodCam/goodcam-api/tree/master/docs/cloud-server.md" target="_blank">here</a>.
The cloud client supports both HTTP and HTTPS, so it is possible (and
preferable) to secure the connection using TLS.
### Connecting a camera to GoodCam Cloud
In principle, the camera can connect to any cloud service implementing
the underlying protocol, however, the pairing process may be different
with third party cloud providers, so we will focus only on the GoodCam
Cloud service here.
In order to set up your camera for remote access, you will need to:
1. Perform the initial setup (if needed; see [Initial setup](#section/Initial-setup)).
2. Enable the cloud client (see [Changing cloud client settings](#operation/update-cloud-client-settings)).
3. Get the camera device ID (see [Getting information about the cloud client](#operation/get-cloud-client-info)).
4. Initiate pairing for the device ID (see the <a href="cloud.html" target="_blank">GoodCam Cloud API documentation</a>).
5. Connect the camera to the cloud (see [Connecting to the cloud service](#operation/connect-to-cloud)).
Once paired, the camera will maintain a permanent connection with the
cloud service and it will be available for remote access via the GoodCam
Cloud API. The camera can be paired with only one GoodCam Cloud account
at a time and only this user will be able to access the camera remotely.
_Note: The cloud service URL should be set to
`https://proxy.goodcam.io:8888` in order to connect to the GoodCam Cloud
service. Different URLs may be used in order to connect the camera to
another cloud service provider._
- name: gpio
x-displayName: GPIO
description: |
The GPIO subsystem provides an API for controlling digital input/output
pins. Input pins are read-only and you can only retrieve their value.
Output pins can be either set to a given fixed value or you can configure
a custom sequence of actions that will drive the output pins. You can
also group several output pins together and control the whole group.
The endpoints in this section are available only if the `gpio`
[feature](#operation/get-basic-info) is indicated.
- name: ssh
x-displayName: SSH
description: |
You can use the SSH endpoints to enable/disable the SSH service, get a
list of users that can log in via SSH and change their password. By
default, the SSH service is disabled, there is only the `root` user and
the `root` password is unusable, so it needs to be set up first.
paths:
'/':
get:
operationId: 'get-public-info'
tags:
- basic
summary: Getting public info
responses:
'200':
$ref: '#/components/responses/PublicInformationResponse'
'/v1/':
get:
operationId: 'get-basic-info'
tags:
- basic
summary: Getting basic device info
security:
- 'HTTP Digest': []
responses:
'200':
$ref: '#/components/responses/BasicInformationResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
put:
operationId: 'update-basic-info'
tags:
- basic
summary: Updating basic device info
security:
- 'HTTP Digest': []
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
timezone:
$ref: '#/components/schemas/Timezone'
responses:
'200':
$ref: '#/components/responses/BasicInformationResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/reboot/':
post:
operationId: 'reboot'
tags:
- basic
summary: Rebooting the device
security:
- 'HTTP Digest': []
responses:
'204':
description: No Content
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/factory-reset/':
post:
operationId: 'factory-reset'
tags:
- basic
summary: Device factory reset
security:
- 'HTTP Digest': []
responses:
'204':
description: No Content
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/logs/':
get:
operationId: 'get-log-messages'
tags:
- basic
summary: Getting log messages
security:
- 'HTTP Digest': []
responses:
'200':
description: OK
content:
text/plain:
example: |
Apr 11 10:46:55 goodcam user.info goodcam-server[902]: [goodcam_server] Loading application configuration
Apr 11 10:46:56 goodcam user.info goodcam-server[902]: [goodcam_server] Loading user settings
Apr 11 10:46:56 goodcam user.info goodcam-server[902]: [goodcam_http::server] HTTP server started at 0.0.0.0:80
Apr 11 10:46:56 goodcam user.info goodcam-server[902]: [goodcam_rtsp::server] RTSP server started at 0.0.0.0:554
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/firmware/':
get:
operationId: 'get-firmware-information'
tags:
- basic
summary: Getting firmware information
security:
- 'HTTP Digest': []
responses:
'200':
$ref: '#/components/responses/FirmwareInformationResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
post:
operationId: 'update-firmware'
tags:
- basic
summary: Updating firmware
description: |
**Please note that firmware update is a delicate procedure. The device
power must not be interrupted during the firmware update. Doing so can
damage the device irreversibly.**
The firmware update may also factory reset the device depending on the
firmware version. The device will be reset into factory defaults if the
current version of the firmware and the new version of the firmware are
considered incompatible. The firmware (in)compatibility is determined
using these semantic versioning rules:
* `0.a.b` -> `0.a.c` where `c >= b` is considered a compatible update,
* `a.b.c` -> `a.d.e` where `a > 0` and `d >= b` is considered a
compatible update regardless of the relation between `c` and `e`,
* all other updates are considered incompatible and will trigger device
factory reset.
For example:
* `0.2.1` -> `0.1.0` - incompatible
* `0.2.1` -> `0.2.0` - incompatible
* `0.2.1` -> `0.2.1` - compatible
* `0.2.1` -> `0.2.2` - compatible
* `0.2.1` -> `0.3.0` - incompatible
* `2.2.2` -> `1.0.0` - incompatible
* `2.2.2` -> `2.1.0` - incompatible
* `2.2.2` -> `2.2.1` - compatible
* `2.2.2` -> `2.2.2` - compatible
* `2.2.2` -> `2.2.3` - compatible
* `2.2.2` -> `2.3.0` - compatible
* `2.2.2` -> `3.0.0` - incompatible
security:
- 'HTTP Digest': []
requestBody:
required: true
content:
application/octet-stream: {}
responses:
'204':
description: No Content
'303':
$ref: '#/components/responses/Uninitialized'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/exposure/':
get:
operationId: 'get-exposure-info'
tags:
- exposure
summary: Getting exposure information
security:
- 'HTTP Digest': []
responses:
'200':
$ref: '#/components/responses/ExposureInformationResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/exposure/settings/':
get:
operationId: 'get-exposure-settings'
tags:
- exposure
summary: Getting exposure settings
security:
- 'HTTP Digest': []
responses:
'200':
$ref: '#/components/responses/ExposureSettingsResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
put:
operationId: 'update-exposure-settings'
tags:
- exposure
summary: Updating exposure settings
security:
- 'HTTP Digest': []
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/ExposureSettings'
responses:
'200':
$ref: '#/components/responses/ExposureSettingsResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/privacy-mask/':
get:
operationId: 'get-privacy-mask'
tags:
- privacy-mask
summary: Getting current privacy mask settings
description: |
This endpoint is available only if the `privacy_mask`
[feature](#operation/get-basic-info) is indicated.
security:
- 'HTTP Digest': []
responses:
'200':
$ref: '#/components/responses/PrivacyMaskResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
post:
operationId: 'set-privacy-mask'
tags:
- privacy-mask
summary: Setting privacy mask
description: |
This endpoint is available only if the `privacy_mask`
[feature](#operation/get-basic-info) is indicated.
security:
- 'HTTP Digest': []
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/PrivacyMask'
responses:
'200':
$ref: '#/components/responses/PrivacyMaskResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/osd/':
get:
operationId: 'get-osd-settings'
tags:
- osd
summary: Getting OSD settings
description: |
This endpoint is available only if the `osd`
[feature](#operation/get-basic-info) is indicated.
security:
- 'HTTP Digest': []
responses:
'200':
$ref: '#/components/responses/OSDSettingsResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
put:
operationId: 'update-osd-settings'
tags:
- osd
summary: Updating OSD settings
description: |
This endpoint is available only if the `osd`
[feature](#operation/get-basic-info) is indicated.
security:
- 'HTTP Digest': []
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/OSDSettings'
responses:
'200':
$ref: '#/components/responses/OSDSettingsResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/users/':
get:
operationId: 'list-users'
tags:
- users
summary: Listing user accounts
security:
- 'HTTP Digest': []
description: |
The endpoint returns a list of objects describing particular user
accounts. No authentication is required during the initial setup.
responses:
'200':
$ref: '#/components/responses/UserListResponse'
'401':
$ref: '#/components/responses/Unauthorized'
post:
operationId: 'create-user'
tags:
- users
summary: Creating a new user account
security:
- 'HTTP Digest': []
description: |
The endpoint can be used for creating new user accounts and for initial
setup of the camera. No authentication is required during the initial
setup.
requestBody:
required: true
content:
application/json:
schema:
type: object
required:
- username
- password
properties:
username:
type: string
example: admin
password:
type: string
example: '123456'
digest_algorithm:
type: string
enum:
- md5
- sha256
description: |
The field is being used only when creating the first user
account (i.e. the initial setup). It will be silently
ignored when creating any subsequent user accounts. If
omitted during the initial setup, `sha256` will be used as
the default value.
example: md5
responses:
'201':
$ref: '#/components/responses/UserCreatedResponse'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/users/{username}/':
get:
operationId: 'get-user'
tags:
- users
summary: Getting user account details
security:
- 'HTTP Digest': []
parameters:
- name: username
in: path
required: true
schema:
type: string
responses:
'200':
$ref: '#/components/responses/UserDetailsResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: Not Found
put:
operationId: 'update-user'
tags:
- users
summary: Changing user settings
security:
- 'HTTP Digest': []
parameters:
- name: username
in: path
required: true
schema:
type: string
requestBody:
required: true
content:
application/json:
schema:
type: object
properties:
password:
type: string
example: '1234'
responses:
'200':
$ref: '#/components/responses/UserDetailsResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: Not Found
delete:
operationId: 'delete-user'
tags:
- users
summary: Deleting user account
security:
- 'HTTP Digest': []
parameters:
- name: username
in: path
required: true
schema:
type: string
description: |
It isn't allowed to delete a user account if it is the only user
account. Use [factory reset](#operation/factory-reset) in such case.
responses:
'204':
description: No Content
'303':
$ref: '#/components/responses/Uninitialized'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: Not Found
'/v1/users/{username}/token/':
get:
operationId: 'get-access-token'
tags:
- users
summary: Creating an access token
security:
- 'HTTP Digest': []
parameters:
- name: username
in: path
required: true
schema:
type: string
description: |
This endpoint will generate an access token which can be used to access
the API endpoints on behalf of the corresponding user without
authenticating using HTTP Digest. **Even though the access tokens are
valid only for a short period of time, their use should be avoided if
possible.** Especially in cases where they need to be sent unencrypted
(using plain HTTP) over untrusted networks.
The name of the query parameter that can be used to pass access tokens
to the API is `X-GoodCam-DeviceToken`.
responses:
'200':
$ref: '#/components/responses/AccessTokenResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: Not Found
'/v1/network/':
get:
operationId: 'get-network-settings'
tags:
- network
summary: Getting general network settings
security:
- 'HTTP Digest': []
responses:
'200':
$ref: '#/components/responses/NetworkSettingsResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
put:
operationId: 'update-network-settings'
tags:
- network
summary: Changing network settings
security:
- 'HTTP Digest': []
requestBody:
content:
application/json:
schema:
type: object
properties:
device_name:
type: string
description: Name of the device (used as DNS-SD instance
name). The device name cannot exceed 63 bytes when encoded
as UTF-8.
example: My Camera
responses:
'200':
$ref: '#/components/responses/NetworkSettingsResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'400':
$ref: '#/components/responses/BadRequest'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/network/interfaces/':
get:
operationId: 'get-network-interfaces'
tags:
- network
summary: Listing network interfaces
security:
- 'HTTP Digest': []
responses:
'200':
$ref: '#/components/responses/NetworkInterfaceListResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
'/v1/network/interfaces/{interface_name}/':
get:
operationId: 'get-network-interface'
tags:
- network
summary: Getting network interface settings
security:
- 'HTTP Digest': []
parameters:
- name: interface_name
in: path
required: true
schema:
type: string
responses:
'200':
$ref: '#/components/responses/NetworkInterfaceSettingsResponse'
'303':
$ref: '#/components/responses/Uninitialized'
'401':
$ref: '#/components/responses/Unauthorized'
'404':
description: Not Found
put:
operationId: 'update-network-interface'
tags:
- network
summary: Changing network interface settings