Getting 204 on subscription DELETE but subscription is still listed in user profile's Applications

[girias-mfp]

We're experiencing an issue where we get a 204 when trying to delete a user subscription, but the user subscription does not get deleted. Here's a sample cURL call:

curl https://api.fitbit.com/1/user/{user-id}/apiSubscriptions/{subscription-id}.json -H "authorization: Bearer {token}" -H "accept-language: en_US" -H "X-Fitbit-Subscriber-Id: {fitbit-subscriber-id}" -X DELETE -v

Here's the response we get back:

* Trying 104.16.65.50:443...

* Connected to api.fitbit.com (104.16.65.50) port 443 (#0)

* ALPN, offering h2

* ALPN, offering http/1.1

* successfully set certificate verify locations:

* CAfile: /etc/ssl/cert.pem

* CApath: none

* TLSv1.2 (OUT), TLS handshake, Client hello (1):

* TLSv1.2 (IN), TLS handshake, Server hello (2):

* TLSv1.2 (IN), TLS handshake, Certificate (11):

* TLSv1.2 (IN), TLS handshake, Server key exchange (12):

* TLSv1.2 (IN), TLS handshake, Server finished (14):

* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):

* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):

* TLSv1.2 (OUT), TLS handshake, Finished (20):

* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):

* TLSv1.2 (IN), TLS handshake, Finished (20):

* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305

* ALPN, server accepted to use h2

* Server certificate:

* subject: CN=*.fitbit.com

* start date: Oct 28 10:52:09 2021 GMT

* expire date: Jan 26 10:52:08 2022 GMT

* subjectAltName: host "api.fitbit.com" matched cert's "*.fitbit.com"

* issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1D4

* SSL certificate verify ok.

* Using HTTP2, server supports multi-use

* Connection state changed (HTTP/2 confirmed)

* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0

* Using Stream ID: 1 (easy handle 0x7fcb0980b600)

> DELETE /1/user/{user-id}/apiSubscriptions/{subscription-id}.json HTTP/2

> Host: api.fitbit.com

> user-agent: curl/7.77.0

> accept: */*

> authorization: Bearer {token}

> accept-language: en_US

> x-fitbit-subscriber-id: {fitbit-subscriber-id}

>

* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!

< HTTP/2 204

< date: Wed, 08 Dec 2021 20:32:12 GMT

< content-type: application/json;charset=UTF-8

< vary: Origin

< cache-control: no-cache, private

< content-language: en-US

< fitbit-rate-limit-limit: 1200

< fitbit-rate-limit-remaining: 1200

< fitbit-rate-limit-reset: 1668

< x-frame-options: SAMEORIGIN

< via: 1.1 google

< cf-cache-status: DYNAMIC

< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"

< server: cloudflare

< cf-ray: 6ba8c2fb7cf30e66-DFW

<

* Connection #0 to host api.fitbit.com left intact

[JohnFitbit · Accepted solution]

Hi @girias-mfp,

Welcome to the forums!

A 204 is correct in this instance as this indicate.s the subscription was successfully deleted. You can confirm this by executing the Get Subscriptions endpoint.

Additionally, please note that deleting a subscription will not revoke access to the Fitbit user's account. To revoke access to a user's account, you must use the Revoke Token endpoint. Revoking a user's access_token will invalidate all refresh_tokens and subscriptions associated to that user. As a result, your application will no longer appear in the Fitbit user's shared application settings.

I hope this helps clear up any confusion. Let me know if you have any additional questions.

[girias-mfp]

Hi @JohnFitbit, 

I really appreciate the response. I will test and let you know if we need further help, but I think this is what we need. Thanks!