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.
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
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.
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.
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.
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.
