Overview
The interface is split in to 4 sections.
- Top bar: access the main functions of the software
- Left column: manual entry of scale data
- Center column: table of tuning data
- Right column: options and configuration
The top bar provides many useful functions.
- New: generate a new scale or load one from a file
- Modify: apply some transformation to a scale that is currently loaded
- Export: save your work in one of many formats
- About: about Scale Workshop
Import/export tunings
Import
Scale Workshop supports import of Scala .scl files, AnaMark .tun files and Korg 'logue .mnlgtuns/.mnlgtuno'. Click 'New' on the top menu bar and then click 'Import .scl' or 'Import .tun'
Note: AnaMark .tun import is incomplete, but it should be able to import .tun V2.00 files exported by Scale Workshop and Scala.
Convert
Convert .scl or convert .tun tunings by importing them and then exporting.
Export
Many synthesizers support microtonal scales. Usually they will require some format of tuning file. Scale Workshop supports many of the popular formats.
To see a list of synths that support microtonal scales, see the List of Microtonal Software Plugins on the Xenharmonic Wiki.
AnaMark TUN (.tun)
If your synth supports .tun format, then please refer to its manual to find how to load the .tun file.
Scala scale (.scl)
If your synth supports .scl format, then please refer to its manual to find how to load the .scl file.
Scala keyboard mapping (.kbm)
Scale Workshop does not support arbitrary keyboard mappings, however it can output a .kbm file with linear mapping that has your chosen base MIDI note and base frequency.
Max/MSP coll (.txt)
When building synths in Max/MSP try using a coll object rather than an mtof object. Coll can load a specially-formatted text file containing a list of frequencies. Scale Workshop exports this kind of text file for you. Set up your coll object as below, and click the 'read' button to bring up a load file dialog.
Then when you input MIDI note numbers to the coll object, it will output the desired frequency.
PureData text (.txt)
When building synths in PureData try using a text object rather than an mtof object. The text object can load a specially-formatted text file containing a list of frequencies. Scale Workshop exports this kind of text file for you. Then when you input MIDI note numbers to the text object, it will output the desired frequency.
Kontakt script (.txt)
Kontakt's scripting environment allows you to retune each key to any pitch. Scale Workshop can export this script for you automatically. Once exported, copy and paste the contents of the script into the script editor of your Kontakt instrument.
Soniccouture tuning file (.nka)
Tuning format for Soniccouture's sampled instruments for Kontakt.
Harmor Pitch Map (.fnv)
Harmor allows retuning keys from C0 to C10 for up to 5 octaves up or down from 12 EDO. To do so, go to the "Pitch" tab, then "Keyboard mapping". Click the small arrow at the bottom left and select "Open State File...". From there, open the file that you exported from Scale Workshop. You will have to do this for every part that you use (A and/or B).
Sytrus Pitch Map (.fnv)
Sytrus allows retuning keys from C0 to C10 for up to 4 octaves up or down from 12 EDO. Warning: You won't be able to slide notes. If you do, the pitch will be incorrect. To do so, go to operator you want to retune, select the "Pitch" tab, then "Keyboard mapping". Click the small arrow at the bottom left and select "Open State File...". From there, open the file that you exported from Scale Workshop. Then, turn PE (Pitch Envelope) knob to the maximum value.
Korg Sound Librarian Scale/Octave (.mnlgtuns/.mnlgtuno)
These are for the Sound Librarian software associated with Korg's Monologue, Minilogue, and Prologue synths, and can be loaded with the "File > Load Single Scale" menu option. The "Scale" format follows the MIDI 1.0 "Bulk Tuning Dump" specification that allows for a 128-note table defined in semitones plus .0061 cents of precision with a supported frequency range of 8.1758 Hz to 12543.875 Hz. The "Octave" format follows the "Scale/Octave Tuning Dump" MIDI specification and only allows for 12 defined notes that will automatically repeat at the octave. Scales with more than 12 notes will be cut off, and pitches can only deviate from standard tuning by -64/+63 cents.
Deflemask 'fine tune' reference (.txt)
Exports a reference sheet to help you make microtonal music using the Deflemask tracker. Notes in Deflemask can have a 'fine tune' property. This reference sheet will show you the data you need to input.
Reaper Note Name Map (.txt)
Reaper allows all 128 rows in its piano roll MIDI editor to have a custom label. This export option gives each note a label based on its pitch, with some other properties depending on the selected options. "Scala Data" will preserve the notes' notation, keeping ratios when possible and allowing for mixed notations. For "Cents", "Frequencies", and "Decimals", each interval will be converted to the chosen format. "Degrees" will simply use "N\D" notation where N is the scale degree and D is the number of notes the scale has. Show Period Number will put the octave/period number of the interval after the pitch label. Calculate Period in Pitch will transpose each interval by the number of periods it is from the base note. It will try to preserve the notation of the interval, but will fallback to cents if it's not possible. Base Period Number will shift the base note from unison by this many periods. For example if you want your the base note & frequency to be note 48 at 256 Hz, but want unison to be an octave higher with note 60 at 512 Hz, you can set this to -1 period, meaning the base note & frequency is shifted one period below unison. Base Cents Value and Base Degree Number allow you to set a different value for the base note in cents or degrees respectively, similar to the "Base Period Number" option. In most cases this should be 0.
Reaper will look for these files by default in:
- Windows - C:\Users\[username]\AppData\Roaming\REAPER\MIDINoteNames
- macOS - /Users/[username]/Library/Application Support/REAPER/MIDINoteNames
Presets
A selection of preset scales are provided as examples.
Scale design
Scale Workshop allows you to create musical scales either by manual data input or by selecting menu options. We'll cover the menu options first.
Start by clicking the New option on the top menu bar. Select from equal temperament, rank-2 temperament, etc.
Equal temperaments
Equal temperaments are scales where every step is of equal size. The most well-known example perhaps is 12-tone equal temperament (12edo) which divides an octave into 12 equal parts and is the standard tuning in the West. Other well known equal tempered scales include 24edo (quartertones), 19edo and 31edo.
To create a new equal temperament scale click New > Equal temperament and then enter values to create the scale.
Number of divisions refers to the number of notes in your scale. Interval to divide will usually be 2/1 (octave) but could be a different value, for example to make Bohlen-Pierce you would have 13 divisions of 3/1.
Rank-2 temperaments
Create a rank-2 temperament using a generator and period.
Harmonic series segments
Generate a segment of the harmonic series by specifying the lowest and highest harmonics to be part of the scale. If the highest harmonic is double that of the lowest harmonic then the scale will repeat at the octave.
Subharmonic series segments
Generate a segment of the subharmonic series by specifying the lowest and highest subharmonics to be part of the scale. If the highest subharmonic is double that of the lowest subharmonic then the scale will repeat at the octave.
Enumerate chord
Create a scale from a list of harmonics separated by colons.
E.g. 4:5:6:7:8
Combination product set
Create a scale by multiplying harmonics in different combinations. Optionally, the resulting scale can be reduced by 2/1 and sorted in ascending order.
Combination product set (Xenharmonic Wiki)
Manual data entry
Scales can be written manually by typing them in to the Scale data text field. Enter one interval per line. Do not enter 1/1 on the first line as it is already assumed that the first note is 1/1.
Values with a . are cents values: e.g. 701.955
Values with slash (/) are ratios: e.g. 3/2
Values with a backslash (n\m) are n degrees of m-EDO: e.g. 7\12
Values with comma (,) are decimals: e.g. 1,5
The final value is your octave or pseudo-octave: e.g. 2/1
Just intonation examples
5-limit just major:
9/8 5/4 4/3 3/2 5/3 15/8 2/1
Harmonics 8-16:
9/8 10/8 11/8 12/8 13/8 14/8 15/8 16/8
Equal temperament examples
Blackwood[10] in 15edo:
2\15 3\15 5\15 6\15 8\15 9\15 11\15 12\15 14\15 15\15
8edo in cents:
150. 300. 450. 600. 750. 900. 1050. 1200.
Misc examples
You can combine any of the above styles in the same scale if needed:
1,2 3\9 700.1 2/1
Modify scales
There are menu options to help you modify your current scale. Note you must have some scale data loaded already in order to modify it. Click 'Modify' on the top menu bar to see the options.
Sort ascending
Sorts your scale ascendingly.
 Intervals in your scale which are larger than the modulus will wrap around, leaving only a remainder.
Rotate
Allows you to choose an interval of your scale to become 1/1.
Subset
Takes a subset of the current scale. Subsets are entered numerically.
Stretch/compress
Applies a linear stretch across the current scale. Enter a stretch factor, where 1 is no stretch at all.
Random variance
Applies a random detuning of each note in the scale. If the checkbox is ticked, this will also detune the octave. If unticked, the octave will remain unchanged.
Tempo-sync beating
This retunes each note of your scale to the nearest harmonic and then tunes the base frequency to match the BPM. This can result in LFO-like pulsations when playing chords.
The effect is most effective when using "rich" harmonic sounds (e.g. sawtooth waves) on a synth with excellent intonation accuracy (e.g. almost all digital synths).
Resolution allows you to control how much retuning is applied. Low values will result in a more drastic retuning of your original scale; in some cases this will result in notes converging on the same note, resulting in duplicates. For more obvious tempo-synced effects, choose a resolution that is a power of 2, e.g. 32, 64, or 128.
Approximate by ratios
This steps you through each interval of your scale, shows you a selection of ratios that are close to your interval, and allows you to choose the ratio for each.
Approximate by harmonics
This retunes each interval in your scale to the nearest harmonic. You select the denominator.
Approximate by subharmonics
This retunes each interval in your scale to the nearest subharmonic. You select the numerator.
Equalize
This retunes each interval in your scale to the nearest equal step. You select the number of steps to equally divide the interval of equivalence.
Synthesizer
Scale Workshop has a built-in synth so that you can play and hear your scales. This is useful for auditioning the scale you're working on, however it is very simple and isn't recommended for live performance.
Playing with a MIDI controller
Play notes on any connected MIDI device in order to hear your current scale. This requires you to use a web-MIDI capable browser. Must be enabled first by clicking the 'MIDI I/O' menu option then clicking the 'MIDI on' button while your controller is connected.

Note: QWERTY note input is disabled any time that a text or input field has focus. An indicator can be seen at the top-right of the screen to show you if you are able to play the QWERTY keyboard currently:
Not all international keyboard layouts are supported. Users who wish to see their keyboard layout supported are encouraged to contribute to the project by adding their own layout to keymap.js in the project source.
Playing with mouse / touch screen
On the top menu, click Virtual Kbd to display a grid overlay. Click / Touch the grid to hear your scale. The mapping on the grid is the same as the mapping on the QWERTY keys.
Isomorphic mapping
When using the QWERTY or the Virtual keyboard, by default each note along a horizontal axis is 1 scale degree apart and each note along vertical axis is 5 scale degrees apart. This can be changed by using the Isomorphic keyboard settings shown on the right column of the Scale Workshop interface.
Changing the sound of the synth
The synth has the following options:
- Main Volume
- Waveform: Semisine (default), Octaver, Triangle, Square, Sawtooth, Brightness, Harmonic Bell, Warm, Sine
- Amplitude envelope: Organ, Pad, Percussive (Short, Medium and Long)
- Delay effect: feedback delay echo
- Max polyphony: maximum number of voices that can be played at one time. Use a low value if you're on a low powered device. Many devices will be capable of 64 or more simultaneous voices. Must refresh the page for changes to take effect.
MIDI I/O
Scale Workshop can behave like a MIDI tuning box, allowing for MIDI input into the app and then outputting MIDI notes plus multichannel pitch bend messages, thereby allowing you to hear your scale on a supported MIDI synth.
Before getting started, make sure that your web browser is web-MIDI compatible. Not all browsers support MIDI I/O.
On your MIDI synth device, you should set pitch bend range to +/- 1 octave.
Connect your MIDI device(s) to your computer, then click the MIDI I/O option in the top menu. Then click the red 'MIDI on' button. If this was successful, the button will turn green and you will see a list of your MIDI devices below.
MIDI devices can be enabled or disabled by selecting the check boxes next to each device. Each individual channel can also be enabled or disabled by the check boxes.
Misc. tips
General settings can be found on the right side of the Scale Workshop interface.
If an exported tuning file doesn't seem to load into a softsynth properly, then try changing the value of Line endings format and re-saving the file. If you're using a Windows computer it's recommended to set this to Microsoft, otherwise set this to Unix.
Dark mode makes the Scale Workshop interface dark.
Undo/redo your tuning changes by using the back/forward browser navigation buttons.
If the synth gets too noisy, you can kill all sound by clicking the Quiet button.


Audience Thrash Tipsy Singer for Singing out of Tune during a Religious Event in India - Video
New Delhi (Sputnik): The audience at a religious turned violent after a singer appeared in intoxicated and started singing out of tune. The incident happened in Gujarat, one of five states in India where the manufacture, sale and consumption of alcohol is prohibited.
In the video clip, the singer can be heard singing out of tune and slurring his words.
Some audience members tried to stop the man from attacking the singer but chaos ensued when more members of the audience joined him in thrashing the singer.
The singer had to be whisked to safety by the organisers. The incident took place in Botad and the video clip was shared by a local journalist on twitter.


?01497640
?
??
6
7
8
9
10
ot.
«.t
v
The
New
York
copyright
reserved
botanical
Garden
First
Jamaican
record
(var.)
INSTITUTE
OF
JAMAICA
FLORA
OF
JAMAICA
\
Parish:
CLARENDON
xt____
Forestiera
rhamnifolia
Griseb.
V«.
rhamnlfnU.
Localityi
Glanuood
Springs
(
along
road
bstuesn
Balcarrss
&
Sunbury•
Altitude:
c.
31OO
ft*
Date:
September
27.
1974
Habitat«
Wooded
limestone
hilltop.
Notes:
Shrub
2
tn.
tall;
fla.
pala
yellow-green.
No.
34183
.
;
Collector:
Georg«
R«
Proctor
01497640
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


"DAVID", CITY OF (1.) David took from the Jebusites the fortress of Mount Zion. He “dwelt in the fort, and called it the city of David” (1 Chronicles 11:7). This was the name afterwards given to the castle and royal palace on Mount Zion, as distinguished from Jerusalem generally (1 Kings 3:1; 8:1), It was on the south-west side of Jerusalem, opposite the temple mount, with which it was connected by a bridge over the Tyropoeon valley. (2) Bethlehem is called the “city of David” (Luke 2:4, 11), because it was David’s birth-place and early home (1 Samuel 17:12).
"DAVID", CITY OF (1.) David took from the Jebusites the fortress of Mount Zion. He “dwelt in the fort, and called it the city of David” (1 Chronicles 11:7). This was the name afterwards given to the castle and royal palace on Mount Zion, as distinguished from Jerusalem generally (1 Kings 3:1; 8:1), It was on the south-west side of Jerusalem, opposite the temple mount, with which it was connected by a bridge over the Tyropoeon valley.
(2) Bethlehem is called the “city of David” (Luke 2:4, 11), because it was David’s birth-place and early home (1 Samuel 17:12).


Post-parsing
ArgParser.php
autoload.php
config.php
constants.php
database.php
doctypes.php
error_404.php
error_db.php
error_general.php
error_php.php
graphic_reports_model.php
graphic_report_tpl.php
hooks.php
main.php
main_tpl.php
mimes.php
pages.php
registration_model.php
registration_tpl.php
registrator.php
routes.php
smileys.php
Statistics.php
tester.php
user_agents.php
Post-parsing
Warnings:
Warning - Class Tester parent Controller not found
Warning - Class Registrator parent Controller not found
Warning - Class Pages parent Controller not found
Warning - Class Main parent Controller not found
Warning - Class Graphic_reports_model parent Model not found
Warning - Class Acc_model parent Model not found
Warning - Class Registration_model parent Model not found
acc_model.php
Warnings:
Warning on line 23 - no @package tag was used in a DocBlock for class Acc_model
ArgParser.php
Warnings:
Warning on line 10 - DocBlock would be page-level, but precedes class "ArgParser", use another DocBlock to document the file
autoload.php
Warnings:
Warning on line 115 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/autoload.php" has no page-level DocBlock, use @package in the first DocBlock to create one
config.php
Warnings:
Warning on line 328 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/config.php" has no page-level DocBlock, use @package in the first DocBlock to create one
constants.php
Warnings:
Warning on line 52 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/constants.php" has no page-level DocBlock, use @package in the first DocBlock to create one
database.php
Warnings:
Warning on line 16 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/database.php" has no page-level DocBlock, use @package in the first DocBlock to create one
doctypes.php
Warnings:
Warning on line 14 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/doctypes.php" has no page-level DocBlock, use @package in the first DocBlock to create one
error_404.php
Warnings:
Warning on line 33 - File "/Applications/MAMP/htdocs/cm-accounting/application/errors/error_404.php" has no page-level DocBlock, use @package in the first DocBlock to create one
error_db.php
Warnings:
Warning on line 33 - File "/Applications/MAMP/htdocs/cm-accounting/application/errors/error_db.php" has no page-level DocBlock, use @package in the first DocBlock to create one
error_general.php
Warnings:
Warning on line 33 - File "/Applications/MAMP/htdocs/cm-accounting/application/errors/error_general.php" has no page-level DocBlock, use @package in the first DocBlock to create one
error_php.php
Warnings:
Warning on line 9 - File "/Applications/MAMP/htdocs/cm-accounting/application/errors/error_php.php" has no page-level DocBlock, use @package in the first DocBlock to create one
graphic_reports_model.php
Warnings:
Warning on line 11 - no @package tag was used in a DocBlock for class Graphic_reports_model
graphic_report_tpl.php
Warnings:
Warning on line 198 - File "/Applications/MAMP/htdocs/cm-accounting/application/views/graphic_report_tpl.php" has no page-level DocBlock, use @package in the first DocBlock to create one
hooks.php
Warnings:
Warning on line 15 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/hooks.php" has no page-level DocBlock, use @package in the first DocBlock to create one
main.php
Warnings:
Warning on line 8 - DocBlock would be page-level, but precedes class "Main", use another DocBlock to document the file
main_tpl.php
Warnings:
Warning on line 265 - File "/Applications/MAMP/htdocs/cm-accounting/application/views/main_tpl.php" has no page-level DocBlock, use @package in the first DocBlock to create one
mimes.php
Warnings:
Warning on line 104 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/mimes.php" has no page-level DocBlock, use @package in the first DocBlock to create one
pages.php
Warnings:
Warning on line 8 - DocBlock would be page-level, but precedes class "Pages", use another DocBlock to document the file
registration_model.php
Warnings:
Warning on line 23 - no @package tag was used in a DocBlock for class Registration_model
registration_tpl.php
Warnings:
Warning on line 22 - File "/Applications/MAMP/htdocs/cm-accounting/application/views/registration_tpl.php" has no page-level DocBlock, use @package in the first DocBlock to create one
registrator.php
Warnings:
Warning on line 9 - DocBlock would be page-level, but precedes class "Registrator", use another DocBlock to document the file
routes.php
Warnings:
Warning on line 47 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/routes.php" has no page-level DocBlock, use @package in the first DocBlock to create one
smileys.php
Warnings:
Warning on line 65 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/smileys.php" has no page-level DocBlock, use @package in the first DocBlock to create one
Statistics.php
Warnings:
Warning on line 10 - DocBlock would be page-level, but precedes class "Statistics", use another DocBlock to document the file
tester.php
Warnings:
Warning on line 8 - DocBlock would be page-level, but precedes class "Tester", use another DocBlock to document the file
user_agents.php
Warnings:
Warning on line 174 - File "/Applications/MAMP/htdocs/cm-accounting/application/config/user_agents.php" has no page-level DocBlock, use @package in the first DocBlock to create one
Documentation generated on Fri, 07 Jan 2011 11:37:01 -0800 by phpDocumentor 1.4.3


Introduction
Welcome to the Signal Biometrics ox
API documentation. This should provide you with all the info you need to collect, store, retrieve and expose time series data
From a high-level perspective, the API allows you to apply CRUD operations to entities using the RESTful connector that you want. The entities you can interact with are:
- Beacon (an emitting device)
- Client (an API client)
- Event (a datapoint)
- Org (an organisation)
- Sensor (a sensing device)
Our production URL is
https://api.signal.bio/
Our staging URL is
https://api.stage.signal.bio/
You can report issues at
<EMAIL_ADDRESS>Requests
Almost all requests need to include a valid JWT token. See the authentication section for more details about this
Headers
This depends on the endpoint, but as a general rule if the request du not create or modify entities, you will not need to include a header (beside Authorization
). If you are passing along a JSON payload however, remember to set the Content-type
header as well
| Header | Content |
|---|---|
| Authorization | bearer {jwt} |
| Content-type | application/json |
Payload & params
As a general rule, endpoints that create a single entity will expect a JSON, while those creating many entities will expect an array of these objects
Endpoints that modify entities will either require an id
URL parameter and a payload (single), or a JSON consisting of the ids
to modify as properties and their changes as an object. Have a look at the updateManyBeacon for an example of this
Endpoints that do not require a payload (read & delete operations) will only require parameters passed in the URL, with multiple values separated by commas
Responses
Our API responses are JSON objects with the results (or error) assigned to the data
property. Our structure liberally adds a few extra properties to the JSend "specs":
Response JSON
{
"program": "ox",
"version": "0.0.1",
"datetime": "2017-10-11T13:10:11.669Z",
"timestamp":<PHONE_NUMBER>669,
"code":200,
"status": "success",
"message": "Call successful",
"data": {
"status": "success",
"message": "OK",
"code": 200
}
}
| Property | Usage |
|---|---|
program |
The name of the API |
version |
The version of the API |
datetime |
When the response was sent (i.e. _new Date ) |
timestamp |
When the response was sent (i.e. Date.now() ) |
code |
HTTP status of the response |
status |
success or failure or error |
message |
Additional API message |
data |
The error or result payload |
Success
If the request succeed with a 200
, the response data
property will be populated according to the HTTP operation requested by the client and the number of entities
| Verb | Scope | Type | Content |
|---|---|---|---|
| POST | Single | Object | {id, info} |
| POST | Collection | Array | [{id, info}] |
| GET | Single | Object | {entity} |
| GET | Collection | Array | [{entity}] |
| PATCH | Single | Object | {id, info} |
| PATCH | Collection | Array | [{id, info}] |
| DELETE | Single | Object | {id, info} |
| DELETE | Collection | Array | [{id, info}] |
Failure
If the request fails witha 4xx
or 5xx
, the response data
property will be be the same regardless of the HTTP operation but will change depending on the number of entities
| Verb | Scope | Type | Content |
|---|---|---|---|
| * | Single | Object | {id, info} |
| * | Collection | Array | [{id, info}] |
Authentication
Header example
Authorization: bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
For all API request, ox
expects a JSON Web Token to be included in a header that looks like the one on the right
The org
entity is are the root of our authentication scheme. At this time, only Signal can create new org
. Beside this, entities have the right to create, modify or delete entities with a higher tier then themselves. The hiearchy looks like this:
| Entity | Owner | Tier |
|---|---|---|
| Org | Signal Biometrics | Tier 0 |
| Client | Org | Tier 1 |
| Beacon | Org | Tier 1 |
| Sensor | Client | Tier 2 |
| Event | Client | Tier 2 |
Code samples
# 1. create a client
curl -X POST -H "Content-Type: application/json" -d '{client_entity_payload}' -H "{headers}" https://api.signal.bio/client
# returns response.body.data.client_api_key
# 2. retrieve a token
curl https://api.signal.bio/client/token/{parent_org_id}/{client_id}/{client_api_key}
# returns response.body.data.token
# 3. authorize a request with a header
curl -H "Authorization: bearer {jwt}" https://api.signal.bio/{endpoint}
Since the API is meant to be accessed programatically, we are not relying on a user/password scheme to grant access to our ressources. Rather, the authentication of a client happens in three steps:
- An
org
create a client and get an API key - The client uses this API key to retrieve a token
- The client uses this token to authenticate its requests
The token expires, but the client do not. Typically, clients will be devices, user accounts interfaces or applications and will be given the cleartext client_api_key
as en environement variable or as part of a configuration object
/
GET /
Providing that the request is authorized and that the API is reachable, the root path will respond to a GET
request with a 200 — OK
. You can use it to confirm that your token is valid and that the host is reachable
/beacon
/beacon
Beacons collect the readings of sensors, called events. Beacons are typically bluetooth-enabled devices that are connected to the internet and relay back events to our realtime database
When a beacon is added, it is also added to our realtime database and watch both by a server service and our app instances. When the beacon_last_event
field is updated, this change is broadcasted to all connected & authenticated devices
Create One
Code samples
curl -X POST https://api.signal.bio/beacon -H "{headers}" -d "{payload}"
POST https://api.signal.io/beacon HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /beacon
Add a new beacon
Body parameter
{
"parent_org":<PHONE_NUMBER>341234,
"beacon_id": "014DB0FE-06D4-4FE3-A81F-14037E8701AA",
"beacon_env": "iOS 9.0",
"beacon_type": "iphone",
"beacon_version": "1.1.1/34",
"beacon_last_event": {
"event_sensor":<PHONE_NUMBER>452345,
"event_reading": 105,
"event_type": "heart_rate",
"event_timestamp":<PHONE_NUMBER>219
}
}
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:28:34.716Z",
"timestamp":<PHONE_NUMBER>716,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5681589568667648"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Beacon | Beacon object that needs to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Beacon |
| 401 | Unauthorized | Invalid token | None |
Create Many
Code samples
curl -X POST https://api.signal.bio/beacon -H "{headers}" -d "{payload}"
POST https://api.signal.io/beacon HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /beacon
Add many beacons
Body parameter
[{
"parent_org":<PHONE_NUMBER>341234,
"beacon_id": "014DB0FE-06D4-4FE3-A81F-14037E8701AA",
"beacon_env": "iOS 9.0",
"beacon_type": "iphone",
"beacon_version": "1.1.1/34",
"beacon_last_event": {
"event_sensor":<PHONE_NUMBER>452345,
"event_reading": 105,
"event_type": "heart_rate",
"event_timestamp":<PHONE_NUMBER>219
}
},
{
"parent_org":<PHONE_NUMBER>214321,
"beacon_id": "06D44FE3-014D-B0FE-A81F-14037E8701AA",
"beacon_env": "iOS 8.0",
"beacon_type": "iphone",
"beacon_version": "2.1.1",
"beacon_last_event": {}
}]
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:30:38.308Z",
"timestamp":<PHONE_NUMBER>308,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Beacons | Array of beacon objects that need to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Beacon |
| 401 | Unauthorized | Invalid token | None |
Retrieve One by Id
Code samples
curl https://api.signal.bio/beacon/{id} -H "{headers}"
GET https://api.signal.io/beacon/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /beacon/{id}
Retrieve a beacon by id
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:49:38.744Z",
"timestamp":<PHONE_NUMBER>744,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"beacon_version": "123",
"beacon_env": "baz",
"beacon_type": "roz",
"beacon_last_event": {
"baa": "zzz"
},
"created_at": "2018-01-16T23:25:25.685Z",
"parent_org": {
"name": "1234123412340000",
"kind": "Org",
"path": [
"Org",
"1234123412340000"
]
},
"modified_at": "2018-01-16T23:25:25.685Z",
"beacon_id": "bar"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Beacon entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Retrieve Many by Id
Code samples
curl https://api.signal.bio/beacon/{id},{id},{id} -H "{headers}"
GET https://api.signal.io/beacon/{id},{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /beacon/{id},{id},{id}
Retrieve many beacons by id
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:52:55.965Z",
"timestamp":<PHONE_NUMBER>965,
"code": 200,
"status": "success",
"message": "Call successful",
"data": [
{
"beacon_env": "iOS 9.0",
"beacon_type": "iphone",
"beacon_last_event": {
"event_type": "heart_rate",
"event_sensor":<PHONE_NUMBER>452345,
"event_timestamp":<PHONE_NUMBER>219,
"event_reading": 105
},
"created_at": "2018-01-30T15:30:38.181Z",
"parent_org": {
"id": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
"modified_at": "2018-01-30T15:30:38.181Z",
"beacon_id": "014DB0FE-06D4-4FE3-A81F-14037E8701AA",
"beacon_version": "1.1.1/34"
},
{
"beacon_version": "1.1.1/34",
"beacon_env": "iOS 9.0",
"beacon_type": "iphone",
"beacon_last_event": {
"event_type": "heart_rate",
"event_sensor":<PHONE_NUMBER>452345,
"event_timestamp":<PHONE_NUMBER>219,
"event_reading": 105
},
"created_at": "2018-01-30T15:30:38.181Z",
"parent_org": {
"id": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
"modified_at": "2018-01-30T15:30:38.182Z",
"beacon_id": "014DB0FE-06D4-4FE3-A81F-14037E8701AA"
}
]
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Beacon entity ids separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete One by Id
Code samples
curl -X DELETE https://api.signal.bio/beacon/{id} -H "{headers}"
DELETE https://api.signal.io/beacon/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /beacon/{id}
Delete a beacon by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:55:13.871Z",
"timestamp":<PHONE_NUMBER>871,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Beacon entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete Many by Id
Code samples
curl -X DELETE https://api.signal.bio/beacon/{id},{id},{id} -H "{headers}"
DELETE https://api.signal.io/beacon/{id},{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /beacon/{id},{id},{id}
Delete many beacons by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:57:57.367Z",
"timestamp":<PHONE_NUMBER>367,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Beacon entity id separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Update One by Id
Code samples
curl -X PUT https://api.signal.bio/beacon -H "{headers}" -d "{payload}"
PUT https://api.signal.io/beacon HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /beacon
Update an existing beacon
Body parameter
{
"5655778694266880": {
"beacon_env": "iOS 10.0",
"beacon_type": "iphone",
"beacon_version": "2.2.0/5"
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Beacon |
| 401 | Unauthorized | Invalid token | None |
Update Many by Id
Code samples
curl -X PUT https://api.signal.bio/beacon -H "{headers}" -d "{payload}"
PUT https://api.signal.io/beacon HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /beacon
Update many existing beacons
Body parameter
{
"5655778694266880": {
"beacon_env": "iOS 10.0",
"beacon_type": "iphone",
"beacon_version": "2.2.0/5"
},
"5092828740845568": {
"beacon_env": "iOS 11.0",
"beacon_type": "ipad",
"beacon_version": "1.2.0"
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880",
"5092828740845568"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Beacon |
| 401 | Unauthorized | Invalid token | None |
/client
/client
Clients are service accounts with access to the API. These accounts can be used on devices or as components for any authflow that involve access to the API. More precisely, the clients are used to issue and validate API keys, which in turn are used to sign and generate access tokens. They are also used to establish permission on our different ressources
Create One
Code samples
curl -X POST https://api.signal.bio/client -H "{headers}" -d "{payload}"
POST https://api.signal.io/client HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /client
Add a new client
Body parameter
{
"parent_org":<PHONE_NUMBER>341234,
"parent_user":<PHONE_NUMBER>214321,
"client_name": "My first client",
"client_id": "ipad/123",
}
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:28:34.716Z",
"timestamp":<PHONE_NUMBER>716,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5681589568667648"
],
"info": "done",
"client_api_key": "0dbe990f688799287c3673382a9d4460cd343f2511a0cff8a26bf088a726c805"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Client | Client object that needs to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Client |
| 401 | Unauthorized | Invalid token | None |
Create Many
Code samples
curl -X POST https://api.signal.bio/client -H "{headers}" -d "{payload}"
POST https://api.signal.io/client HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /client
Add many clients
Body parameter
[{
"parent_org":<PHONE_NUMBER>341234,
"parent_user":<PHONE_NUMBER>214321,
"client_name": "My first client",
"client_id": "ipad/123",
},{
"parent_org":<PHONE_NUMBER>341234,
"parent_user":<PHONE_NUMBER>214321,
"client_name": "My second client",
"client_id": "ipod/777",
}
]
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:30:38.308Z",
"timestamp":<PHONE_NUMBER>308,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Clients | Array of client objects that need to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Client |
| 401 | Unauthorized | Invalid token | None |
Issue Token
Code samples
curl https://api.signal.bio/client/token/{parent_org}/{client_id}/{client_api_key} -H "{headers}"
GET https://api.signal.io/client/token/{parent_org}/{client_id}/{client_api_key} HTTPS/1.1
Host: api.signal.bio
GET /client/tokent/{parent_org}/{client_id}/{client_api_key}
Retrieve a JSON Web Token signed with an API key
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:49:38.744Z",
"timestamp":<PHONE_NUMBER>744,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"parent_user": {
"id": "4321432143214321",
"kind": "User",
"path": [
"User",
"4321432143214321"
]
},
"client_secret": "$2a$10$L/GOsc5v4lw/iUzuYDOUH.zBEMb1fbYrFlJJXtLTYC78lG.1nl.Fa",
"client_id": "baz",
"created_at": "2018-02-01T12:58:37.574Z",
"parent_org": {
"id": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
"modified_at": "2018-02-01T12:58:37.579Z",
"client_name": "booboo",
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXJlbnRfb3JnIjp7ImlkIjoiMTIzNDEyMzQxMjM0MTIzNCIsImtpbmQiOiJPcmciLCJwYXRoIjpbIk9yZyIsIjEyMzQxMjM0MTIzNDEyMzQiXX0sInBhcmVudF91c2VyIjp7ImlkIjoiNDMyMTQzMjE0MzIxNDMyMSIsImtpbmQiOiJVc2VyIiwicGF0aCI6WyJVc2VyIiwiNDMyMTQzMjE0MzIxNDMyMSJdfSwiY2xpZW50X2lkIjoiYmF6IiwiY2xpZW50X25hbWUiOiJib29ib28iLCJpYXQiOjE1MTc1MDgxMDMsImV4cCI6MTUxNzc2NzMwM30.iizTopa0Zr0ddcmi8Htu4dcN_lpFrTdzoblDyt33bls"
},
"created_at": "2018-01-16T23:25:25.685Z",
"modified_at": "2018-05-17T11:36:55.907Z",
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Client entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 403 | Forbidden | The API key does not match the one stored | None |
| 404 | Not Found | The client was not found | None |
Retrieve One by Id
Code samples
curl https://api.signal.bio/client/{id} -H "{headers}"
GET https://api.signal.io/client/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /client/{id}
Retrieve a client by id
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:49:38.744Z",
"timestamp":<PHONE_NUMBER>744,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"client_id": "ipad/123",
"client_name": "My first client",
"parent_org": {
"name": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
"parent_user": {
"name": "4321432143214321",
"kind": "Org",
"path": [
"Org",
"4321432143214321"
]
},
},
"created_at": "2018-01-16T23:25:25.685Z",
"modified_at": "2018-05-17T11:36:55.907Z",
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Client entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Retrieve Many by Id
Code samples
curl https://api.signal.bio/client/{id},{id},{id} -H "{headers}"
GET https://api.signal.io/client/{id},{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /client/{id},{id},{id}
Retrieve many clients by id
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:52:55.965Z",
"timestamp":<PHONE_NUMBER>965,
"code": 200,
"status": "success",
"message": "Call successful",
"data": [{
"client_id": "ipad/123",
"client_name": "My first client",
"parent_org": {
"name": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
},
{
"client_id": "iphone/777",
"client_name": "My second client",
"parent_org": {
"name": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
}
}]
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Client entity ids separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete One by Id
Code samples
curl -X DELETE https://api.signal.bio/client/{id} -H "{headers}"
DELETE https://api.signal.io/client/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /client/{id}
Delete a client by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:55:13.871Z",
"timestamp":<PHONE_NUMBER>871,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Client entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete Many by Id
Code samples
curl -X DELETE https://api.signal.bio/client/{id},{id},{id} -H "{headers}"
DELETE https://api.signal.io/client/{id},{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /client/{id},{id},{id}
Delete many clients by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:57:57.367Z",
"timestamp":<PHONE_NUMBER>367,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Client entity id separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Update One by Id
Code samples
curl -X PUT https://api.signal.bio/client -H "{headers}" -d "{payload}"
PUT https://api.signal.io/client HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /client
Update an existing client
Body parameter
{
"5655778694266880": {
"client_name": "new device name",
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Client |
| 401 | Unauthorized | Invalid token | None |
Update Many by Id
Code samples
curl -X PUT https://api.signal.bio/client -H "{headers}" -d "{payload}"
PUT https://api.signal.io/client HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /client
Update many existing clients
Body parameter
{
"5655778694266880": {
"client_type": "very new device name",
},
"5092828740845568": {
"client_type": "very very new device name",
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880",
"5092828740845568"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Client |
| 401 | Unauthorized | Invalid token | None |
/event
/event
Events are the fragment of information that we store on the backend. It consist of a sensor value of a biometric measurement, along with a timestamp and information about the entities owning this event (sensor, beacon, beacon)
These events are aggregated and can be queried, however they are hardly ever created through the API: they are generally created when a sensor entity's last_event
property is updated in our realtime database
Create One
Code samples
curl -X POST https://api.signal.bio/event -H "{headers}" -d "{payload}"
POST https://api.signal.io/event HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /event
Add a new event
Body parameter
{
"parent_org":<PHONE_NUMBER>341234,
"event_beacon":<PHONE_NUMBER>325432,
"event_sensor":<PHONE_NUMBER>89,
"event_reading": 123,
"event_type": "heart_rate",
"event_timestamp":<PHONE_NUMBER>,
}
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:28:34.716Z",
"timestamp":<PHONE_NUMBER>716,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"4873960965537792"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Event | Event object that needs to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Event |
| 401 | Unauthorized | Invalid token | None |
Create Many
Code samples
curl -X POST https://api.signal.bio/event -H "{headers}" -d "{payload}"
POST https://api.signal.io/event HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /event
Add many events
Body parameter
[{
"parent_org":<PHONE_NUMBER>341234,
"event_beacon":<PHONE_NUMBER>325432,
"event_sensor":<PHONE_NUMBER>89,
"event_reading": 123,
"event_type": "heart_rate",
"event_timestamp":<PHONE_NUMBER>,
},{
"parent_org":<PHONE_NUMBER>341234,
"event_beacon":<PHONE_NUMBER>325432,
"event_sensor":<PHONE_NUMBER>89,
"event_reading": 123,
"event_type": "heart_rate",
"event_timestamp":<PHONE_NUMBER>,
}]
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:30:38.308Z",
"timestamp":<PHONE_NUMBER>308,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Events | Array of event objects that need to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Event |
| 401 | Unauthorized | Invalid token | None |
Retrieve One by Id
Code samples
curl https://api.signal.bio/event/{id} -H "{headers}"
GET https://api.signal.io/event/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /event/{id}
Retrieve a event by id
Success response
{
"created_at": "2018-02-05T20:18:25.706Z",
"parent_org": {
"id": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
"event_beacon": {
"id": "5432543254325432",
"kind": "Beacon",
"path": [
"Beacon",
"5432543254325432"
]
},
"event_sensor": {
"id": "678967896789",
"kind": "Sensor",
"path": [
"Sensor",
"678967896789"
]
},
"event_timestamp":<PHONE_NUMBER>,
"event_reading": 123,
"event_type": "heart_rate"
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Event entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Retrieve Many by Id
Code samples
curl https://api.signal.bio/event/{id},{id},{id} -H "{headers}"
GET https://api.signal.io/event/{id},{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /event/{id},{id},{id}
Retrieve many events by id
Success response
[{
"created_at": "2018-02-05T20:18:25.706Z",
"parent_org": {
"id": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
"event_beacon": {
"id": "5432543254325432",
"kind": "Beacon",
"path": [
"Beacon",
"5432543254325432"
]
},
"event_sensor": {
"id": "678967896789",
"kind": "Sensor",
"path": [
"Sensor",
"678967896789"
]
},
"event_timestamp":<PHONE_NUMBER>,
"event_reading": 123,
"event_type": "heart_rate"
},
{event},
{event}]
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Event entity ids separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete One by Id
Code samples
curl -X DELETE https://api.signal.bio/event/{id} -H "{headers}"
DELETE https://api.signal.io/event/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /event/{id}
Delete a event by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:55:13.871Z",
"timestamp":<PHONE_NUMBER>871,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Event entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete Many by Id
Code samples
curl -X DELETE https://api.signal.bio/event/{id},{id},{id} -H "{headers}"
DELETE https://api.signal.io/event/{id},{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /event/{id},{id},{id}
Delete many events by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:57:57.367Z",
"timestamp":<PHONE_NUMBER>367,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Event entity id separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Update One by Id
Code samples
curl -X PUT https://api.signal.bio/event -H "{headers}" -d "{payload}"
PUT https://api.signal.io/event HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /event
Update an existing event
Body parameter
{
"5655778694266880": {
"parent_org":<PHONE_NUMBER>870987,
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Event |
| 401 | Unauthorized | Invalid token | None |
Update Many by Id
Code samples
curl -X PUT https://api.signal.bio/event -H "{headers}" -d "{payload}"
PUT https://api.signal.io/event HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /event
Update many existing events
Body parameter
{
"5655778694266880": {
"parent_org":<PHONE_NUMBER>658765
},
"5092828740845568": {
"parent_org":<PHONE_NUMBER>563456
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880",
"5092828740845568"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Event |
| 401 | Unauthorized | Invalid token | None |
/org
/org
Org are the top entities of our datastructure, and superseed or hold permission over all others. An organisation contains child beacons, users, clients, and sensors and it is itself owned by a user (or another org)
Every child element can be enabled or disabled at the organisation level (see the IdMap schema)
Create One
Code samples
curl -X POST https://api.signal.bio/org -H "{headers}" -d "{payload}"
POST https://api.signal.io/org HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /org
Add a new org
Body parameter
{
"org_owner":<PHONE_NUMBER>325432,
"org_active": true,
"org_sensors": {
"1234567890981111":<PHONE_NUMBER>000
},
"org_beacons": {
"1234567890987654":<PHONE_NUMBER>829
},
"org_users": {
"1234567890988888":<PHONE_NUMBER>829
},
"org_alias": "FastCars Co.",
"org_clients": {
"1234567890987777":<PHONE_NUMBER>000
}
}
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-02-14T12:50:10.658Z",
"timestamp":<PHONE_NUMBER>658,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5713106038685696"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Org | Org object that needs to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Org |
| 401 | Unauthorized | Invalid token | None |
Create Many
Code samples
curl -X POST https://api.signal.bio/org -H "{headers}" -d "{payload}"
POST https://api.signal.io/org HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /org
Add many orgs
Body parameter
[{
"org_owner":<PHONE_NUMBER>325432,
"org_active": true,
"org_sensors": {
"1234567890981111":<PHONE_NUMBER>000
},
"org_beacons": {
"1234567890987654":<PHONE_NUMBER>829
},
"org_users": {
"1234567890988888":<PHONE_NUMBER>829
},
"org_alias": "FastCars Co.",
"org_clients": {
"1234567890987777":<PHONE_NUMBER>000
}
},{
"org_owner":<PHONE_NUMBER>325643,
"org_active": true,
"org_sensors": {
"1234567890983331":<PHONE_NUMBER>333
},
"org_beacons": {
"1234567890983211":<PHONE_NUMBER>444
},
"org_users": {
"1234567890983543":<PHONE_NUMBER>666
},
"org_alias": "FastCars Co.",
"org_clients": {
"1234567890981234":<PHONE_NUMBER>777
}
}]
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:30:38.308Z",
"timestamp":<PHONE_NUMBER>308,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Orgs | Array of org objects that need to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Org |
| 401 | Unauthorized | Invalid token | None |
Retrieve One by Id
Code samples
curl https://api.signal.bio/org/{id} -H "{headers}"
GET https://api.signal.io/org/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /org/{id}
Retrieve a org by id
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-02-14T17:06:43.393Z",
"timestamp":<PHONE_NUMBER>393,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"created_at": "2018-02-05T20:18:25.706Z",
"parent_org": {
"id": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
"event_beacon": {
"id": "5432543254325432",
"kind": "Beacon",
"path": [
"Beacon",
"5432543254325432"
]
},
"event_sensor": {
"id": "678967896789",
"kind": "Sensor",
"path": [
"Sensor",
]
"678967896789"
},
"event_timestamp":<PHONE_NUMBER>,
"event_reading": 123,
"event_type": "heart_rate"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Org entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Retrieve Many by Id
Code samples
curl https://api.signal.bio/org/{id},{id} -H "{headers}"
GET https://api.signal.io/org/{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /org/{id},{id}
Retrieve many orgs by id
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-02-14T17:09:04.125Z",
"timestamp":<PHONE_NUMBER>125,
"code": 200,
"status": "success",
"message": "Call successful",
"data": [
{
"modified_at": "2018-01-09T16:11:43.148Z",
"org_owner": {
"id": "1234432112344321",
"kind": "User",
"path": [
"User",
"1234432112344321"
]
},
"org_active": true,
"org_sensors": {
"1234567890981111":<PHONE_NUMBER>000,
"1234567890987654":<PHONE_NUMBER>829
},
"org_beacons": {
"1234567890987654":<PHONE_NUMBER>829,
"1234567890981111":<PHONE_NUMBER>000
},
"org_alias": "goo",
"org_users": {
"1234567890987654":<PHONE_NUMBER>829,
"1234567890981111":<PHONE_NUMBER>000
},
"org_clients": {
"1234567890981111":<PHONE_NUMBER>000,
"1234567890987654":<PHONE_NUMBER>829
},
"created_at": "2018-01-09T16:11:43.148Z"
},
{
"org_clients": {
"1234567890987654":<PHONE_NUMBER>829,
"1234567890981111":<PHONE_NUMBER>000
},
"created_at": "2018-01-09T16:07:31.373Z",
"modified_at": "2018-01-09T16:07:31.374Z",
"org_owner": {
"id": "1234432112344321",
"kind": "User",
"path": [
"User",
"1234432112344321"
]
},
"org_active": true,
"org_sensors": {
"1234567890987654":<PHONE_NUMBER>829,
"1234567890981111":<PHONE_NUMBER>000
},
"org_beacons": {
"1234567890987654":<PHONE_NUMBER>829,
"1234567890981111":<PHONE_NUMBER>000
},
"org_users": {
"1234567890987654":<PHONE_NUMBER>829,
"1234567890981111":<PHONE_NUMBER>000
},
"org_alias": "goo"
}
]
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Org entity ids separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete One by Id
Code samples
curl -X DELETE https://api.signal.bio/org/{id} -H "{headers}"
DELETE https://api.signal.io/org/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /org/{id}
Delete a org by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:55:13.871Z",
"timestamp":<PHONE_NUMBER>871,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Org entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete Many by Id
Code samples
curl -X DELETE https://api.signal.bio/org/{id},{id},{id} -H "{headers}"
DELETE https://api.signal.io/org/{id},{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /org/{id},{id},{id}
Delete many orgs by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:57:57.367Z",
"timestamp":<PHONE_NUMBER>367,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Org entity id separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Update One by Id
Code samples
curl -X PUT https://api.signal.bio/org -H "{headers}" -d "{payload}"
PUT https://api.signal.io/org HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /org
Update an existing org
Body parameter
{
"5655778694266880": {
"org_active": false
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Org |
| 401 | Unauthorized | Invalid token | None |
Update Many by Id
Code samples
curl -X PUT https://api.signal.bio/org -H "{headers}" -d "{payload}"
PUT https://api.signal.io/org HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /org
Update many existing orgs
Body parameter
{
"5655778694266880": {
"org_active": false
},
"5092828740845568": {
"org_alias": "New Company Name Inc."
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880",
"5092828740845568"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Org |
| 401 | Unauthorized | Invalid token | None |
/sensor
/sensor
Sensors are devices that pick up the events and broadcast them to beacons. A sensor could be an assembly doing both the acquisition (i.e. sensing device) and the broadcasting (i.e. the enclosure)
Sensors can be provisioned (and re-reprovisioned) for different organisations, and we keep track of them as part of our event flow to add one more layer of data accountabilty/ownership
Create One
Code samples
curl -X POST https://api.signal.bio/sensor -H "{headers}" -d "{payload}"
POST https://api.signal.io/sensor HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /sensor
Add a new sensor
Body parameter
{
"parent_org":<PHONE_NUMBER>785678,
"sensor_version": "7",
"sensor_type": "glove/palm",
"sensor_id": "12345"
}
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-02-15T12:56:48.446Z",
"timestamp":<PHONE_NUMBER>446,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5759902660165632"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Sensor | Sensor object that needs to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Sensor |
| 401 | Unauthorized | Invalid token | None |
Create Many
Code samples
curl -X POST https://api.signal.bio/sensor -H "{headers}" -d "{payload}"
POST https://api.signal.io/sensor HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
POST /sensor
Add many sensors
Body parameter
[{
"parent_org":<PHONE_NUMBER>785678,
"sensor_version": "7",
"sensor_type": "glove/palm",
"sensor_id": "12345"
},{
"parent_org":<PHONE_NUMBER>785678,
"sensor_version": "2",
"sensor_type": "chest/mid",
"sensor_id": "432"
}]
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:30:38.308Z",
"timestamp":<PHONE_NUMBER>308,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Sensor | Array of sensor objects that need to be added |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Sensor |
| 401 | Unauthorized | Invalid token | None |
Retrieve One by Id
Code samples
curl https://api.signal.bio/sensor/{id} -H "{headers}"
GET https://api.signal.io/sensor/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /sensor/{id}
Retrieve a sensor by id
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-02-15T13:01:55.847Z",
"timestamp":<PHONE_NUMBER>847,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"sensor_version": "7",
"created_at": "2018-02-15T12:56:48.338Z",
"parent_org": {
"id": "5678567856785678",
"kind": "Org",
"path": [
"Org",
"5678567856785678"
]
},
"sensor_type": "glove/palm",
"modified_at": "2018-02-15T12:56:48.339Z",
"sensor_id": "12345"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Sensor entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Retrieve Many by Id
Code samples
curl https://api.signal.bio/sensor/{id},{id} -H "{headers}"
GET https://api.signal.io/sensor/{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
GET /sensor/{id},{id}
Retrieve many sensors by id
Success response
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-02-15T13:08:14.228Z",
"timestamp":<PHONE_NUMBER>228,
"code": 200,
"status": "success",
"message": "Call successful",
"data": [
{
"sensor_version": "7",
"created_at": "2018-02-15T13:06:03.016Z",
"parent_org": {
"id": "5678567856785678",
"kind": "Org",
"path": [
"Org",
"5678567856785678"
]
},
"sensor_type": "glove/palm",
"modified_at": "2018-02-15T13:06:03.017Z",
"sensor_id": "12345"
},
{
"created_at": "2018-02-15T13:06:03.016Z",
"parent_org": {
"id": "5678567856785678",
"kind": "Org",
"path": [
"Org",
"5678567856785678"
]
},
"sensor_type": "glove/palm",
"modified_at": "2018-02-15T13:06:03.016Z",
"sensor_id": "12345",
"sensor_version": "7"
}
]
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Sensor entity ids separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete One by Id
Code samples
curl -X DELETE https://api.signal.bio/sensor/{id} -H "{headers}"
DELETE https://api.signal.io/sensor/{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /sensor/{id}
Delete a sensor by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:55:13.871Z",
"timestamp":<PHONE_NUMBER>871,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| id | url | Integer | Sensor entity id |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Delete Many by Id
Code samples
curl -X DELETE https://api.signal.bio/sensor/{id},{id},{id} -H "{headers}"
DELETE https://api.signal.io/sensor/{id},{id},{id} HTTPS/1.1
Host: api.signal.bio
Authorization: bearer {jwt}
DELETE /sensor/{id},{id},{id}
Delete many sensors by id
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T15:57:57.367Z",
"timestamp":<PHONE_NUMBER>367,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"6487942298075136",
"4658354949455872"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| ids | url | Integer | Sensor entity id separated by commas |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 401 | Unauthorized | Invalid token | None |
Update One by Id
Code samples
curl -X PUT https://api.signal.bio/sensor -H "{headers}" -d "{payload}"
PUT https://api.signal.io/sensor HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /sensor
Update an existing sensor
Body parameter
{
"5655778694266880": {
"parent_org":<PHONE_NUMBER>334444
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Sensor |
| 401 | Unauthorized | Invalid token | None |
Update Many by Id
Code samples
curl -X PUT https://api.signal.bio/sensor -H "{headers}" -d "{payload}"
PUT https://api.signal.io/sensor HTTPS/1.1
Host: api.signal.bio
Content-Type: application/json
Authorization: bearer {jwt}
PUT /sensor
Update many existing sensors
Body parameter
{
"5655778694266880": {
"parent_org": false
},
"5092828740845568": {
"sensor_id": "yul-773"
}
}
Success payload
{
"program": "ox",
"version": "0.0.5",
"datetime": "2018-01-30T16:13:33.062Z",
"timestamp":<PHONE_NUMBER>062,
"code": 200,
"status": "success",
"message": "Call successful",
"data": {
"ids": [
"5655778694266880",
"5092828740845568"
],
"info": "done"
}
}
Parameters
| Parameter | In | Type | Description |
|---|---|---|---|
| body | body | Object | Key/value pairs of entities and updates |
Responses
| Status | Meaning | Description | Schema |
|---|---|---|---|
| 200 | OK | Request was successful | None |
| 400 | Bad Request | Invalid payload | Sensor |
| 401 | Unauthorized | Invalid token | None |
Schemas
Schemas might not be identical our internal representation (i.e. models) of the entities or even how entities are returned when queried. To illustrate this, we are including examples payload that should be passed with POST requests (Request Payload), and what is the expected results from GET requests (Response Payload)
There is also table with Appended Values and Modified Values. Appended Values are added during the creation or modification of entities, while Modified Values are changed on the fly, for instance when casting a type into another
Beacon
Request Payload
{
"beacon_id": "014DB0FE-06D4-4FE3-A81F-14037E8701AA",
"beacon_env": "iOS 9.0",
"beacon_type": "iphone",
"beacon_version": "1.1.1/34",
"beacon_last_event": {
"foo": "bar"
},
"parent_org":<PHONE_NUMBER>341234,
}
Return Payload
{
"beacon_id": "014DB0FE-06D4-4FE3-A81F-14037E8701AA",
"beacon_env": "iOS 9.0",
"beacon_type": "iphone",
"beacon_version": "1.1.1/34",
"beacon_last_event": {
"foo": "bar"
},
"parent_org": {
"name": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
"created_at": "2018-01-16T23:25:25.685Z",
"modified_at": "2018-05-17T11:36:55.907Z",
}
Properties
| Name | Type | Required | Description |
|---|---|---|---|
| parent_org | Integer | true | The id of this beacon's parent org |
| beacon_id | String | true | Custom local id of this device |
| beacon_env | String | true | Device OS or model (including version) |
| beacon_type | String | true | Device type |
| beacon_version | String | true | Version number of the Signal app |
| beacon_last_event | Object(Event) | false | The last event captured by this beacon |
Appended Values
| Property | Description |
|---|---|
| created_at | When the entity was created |
| modified_at | When the entity was last modified |
Modified Values
| Property | From | To |
|---|---|---|
| parent_org | Integer | Object(Key) |
Client
Request Payload
{
"client_id": "ipad/123",
"client_name": "My first client",
"parent_org":<PHONE_NUMBER>341234,
"parent_user":<PHONE_NUMBER>21432
}
Return Payload
{
"client_id": "ipad/123",
"client_name": "My first client",
"parent_org": {
"name": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
},
"parent_user": {
"name": "4321432143214321",
"kind": "Org",
"path": [
"Org",
"4321432143214321"
]
},
"client_secret": "$2a$10$L/GOsc5v4lw/iUzuYDOUH.zBEMb1fbYrFlJJXtLTYC78lG.1nl.Fa",
"created_at": "2018-01-16T23:25:25.685Z",
"modified_at": "2018-05-17T11:36:55.907Z"
}
Properties
| Name | Type | Required | Description |
|---|---|---|---|
| client_id | String | true | User defined id for the client |
| client_name | String | true | User defined common name for the client |
| parent_org | Integer | true | The id of this beacon's parent org |
| parent_user | Number | true | The id of this client's parent org* |
* DEPRECATED do not use
Appended Values
| Property | Description |
|---|---|
| created_at | When the entity was created |
| modified_at | When the entity was last modified |
| client_secret | API key hashed on creation |
Modified Values
| Property | From | To |
|---|---|---|
| parent_org | Integer | Object(Key) |
| parent_user | Integer | Object(Key) |
Event
Request Payload
{
"collected_at":<PHONE_NUMBER>,
"parent_org":<PHONE_NUMBER>341234,
"parent_beacon":<PHONE_NUMBER>325432,
"parent_sensor":<PHONE_NUMBER>89,
"event_reading": 123,
"event_type": "heart_rate"
}
Return Payload
{
"event_beacon": {
"id": "5432543254325432",
"kind": "Beacon",
"path": [
"Beacon",
"5432543254325432"
]
},
"event_sensor": {
"id": "678967896789",
"kind": "Sensor",
"path": [
"Sensor",
"678967896789"
]
},
"event_timestamp":<PHONE_NUMBER>,
"event_reading": 123,
"event_type": "heart_rate",
"created_at": "2018-02-05T20:18:25.706Z",
"modified_at": "2018-02-05T20:18:25.706Z",
"parent_org": {
"id": "1234123412341234",
"kind": "Org",
"path": [
"Org",
"1234123412341234"
]
}
}
Properties
| Name | Type | Required | Description |
|---|---|---|---|
| parent_org | Integer | true | The id of this beacon's parent org |
| event_timestamp | String | true | When did this event happen |
| event_reading | Integer | true | Value of the event's reading |
| event_type | String | true | Type of the collected event |
Appended Values
| Property | Description |
|---|---|
| created_at | When the entity was created |
| modified_at | When the entity was last modified |
Modified Values
| Property | From | To |
|---|---|---|
| parent_org | Integer | Object(Key) |
| event_sensor | Integer | Object(Key) |
| event_beacon | Integer | Object(Key) |
Org
Request Payload
{
"org_owner":<PHONE_NUMBER>325432,
"org_active": true,
"org_sensors": {
"1234567890981111":<PHONE_NUMBER>000
},
"org_beacons": {
"1234567890987654":<PHONE_NUMBER>829
},
"org_users": {
"1234567890988888":<PHONE_NUMBER>829
},
"org_alias": "FastCars Co.",
"org_clients": {
"1234567890987777":<PHONE_NUMBER>000
}
}
Return Payload
{
"org_sensors": {
"1234567890981111":<PHONE_NUMBER>000
},
"org_beacons": {
"1234567890987654":<PHONE_NUMBER>829
},
"org_users": {
"1234567890988888":<PHONE_NUMBER>829
},
"org_alias": "FastCars Co.",
"org_clients": {
"1234567890987777":<PHONE_NUMBER>000
},
"created_at": "2018-02-14T12:50:10.283Z",
"modified_at": "2018-02-14T12:50:10.285Z",
"org_owner": {
"id": "5432543254325432",
"kind": "User",
"path": [
"User",
"5432543254325432"
]
},
"org_active": true
}
Properties
| Name | Type | Required | Description |
|---|---|---|---|
| org_owner | Integer | true | The id of this org's owner |
| org_active | Boolean | true | If this org is enabled or not |
| org_sensors | Object(IdMap) | true | Map of child sensors |
| org_beacons | Object(IdMap) | true | Map of child beacons |
| org_users | Object(IdMap) | true | Map of child users |
| org_client | Object(IdMap) | true | Map of child clients |
Appended Values
| Property | Description |
|---|---|
| created_at | When the entity was created |
| modified_at | When the entity was last modified |
Modified Values
| Property | From | To |
|---|---|---|
| org_owner | Integer | Object(Key) |
Sensor
Request Payload
{
"parent_org":<PHONE_NUMBER>785678
"sensor_version": "7",
"sensor_type": "glove/palm",
"sensor_id": "12345"
}
Return Payload
{
"sensor_version": "7",
"created_at": "2018-02-15T12:56:48.338Z",
"parent_org": {
"id": "5678567856785678",
"kind": "Org",
"path": [
"Org",
"5678567856785678"
]
},
"sensor_type": "glove/palm",
"modified_at": "2018-02-15T12:56:48.339Z",
"sensor_id": "12345"
}
Properties
| Name | Type | Required | Description |
|---|
Appended Values
| Property | Description |
|---|
Modified Values
| Property | From | To |
|---|
Key
Keys objects are generated when creating entities and are the most direct way to reference (or retrieve) them. They are passed as integer to the API which turns it into an object or are created when a new entity is added
Request Payload
[...]
"event_sensor":<PHONE_NUMBER>89
[...]
Return Payload
[...]
"event_sensor": {
"id": "678967896789",
"kind": "Sensor",
"path": [
"Sensor",
"678967896789"
]
}
[...]
Properties
| Name | Type | Required | Description |
|---|---|---|---|
| id | Integer | true | This is the entity Id |
Appended Values
| Property | Description |
|---|---|
| kind | Entity type |
| path | Entity hiearchy path |
Modified Values
| Property | From | To |
|---|---|---|
| id | Interger | String |
IdMap
IdMap object are simple value maps of entities ids assigned an integer timestamp as their only properties. Effectively, we're using this to keep track of dependent entities and to enable or disable them. A non-zero timestamp enable an entity, while a zero value disable it
We are using timestamp rather than boolean because it allows us to make complex queries without the need to compile indexes (see this GCP documentation for more details)
Request Payload
[...]
"1234123412341234":<PHONE_NUMBER>4
[...]
Return Payload
[...]
"1234123412341234":<PHONE_NUMBER>4
[...]
Properties
| Name | Type | Required | Description |
|---|---|---|---|
| Timestamp | Integer | true | Epoch timestamp to enable; zero value to disable |
Errors
The ox
API uses the following error codes:
| Error Code | Meaning |
|---|---|
| 400 | Bad Request — Your request is invalid |
| 401 | Unauthorized — Your JWT token is invalid |
| 403 | Forbidden — Your API key is wrong |
| 404 | Not Found — The ressource was not found |


ID Dr. Kenneth C. Edelin kill a person at Boston City Hospital? Can other
doctors be convicted of manslaughter in the deaths of fetuses they abort, as
Edelin was?
There are no commonly accepted medical or legal standards to define a human
being. Edelin's manslaughter trial early this year hinged on that definition
and on a cluster of related questions about the limits of human life and
medical responsibility. They are questions that will grow in urgency as doctors
become more skilled in sustaining life before an infant can function for
itself, or after an old or sick person loses his capacity to function.
"A fetus is not a person and not the subject of an indictment for
manslaughter," Boston's Superior Court Judge James P. McGuire told the jury.
Yet twelve men and women found Edelin guilty on February 15 of homicide in the
death of a twenty- to twenty-four-week-old fetus during the course of a legal
abortion.
Their verdict left doctors and lawyers debating over just what it was Edelin
had killed. Under the judge's instructions it had to have been something more
than a fetus. If so, at what point did the fetus become a person protected by
law? To stay on the safe side of that question, a number of hospitals around
the country have now cut back on abortions performed after the third month of
pregnancy.
In reaching their decision, the jurors appear to have ignored many of the legal
and medical points raised about the scope of an abortion, the moment of birth,
and the ability of a fetus to survive on its own. And they left behind them
questions about whether a jury of laymen can be asked to decide a case whose
outcome rests on technical questions and disputes over definitions.
"I don't believe it's possible for a jury of people like those who were
selected to really understand the issues, especially some of the scientific and
medical problems encountered at the trial," Edelin said later. "We attempted to
educate them, and I guess we failed. As a jury of my peers...it certainly was
not."
The jurors themselves said they were most impressed by a photograph of the
fetus, which they said "looked like a baby," and by the prosecutor's insistence
that the aborted fetus was due all the attention a baby would receive.
"That baby should have had the chance to prove his own viability," said juror
Paul A. Holland. "There is only one person that can make that decision, and
that is the baby....We did not agree that [Edelin] took the proper precautions
in checking the baby."
Although the verdict may have appeared to run counter to much of the testimony,
it did make a statement that doctors and lawyers must now take into account. It
made a statement about the attitudes of twelve ordinary people toward the
potential person involved in an abortion, and about the duty a doctor owes
it.
Edelin, thirty-six, is coordinator of ambulatory services in the obstetrical
and gynecological ward of Boston City Hospital, where many of the patients are
black and poor. At the time of the abortion, he was chief resident in the
department, one of only two residents who routinely performed abortions.
Although he does not like to perform them, he says, he believes strongly that
he has an obligation to provide the best medical care to a woman, whether she
wishes to give birth or terminate her pregnancy.
"I will continue to do abortions. They are a woman's right," he said after his
conviction, "Women since they've been on this earth have been making that
choice, whether they want to carry that baby or not....The only humane thing we
can do is make sure that when they make that choice they have the opportunity
to make it under the best conditions possible."
On October 3, 1973, Edelin performed a legal abortion at the request of a
pregnant seventeen year-old, completing the operation by hysterotomy or
mini-Cesarean, after three attempts at saline infusion failed. In the
hysterotomy, he removed the fetus through an incision in its mother's abdomen
peeling it from the wall of the womb and scooping it out along with the
afterbirth.
Two months later, investigators from the Suffolk County district attorney's
office found the fetus in the hospital's morgue as they gathered evidence for
another indictment against four physicians performing research on the tissues
of aborted fetuses. That prosecution, based on an 1814 grave-robbing statute,
is next on Assistant District Attorney Flanagan's docket.
When Edelin's case came to trial in January, Flanagan argued that although the
abortion was legal, the death of the fetus was not; that the abortion was
completed the moment the fetus was separated from the wall of the womb, and
that at that moment a baby was born "with all the rights that you have under
the Constitution of the United States."
Defense Attorney Homans called this reasoning "metaphysical." He argued that
the entire operation, including the death of the fetus, was protected by the
U.S. Supreme Court's decision legalizing most abortions. In any event, he said,
the fetus never was born and never legally became a person.
The conviction of Dr. Edelin, despite that defense, opens the possibility that
any doctor maybe convicted of homicide in the death of a legally aborted
fetus--particularly in late abortions and those performed by hysterotomy, which
run the risk of producing a fetus that shows at least fleeting signs of life.
The trial raised sensitive questions skirted by the companion Supreme Court
rulings of January 1973, known as "Roe and Doe." In those rulings, the court
barred states from interfering with a woman's right to an abortion before a
fetus became viable--but left the moment and definition of viability unclear.
And the trial reopened debate about the status of persons on the fringes of
life, either side of the moment of birth or death.
"If the obstetrician has the right to destroy the live-born infant in an
abortion procedure, would he not have the same right to extinguish the life of
a newborn infant with a congenital defect whose mother may not want him?" asked
Dr. Matthew J. Bulfin of Fort Lauderdale, Florida, president of the American
Association of Pro-Life Obstetricians and Gynecologists "The acceptance of this
principle surely would in fact be providing legal endorsement for euthanasia.
As this debate was brought into the courtroom, with separate sets of medical
experts testifying for the prosecution and defense, the jurors found themselves
confronted with at least two conflicting opinions on almost every point
raised.
In Roe and Doe, the court said a fetus is generally considered viable at about
twenty-eight weeks' gestational age, but that viability sometimes comes as
early as twenty-four weeks. It drew its estimates from generally accepted
medical practice. But the authors of two basic obstetrical textbooks, on which
much of this practice is based, testified at the trial to their own uncertainty
about the age at which a fetus can survive. They and other doctors also pointed
out that "survival" itself is a disputed concept: does it mean life for a
minute, for twenty-eight days, or for a lifetime of contribution to society?
Flanagan capitalized on their uncertainty, asking each one whether the
determination of viability should not be left up to the fetus itself, no matter
how statistically tiny its chance. The doctor's role, he said, is simply to
give it the best medical care as it struggles for life.
Roe and Doe also did not specifically define abortion, leaving another open
question whose answer could affect Edelin's fate. If abortions presuppose the
death of the fetus, as Edelin claimed, then his entire procedure was legal and
immune from prosecution. But Flanagan's medical experts insisted that an
abortion was nothing more than the termination of pregnancy, which could
sometimes result in a live birth.
The definition of birth itself became pivotal as witnesses raised questions of
fact about the procedure Edelin used and the exact moment the fetus died,
Doctors testifying against him agreed that birth means the separation of the
placenta from the wall of the womb, the moment at which the fetus "goes on its
own systems" for nourishment and oxygen. Defense witnesses repeated the more
commonly understood definition of the word as involving expulsion or removal
from the mother's body. And Judge McGuire supported that understanding of the
word in his charge to the jury.
The distinction was crucial, for Edelin was accused of killing the aborted
fetus before removing it from inside its mother. Flanagan charged that he held
it motionless inside the womb and watched a wall clock for three minutes as it
struggled for air and died. Edelin, supported by testimony from two nurses and
a medical student, denied the three-minute wait, and claimed that in fact there
was no working wall clock for him to watch. But he did not deny that he had no
intention of delivering a live baby: "It would have been contrary to the wishes
of the mother."
Although Flanagan's only eyewitness had testified emphatically that "the baby
was dead" when Edelin finally removed it, the prosecutor brought other
witnesses who claimed it had breathed outside its mother. On the basis of their
examination of its lungs, a medical examiner and a pathologist testified that
the fetus could have drawn breath outside its mother.
But witnesses for the defense looked at the same slides of lung tissue and
insisted that no air had been breathed, that the lungs showed signs of gasps
within the uterus but not outside it. One of these witnesses even suggested
that the gasps had come during the earlier attempts at saline infusion, and
that the fetus had died at that time--before the hysterotomy began.
In the face of the series of contradictory testimony throughout the trial, the
jury's verdict appeared to fall short of the "moral certainty beyond a
reasonable doubt" that Judge McGuire said was called for. The verdict appeared
to be based on a series of possibilities: that the fetus might have been a
person, might have been viable, might have been born, might have breathed
outside its mother.
But it did appear to reflect a certainty that neither the legal rights of the
surgeon nor the wishes of the mother were enough to deny the fetus a chance for
life. The jury's decision, based on a photograph that "looked like a baby,"
appeared to state that as long as there was a reasonable doubt that this was
not a person, it must be treated with every care a person would receive.
Edelin talked later about the hard decisions every doctor must make, the
balancing he must do between the needs of the mother and the aborted fetus,
between those of the fetus and a premature infant who may need attention.
There is likely to be an increasing number of these hard decisions as
artificial placentas, or test tube babies, are developed, and as doctors learn
to keep alive the old and sick.
The decisions are currently being made in a legal vacuum, and the trial of
Kenneth Edelin served to point out some of the questions that need to be
answered.
Copyright © 1975 by Seth Mydans. All rights reserved.


Boring Political App
See what your government is up to by discovering upcoming political bills that interest you.
Search
Hot Topics
Recent Searches By Users
Boring Political App
Home
Search
Drag & Drop
Bills Here
Boring Political App
Home
Search
Contact Your Legislative Representatives
Street Address:
City:
State:
Submit