{"__v":7,"_id":"5696fa4969393517000c8257","category":{"__v":5,"_id":"564514ff98da41190099f346","pages":["56451bbf98da41190099f352","56452bcc7f1fff210078e754","5645518cdecdee0d0090b786","56735fc247f7010d005bfdd6","5696fa4969393517000c8257"],"project":"5644e8bed608df0d00d269d9","version":"5644e8f22229d7170010923b","reference":false,"createdAt":"2015-11-12T22:38:55.104Z","from_sync":false,"order":3,"slug":"metric-data","title":"Metric Data"},"parentDoc":null,"project":"5644e8bed608df0d00d269d9","user":"564aa930c58bef0d006206fc","version":{"__v":15,"_id":"5644e8f22229d7170010923b","project":"5644e8bed608df0d00d269d9","createdAt":"2015-11-12T19:30:58.871Z","releaseDate":"2015-11-12T19:30:58.871Z","categories":["5644e8f32229d7170010923c","564514ff98da41190099f346","564523546b0ca50d00f6bdb8","564533dc6b0ca50d00f6bdcf","564535c16b0ca50d00f6bdd2","5645397a6b0ca50d00f6bddb","5645451eda14e70d0027cd2c","56454606decdee0d0090b774","564550e2bb7ad50d00e9c4ce","566f6768f11d5a0d007226e3","56a65b2f2ec8310d007bc1f2","56d77760693ef41d0003ac19","57151b8f11537f19006aab1e","5720e5dbdb52d01700f5d267","57487fd7db76422200d95873"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"2.0.0","version":"2"},"updates":[],"createdAt":"2016-01-14T01:30:49.704Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":0,"body":"The /datapoint API endpoint allows for sending data points to SignalFx. It is a versatile endpoint that supports multiple content types, as well as streaming and non-streaming requests.\n\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Streaming data points to SignalFx\"\n}\n[/block]\n**JSON**\n\nThe simplest way to send a single JSON-encoded data point is by making a simple POST request to that endpoint. The query string must contain the ID of the organization you are sending the data point into, while the body must be a JSON document describing each measurement (with their metric name, dimension(s) and value) for each metric, by type.\n\nTo specify the timestamp of the measurement, add a timestamp field (in milliseconds since the Unix Epoch of 00:00:00 UTC on 1 January 1970) to each JSON object being sent. Note that timestamps must be monotonically increasing per time series; data points with timestamps lower than previously seen for the same time series will be ignored. If you don't specify a timestamp, SignalFx's server clock will be used and the time the datapoint is received will be attached to the data point.\n\nNote that the orgid parameter is only required when you use a user session token. If your authorization token is an organization-wide API ingest token, the organization ID is automatically inferred from the token.\n\n\n**PROTOBUF**\n\nThe /datapoint endpoint also supports a more bandwidth efficient way of sending data points to SignalFx using a ProtocolBuffer encoding. The [signalfx-protoc](https://github.com/signalfx/signalfx-java/tree/master/signalfx-protoc) package contains the ProtocolBuffer definition of the DataPoint message that is expected by the API.\n\nTo send data encoded as ProtocolBuffer messages, you'll have to make sure your POST request declares the application/x-protobuf content type.\n\n\n**METRIC, DIMENSION AND METRIC TIME SERIES**\n\nWhen sending data points, you are required to specify a metric, to which you can add any number of dimensions (zero or more) to complete the unique identity of the metric time series that represents that particular series of measurements.\n\nA metric time series also inherits, via property propagation (read below in Metadata), all the properties of its parent dimensions and of its parent metric (the metric name and the metric type being two of the most important).\n\n\n**METRIC TYPES**\n\nIf you send a data point to a non-existent metric, the new metric will be automatically created using the metric type under which it was reported. The [available metric types](https://support.signalfx.com/hc/en-us/articles/201213445) are [gauge](https://support.signalfx.com/hc/en-us/articles/203758549#gauge), [counter](https://support.signalfx.com/hc/en-us/articles/203758549#counter) and [cumulative_counter](https://support.signalfx.com/hc/en-us/articles/203758549#cumulativecounter). You can of course send data for different time series of different metric types in the same API call.\n\nIt is also possible to change the metric type after the metric has been created, using an API call or in the product UI. Keep in mind that if you do so, the data ingested before the type of the metric was changed will not be recalculated and may thus appear incorrect, mathematically speaking.","excerpt":"","slug":"sending-data-points","type":"basic","title":"Sending Data Points"}

Overview

Client Libraries

Authentication

Metric Data

Metric Metadata

Events

Tags

Alerting

Dashboarding

Organization

SignalFlow

SignalFlow API Reference

SignalFlow Library Reference

Sending Data Points

The /datapoint API endpoint allows for sending data points to SignalFx. It is a versatile endpoint that supports multiple content types, as well as streaming and non-streaming requests. [block:api-header] { "type": "basic", "title": "Streaming data points to SignalFx" } [/block] **JSON** The simplest way to send a single JSON-encoded data point is by making a simple POST request to that endpoint. The query string must contain the ID of the organization you are sending the data point into, while the body must be a JSON document describing each measurement (with their metric name, dimension(s) and value) for each metric, by type. To specify the timestamp of the measurement, add a timestamp field (in milliseconds since the Unix Epoch of 00:00:00 UTC on 1 January 1970) to each JSON object being sent. Note that timestamps must be monotonically increasing per time series; data points with timestamps lower than previously seen for the same time series will be ignored. If you don't specify a timestamp, SignalFx's server clock will be used and the time the datapoint is received will be attached to the data point. Note that the orgid parameter is only required when you use a user session token. If your authorization token is an organization-wide API ingest token, the organization ID is automatically inferred from the token. **PROTOBUF** The /datapoint endpoint also supports a more bandwidth efficient way of sending data points to SignalFx using a ProtocolBuffer encoding. The [signalfx-protoc](https://github.com/signalfx/signalfx-java/tree/master/signalfx-protoc) package contains the ProtocolBuffer definition of the DataPoint message that is expected by the API. To send data encoded as ProtocolBuffer messages, you'll have to make sure your POST request declares the application/x-protobuf content type. **METRIC, DIMENSION AND METRIC TIME SERIES** When sending data points, you are required to specify a metric, to which you can add any number of dimensions (zero or more) to complete the unique identity of the metric time series that represents that particular series of measurements. A metric time series also inherits, via property propagation (read below in Metadata), all the properties of its parent dimensions and of its parent metric (the metric name and the metric type being two of the most important). **METRIC TYPES** If you send a data point to a non-existent metric, the new metric will be automatically created using the metric type under which it was reported. The [available metric types](https://support.signalfx.com/hc/en-us/articles/201213445) are [gauge](https://support.signalfx.com/hc/en-us/articles/203758549#gauge), [counter](https://support.signalfx.com/hc/en-us/articles/203758549#counter) and [cumulative_counter](https://support.signalfx.com/hc/en-us/articles/203758549#cumulativecounter). You can of course send data for different time series of different metric types in the same API call. It is also possible to change the metric type after the metric has been created, using an API call or in the product UI. Keep in mind that if you do so, the data ingested before the type of the metric was changed will not be recalculated and may thus appear incorrect, mathematically speaking.