Hello dweeters we've added three new endpoints to dweet.cc that give your devices confidence that their data arrived safely, even on unreliable connections.

The Problem

Standard dweets are fire-and-forget. Your device sends data and hopes it arrived. On unreliable networks (mobile, IoT, WiFi dropouts) you have no way to know if:

The request never left the device
The request left but never reached the server
The server received it but the response never got back to the device

The Solution — Three New Endpoints

1. Send with Guaranteed Delivery (sla=1)

Add sla=1 to any dweet and the server returns a unique delivery token:

curl "https://dweet.cc/dweet/for/my-thing?temp=21&sla=1"

{
    "this": "succeeded",
    "with": {
        "thing": "my-thing",
        "created": "2026-08-11T14:26:13+00:00",
        "content": { "temp": "21" },
        "delivery_token": "ed91207f0f178f4656d1146e67be20f2",
        "confirmed": true
    }
}

Your device should store the delivery_token locally using bash etc. The confirmed: true in the response means the server received and stored the dweet successfully.

2. Confirm Delivery by Token (/confirm/TOKEN)

If your device stored a token but isn't sure the response was seen, it can verify at any time:

curl "https://dweet.cc/confirm/ed91207f0f178f4656d1146e67be20f2"
{
    "this": "succeeded",
    "confirmed": true,
    "thing": "my-thing",
    "created": "2026-08-11 14:26:13",
    "content": { "temp": "21" }
}

If the token is not found you get confirmed: false with a 404 — meaning the dweet never arrived and should be resent.

3. Check Last Delivery (/last/confirm/THING)

On reconnect, your device can check whether its last SLA dweet arrived without needing to store a token:

curl "https://dweet.cc/last/confirm/my-thing"
{
    "this": "succeeded",
    "confirmed": true,
    "thing": "my-thing",
    "created": "2026-08-11 14:26:13",
    "delivery_token": "ed91207f0f178f4656d1146e67be20f2",
    "content": { "temp": "21" }
}

4. Idempotent Sending (idem=YOUR_KEY)

Combine with sla=1 to prevent duplicate dweets when retrying. Your device generates a unique key per reading (e.g. boot count + timestamp) and includes it:

curl "https://dweet.cc/dweet/for/my-thing?temp=21&sla=1&idem=boot-1234"

If the same key is sent again (retry after network dropout), the server returns the original dweet instead of creating a duplicate:

{
    "this": "succeeded",
    "idempotent": true,
    "with": {
        "thing": "my-thing",
        "created": "2026-08-11 14:26:13",
        "content": { "temp": "21" },
        "delivery_token": "ed91207f0f178f4656d1146e67be20f2",
        "confirmed": true
    }
}

The idempotent: true flag tells your device this was a duplicate — same token, no new dweet created.

Failure Scenarios & How to Handle Them

Scenario 1 — Device sent, server never received

Device sends sla=1, gets no response or a network error
Device retries with same idem key
If server now responds with confirmed: true — dweet arrived on retry
If server responds with idempotent: true — arrived on an earlier attempt
If /last/confirm/my-thing returns a timestamp older than expected — dweet never arrived, resend

Scenario 2 — Server received but response lost

Device sends sla=1&idem=boot-1234, server stores it, response lost in transit
Device retries with same idem key
Server returns idempotent: true with original token — no duplicate created
Device now has the token and knows it arrived

Scenario 3 — Network dropout mid-send

Device sends sla=1, connection drops before response
Device calls /last/confirm/my-thing on reconnect
If created timestamp matches expected send time — arrived safely
If not — resend with new idem key

Scenario 4 — Device reboots before storing token

Device had no chance to store the delivery token
On reboot, call /last/confirm/my-thing
Returns last known good delivery with timestamp
Device can compare timestamp against its own records

Scenario 5 — Prolonged outage, multiple missed dweets

Device queues readings locally during outage
On reconnect, sends each with unique idem key (e.g. reading-timestamp)
Safe to retry all — duplicates automatically rejected by idempotency key
Use /confirm/TOKEN for each to verify queue cleared successfully.

As always, feedback welcome below!