End of life for api.spark.io


As of today, the Particle API can only be accessed through the api.particle.io domain. Access through the legacy domain api.spark.io has been disabled.

I notified Particle users with web applications that made requests to the api.spark.io domain of this planned end of life by email one month ago.

If you have a web application that stopped working because of the domain change, you must update it to make Particle API requests to the api.particle.io domain. No other change should be necessary in your application as the functionality of the Particle API offered by api.spark.io and api.particle.io is identical. In particular, no changes to the firmware running on devices is necessary.

If you use the deprecated sparkjs library, consider upgrading to particle-api-js or at least updating to the latest version of sparkjs which is configured to use api.particle.io.

HTML page suddenly won't work

Farewell, old friend :cry:



This post was flagged by the community and is temporarily hidden.


Are you going to change it from coreid to sparkid tomorrow without warning as well?


This post was flagged by the community and is temporarily hidden.


That’s exactly what happened. Can you check your mail (the one that’s registered and hitting the API) to make sure that email didn’t end up where it didn’t belong (spam)?

While the Spark domain has been deprecated for years, I’m sorry you had to find out the hard way, that shouldn’t be the case :confused:


Dude, First learn the form rules, and how to control your anger / language.
Second, Who’s decision was it to use a service that you have no control over in the first place? If it was that critical to you and your operation you should not have used any service that you have no control over.


Hey Mark, I sent you an email on May 30 with the subject “End of life for api.spark.io” to give you a heads-up of this change.

I hope you’re able to to update your application to use api.particle.io from the instructions in the message at the top of this thead.


Hi, I updated to api.particle.io within a few minutes of finding the error. Re-published our functions and all was good. We had ignored http errors previously as we commonly see “{ RequestError: Error: ESOCKETTIMEDOUT at new RequestError…” when cores are offline. We’ve specifically added that error to be ignored and everything else to thrown as an error which will trigger our alarm notifications.

I am very surprised that you didn’t follow up with contacting customers more directly. One email is a pretty lame attempt. I presume, per good practice, you ran the report of who was using it again before turning it off? If that was actually done, I am curious what went through the engineers head, I imagine it was something like ‘oh who cares’.

I apologise for swearing but I’m a little disenfranchised with Particle. 500 chips were assigned to another customer the other month and it took over 14 days for Particle to fix that mess up. Latest firmware has a bug with wifi ssids starting with numbers or containing spaces. The latest is some one deciding turning off a busy API was a good idea.


I agree. You’re right. Having traffic go in/out of Particle cloud is a major point of failure.


A suggestion @jvanier for next time you communicate a major service EOL is don’t send from your personal account. I’m sure you’re a great guy, but we’re not friends, I don’t know who you are and it’s not in response to an email I’ve sent. Nothing in the person field or subject line highlighted it was Particle.

Seen as you only send one email one month before it seems important to really get people’s attention in subject line and first sentence of the email. From the preview it looks like you’re about to suggest I send you money to Nigeria so you can pay a lawyer to claim a massive inheritance. It didn’t get a serious second look when I scanned the clutter folder.


Just so I am clear. I am not saying there is anything wrong with Particle at all. In fact they have a great track record for keeping the system up and running.
The problem I see with this whole somewhat old now IoT era is the push to have services in the cloud. Weather that be Amazon services or any other. Personally I am not going to have thousands or ten’s of thousands of my devices out in the wild relying on a cloud service. You never know what could happen out there. If something does do hanky with the service, it brings the whole thing crashing down. Then you have 10k+ customers calling you up complaining 24/7 about a issue that you have no control over.
Na… I would rather pay for setting up and installing my own in house server so at least we can control it all.


Thanks for the feedback on the email title and number of email. We’ll keep that in mind for future announcements to platform changes. I’m glad to know that you were able to get your web application back up shortly after finding the error.


Fair enough.

You’d have to have a 2M opex budget and initial capex of about 1M to do a half decent single site deployment. That’s the rub, single site. Adding two sites is double the capex and about half the additional opex (as I was counting 24x7 staff and operational management layers on top and licensing), even counting the leased dark fibre between sites.

Google cloud functions cost next to nothing. Google Firebase is hands down the most revolutionary realtime database system we’ve seen come out in 10 years. Marriage in heaven for mobile as a service. They don’t even bother talking to you about availability zones, it’s just done for you. My costs are a rounding error on the cost of running your own. Serverless compute is the future.

My speciality in IT is high availability application delivery networks. Fingerprints all over the largest uni’s / telcos and banks here. I’m happy to hang up my hat and let Google do the heavy lifting. They’re really, really, really good at it.

ps, Google deprecation notices are usually numbered in years and they flash warnings to you as an user when you use their CLI or console about services you’re using that are being deprecated. Even the Particle API could contain a deprecation warning if the return object was structured correctly.


I usually expect a magic phrase in the subject line of deprecation e-mails “ACTION REQUIRED” while you’re looking at notes for next time.