Call the free microtimestamp api endpoint
One GET request. No headers, no body, no key.
curl https://aisenseapi.com/services/v1/microtimestamp{"microtimestamp":1787171289.888783}Ask for whole seconds at the same moment and you get the integer half of that reading, nothing more.
curl https://aisenseapi.com/services/v1/timestamp{"timestamp":1787171289}Both paths sit on the same clock. Choosing between them is only a question of how much of the reading you intend to keep.
Trailing zeros are not written out. Six consecutive test calls returned values ending .223335, .471356, .737204, .981324 and .23985, and that last one carries five digits after the point rather than six. Treat the reply as a number, never as a fixed-width string.
Response field
The free microtimestamp api endpoint answers with a single field, and nothing else.
| Field | Type | Description |
|---|---|---|
| microtimestamp | number | Seconds since midnight UTC on 1 January 1970, with a fractional part to microsecond resolution. |
The reply arrives as application/json with HTTP 200. It ships cache-control: no-store, which is the honest header for a value that differs on every call, and access-control-allow-origin: *, so a browser page can read it without a proxy in front.
When the fraction earns its place
Whole seconds are the right default. Reach for the free microtimestamp api endpoint only when a second is too coarse to answer the question you are actually asking. Three cases qualify.
- Ordering events inside the same second
Two things happen in the same second far more often than intuition suggests. Four of the six test calls above landed inside second 1787178864. Stamp those four with whole seconds and they collapse into one value, and the order between them is gone permanently. There is no later repair for that, because the information was never written down.
- Measuring how long something took
Take a reading, do the work, take a second reading, subtract. The difference is a duration in seconds expressed as a decimal. Whole seconds cannot express a job that finished in 300 milliseconds, so it reads as either 0 or 1 depending on where the boundary fell.
- Correlating logs across machines
Two hosts write to two files, and later somebody merges them to reconstruct what happened. Second resolution produces ties everywhere, exactly where the interesting interleaving is. A fraction breaks most of those ties and turns a pile of lines back into a sequence.
Be honest about what the fraction is. It is resolution, not accuracy. This is a reading fetched over a network, so the round trip dominates anything below a few milliseconds. Use it to order and to measure, and use NTP on any host that needs its own clock to be genuinely correct. A useful habit is to compare a reading against the local clock at startup and refuse to run when the gap is wider than a few seconds. Drift on a suspended virtual machine or a container without NTP tends to surface as authentication errors rather than as a clock complaint, which is what makes it expensive to track down.
It is a float, and that has a ceiling
The value arrives as a JSON number with a decimal point. Most languages hand that to a double, and for a present-day epoch reading a double loses nothing at all.
The arithmetic is worth knowing. A double carries 53 bits of mantissa, so it represents every integer up to 9007199254740992 exactly. Write the reading above in microseconds and it becomes 1787171289888783, which is well under that ceiling. Every microsecond survives the parse, and that stays true until roughly the year 2255.
Push the magnitude higher and the guarantee stops. Nanosecond epoch stamps, the kind Go and several time series databases emit, run near 1787171289888783000 today. That is almost two hundred times past 2 to the 53rd power, so a JSON parser that reads numbers as doubles rounds it silently and hands back a value that is close but not equal. Nothing raises an error, and nothing in the output looks wrong. Microsecond resolution is the last step where a plain double still tells the truth, which is a good part of why this endpoint stops there.
Two practical consequences follow. Subtracting two readings gives a float, so round the result before you print it rather than showing fifteen digits of noise. And if you ever move to nanoseconds elsewhere, carry them as strings or as 64-bit integers and keep them away from a double.
Seconds, microseconds or a datetime string
Three shapes describe the same instant, and each one is cheapest for a different job.
Store and compare with whole seconds. Ten ASCII digits fit a URL, a filename, an environment variable, a signed header or a 32-bit column, and no parser anywhere disagrees about what they mean. That is what the Timestamp API endpoint is for, and it should be your default.
Show a person an ISO 8601 string. The Datetime API endpoint returns the same moment with an explicit offset, which is readable at a glance and useless as a sort key.
Translate a value you already hold with the Timestamp Converter API endpoint, which detects whether it received an epoch number or a date string and returns both. For named zones rather than fixed offsets, see the Timezones API endpoint. The Time APIs hub lays all of them out side by side.
Everything here is UTC. No hour happens twice in autumn and no hour goes missing in spring, so arithmetic on these values is just arithmetic. Convert to a local zone at the last possible moment, for display only.
Common uses
The free microtimestamp api endpoint suits any job where two events might share a second.
Sortable log lines
Stamp entries from several workers so a merged stream still sorts into the order things actually happened.
Queue message ordering
Give each message a fraction so a consumer can reconstruct the sequence when two arrive in the same tick.
Timing a request
Read before and after, subtract, and record a duration in seconds without shipping a benchmarking library.
Cross-host correlation
Point every machine at one neutral clock so their traces line up instead of drifting apart file by file.
Thin clients
Hand a shell script or an embedded board a sub-second reading without a date library or a battery-backed clock.
Limits on the free microtimestamp api endpoint
This path takes no input at all. There is nothing about the caller in the request to record, and the reply depends only on the server clock.
Never put the response behind a cache or a CDN rule. A stale time is worse than no time, because it looks perfectly valid. The service-wide limit is 5000 requests per IP per 24 hours, which is generous for ordering and timing work and is not meant to feed a polling loop.
No key and no account are needed anywhere on this base URL. Every other service on the host follows the same rules, and you can browse them all in the full list of free public REST APIs.