Some background.#

For three years every plant page on Plant🌱Smart ended with the same two phone numbers and both of them were for the US. That never really sat right with me. I even flagged it as roadmap work when I rebuilt the site, then left it sitting there. The site’s whole reason for existing is for the moment your cat eats something and you need an answer now. For most of the people who land there from a search engine, I was answering with a number they can’t dial. So, I recently sat down to address that gap, assuming I’d spend a few minutes filling in a table of hotlines and be done with it.

Every single country had a speed bump.#

• Sweden’s poison centre stopped answering questions about animals in July 2018 because the human call volume got too high.
• The Dutch line only takes calls from vets, so if you’re a pet owner in Rotterdam, the correct advice is “ring your vet and let them ring the line”, which is not a phone number at all.
• Belgium answers animal calls only during the day and says outright on its own site that it isn’t funded for animal work.
• The Australian helpline I’d have sworn was free actually starts at $75. This is a bit embarrassing because I live here and should know this.
• The UK’s fee changes depending on the time of day you call.
• The ASPCA doesn’t publish its consultation fee anywhere on its own page, so the figure everyone quotes online comes from third parties.

The list goes on.

I’d have got at least half of these wrong from memory, which is a genuinely unsettling thing to realise about emergency information.

Once again, I had to collate a bunch of disparate data and create a shape to support it before munging it all together. Every entry in the hotlines list now cites the operator’s page it came from and the date I read it which is the same rule I put on the plant records in the last post. A Python script holds the whole list and nags me when an entry goes over a year old and it runs as part of the automated deployment. So, the build gives me a big’ole bonk on the nose whenever the list goes stale.

The boring technical stuff.#

The engineering ended up being the easy half and mostly a matter of deciding what fails safely. Hugo writes every country into the HTML as a partial. A small script then lifts the relevant one out and folds the rest away. It guesses in order: a country you’ve pinned, then the location filter if it names exactly one country, then your browser locale.

It never asks permission for anything, because a permission prompt at 2am is the last thing you need while you’re panicking about your pet. And, personally, I hate browser prompts asking for location tracking. Hard pass. If the script doesn’t run, or if the service worker hands you a stale page, you get all countries instead of the wrong one.

There’s also a new emergency page for the first five minutes before you get through: what to do, what not to do and what they’ll ask you. The guidance follows the ASPCA and the Pet Poison Helpline which is also cited and linked. After all, the one thing I’m definitely not qualified to write is clinical advice.

Another free gift: the hotlines API.#

There’s really no obvious centralised place online that collates all this information into a single data set. I’ve at least done the work of bootstrapping the handful of most common countries that have helplines and the list will definitely grow over time. So, I’ve exposed a new “hotlines” API endpoint with its own documented shape.

{
    "countries": {
        // ... more countries ...
        "US": {
            "checked": "2026-09-10",
            "name": "United States",
            "services": [
                {
                    "audience": "owner",
                    "display": "(888) 426-4435",
                    "fee": "A consultation fee applies",
                    "hours": "24 hours, every day",
                    "org": "ASPCA Animal Poison Control Center",
                    "source": "https://www.aspca.org/pet-care/animal-poison-control",
                    "tel": "+18884264435"
                },
                {
                    "audience": "owner",
                    "display": "(855) 764-7661",
                    "fee": "$89 for each incident",
                    "hours": "24 hours, every day",
                    "org": "Pet Poison Helpline",
                    "source": "https://www.petpoisonhelpline.com/about/",
                    "tel": "+18557647661"
                }
            ]
        }
    },
    "notice": "Emergency telephone numbers for animal poisoning. Each country cites the operator page the entry came from and the date a person read it. Services close and numbers change, so check an entry before you rely on it. Coverage is not global. A country in this file with an empty services list has been checked and has no service an owner can call. A country that is absent has not been checked.",
    "updated": "2026-09-10"
}

I felt wrapping it in an envelope was the correct approach here. It leads with the notice and the date I last changed anything. A .countries object follows, keyed by ISO 3166-1 alpha-2 code. At the very least, it gives me room to change a country’s metadata later without breaking the top-level shape.

The audience field on each service is what carries the Dutch problem into the data. It reads either owner or vet. A vet entry means the number exists but you can’t ring it yourself, so the entry tells you to phone your vet and let them make the call.

Anyway, along with some stylistic changes and code cleanup, that’s pretty much all there is to it for this update. I’ll be giving Plant🌱Smart a rest for a bit while all the changes settle in. This gives me some time to work on other fun things!

Enjoy, nerds!

The database lost some weight.#

Originally, the plant database held around 480 records. It now holds around 280, so roughly 200 records are gone. About 170 of them came from a single symptom list and all of them included “cardiac failure”. That one symptom pushed every associated record to the top severity level. They read as “critical” because of the shared symptom list, not because of the plant itself. The list came from older sourced data that I never properly scrubbed and vetted, so I nixed those records entirely from the primary data set.

Sucks, but a smaller database you can trust beats a bigger one you cannot.

How I source vetted data.#

At the moment, I check each record against the following authoritative data sources:

• The ASPCA toxic plant list. It gives the clinical signs for dogs, cats and horses. This is the original reference that started the project way back in December of 2022.
• The Guide to Poisonous Plants from the College of Veterinary Medicine and Biomedical Sciences at Colorado State University. It gives the clinical signs for each body system and it names the animals that the plant affects. It is stronger than the ASPCA list on horses and other farm animals.

Every one of the 280 or so records that remain traces back to at least one of these two references. This is a hard requirement. If a plant can’t clear it, it doesn’t get a record.

Both references are copyrighted material. I cite them and link to them directly without publishing any of their text. Each record holds my own symptom names only. If you’re curious, the attributions page lists every licensed source used to build the site.

If you know of another authoritative data set that covers animals, the plants that are toxic to them and the associated symptoms, please let me know in the comments below or on the contribute page.

What I removed, specifically.#

I removed the inaccurate records and enriched and corrected the rest. These changes break down into three groups.

1. The old data set covered seven animal types. The update reduces coverage to cats, dogs and horses. That doesn’t mean I’ve given up on birds, fish, reptiles and small mammals. If I find good data for any of those groups, they go straight back in. Until then, they’re parked.
2. I also changed the rule that sets the severity level of each record. The old rule just took the worst symptom on the record. Now there’s an extra condition: a record with a single “critical” symptom and no “severe” symptoms gets marked “severe” instead. Nothing huge, but I felt it was worth mentioning.
3. A handful of records turned out to be duplicates, so I merged them.

The plant index is now a “Field Guide”.#

Reddit user u/Abbot_of_Cucany mentioned that their bird guide indexes each species twice: the common name in plain type and the scientific name in italic type. I thought this was a great idea, so I built it. Of course, I got a little carried away, so the page now also holds a filter box. Type part of a name and the page shows every matching plant on record. A letter row sticks to the top of the screen while you scroll and it marks the letter you’re currently reading through.

The front page got some filter updates!#

Some people requested more filters, so I delivered. The additions cover severity, plant shape and the geographical regions where you might come across a plant in the wild. Those last two data points were already sourced, but not really in use. At least not in any obvious way. I also added a newer, tighter, photo-centric grid view for smaller screens. Personally, I think it looks good, but I’m not sure if I’m going to keep it. Let me know what you think!

The extra dropdowns squished everything together in the filter bar, so I had to rethink how to display them. I replaced all the individual dropdowns with a single multi-level filter menu. You can now click around and filter as you go. I also shrank the icons a bit to save more space, but they expand when you hover over them with a mouse or tap them on a small screen.

Also, worth noting: your filter selections stay in the browser between visits.

The data for the “Found in” filter comes from GBIF, the Global Biodiversity Information Facility. GBIF counts the wild sightings of each plant in each country. A country counts as a match when it holds one percent or more of the sightings for that plant. It’s a totally arbitrary, non-scientific threshold that I imposed to keep the country list as tight as possible.

Safe plants get a facelift!#

The safe plants list now holds over 30 common household plants. The new entries include the spider plant, the bamboo palm, sage and baby’s breath, among others. A new entry joins this list only when the ASPCA marks the plant as non-toxic and only when the plant is absent from my own database. Each entry also carries a note that names the toxic plant people confuse it with. For instance, bamboo palm is safe while sago palm is deadly.

Based on a couple of user suggestions, each safe plant also includes a small gallery of three related photos sourced directly from the naturalist community at iNaturalist. Clicking a photo opens a lightbox with a zoomed-in view along with attribution and licensing information.

It now has a blog… sort of.#

This part wasn’t a suggestion. In addition to the updates page, I thought some kind of small blog would make sense. The articles I write about the site live here, where visitors to Plant🌱Smart will most likely never read them. So, instead of building actual blogging functionality, I decided to syndicate the articles from here. I updated my Hugo templates to generate an RSS feed for each tag. Every article about Plant🌱Smart carries the plantsm.art tag, so the site can ingest all the relevant content on its own.

The page shows one featured note first, just the latest entry in the list. Five recent notes follow as cards. Finally, an archive section gives one row per note, grouped by year. There’s just not enough content at the moment to fill that section out, so it stays hidden for now. Also, something you can’t see just yet: a text filter appears after 15 or so entries and works just like the one in the field guide.

Finally, some changes to the API.#

The API gives one file for each animal in the database. Since the data scrub, four of those files no longer exist: birds.json, small-mammals.json, reptiles.json and fish.json. The database itself no longer holds plant records for those animals. The API page documents the files that remain. Every other endpoint and every other shape stays the same.

What’s next?#

I want the other four animal types back. A rabbit owner needs this data as much as a dog owner does. I’m on the lookout for a reference that gives the symptoms per plant for birds, fish, reptiles and small mammals, but there’s just not a lot of authoritative data out there. If you know of one, tell me in the comments below or on the contribute page.

I also want those 170 records back, but each one needs a reference that names the plant and gives the clinical signs. Until then, they stay on the back burner.

That pretty much covers it. It’s been a fairly hectic week of coding and rolling out updates, but it’s been a lot of fun. At the time of writing, the Reddit post sits at over 530 upvotes! It’s always risky sharing something you’ve made with the world, but more often than not, people appreciate it. It really put a smile on my face.

Till next time!

If you use Github, you know it quietly records nearly everything you do as a stream of events. Better still, for a public repository, that stream is available over a public, unauthenticated API endpoint through a simple GET request.

So the plan more or less writes itself. We fetch the stream at build time, group the events by day, and let Hugo render them. Hugo even has a tidy little function for pulling in remote resources that works like so:

{{ $url := "https://api.github.com/repos/wilhelm-murdoch/wilhelm.codes/events" }}
{{ with try (resources.GetRemote $url) }}
  {{ $events := .Value | transform.Unmarshal }}
  {{/* ...range over them and render... */}}
{{ end }}

Because this all happens at build time, the visitor never waits on GitHub. By the time the page reaches a browser it’s just static HTML like everything else. The changelog is always current as of the last deploy, and I never have to think about it.

That’s the part that worked. Now for the parts that didn’t.

… Then, production happened.#

I’ve been more or less absent from this site for close to a year, but this past week I’ve decided to breathe a bit more life into it. I made a few changes to modernise the stack, pushed my changes up and waited on Cloudflare to do its thing and…

ERROR error building site: ... error calling GetRemote:
failed to fetch remote resource from 'https://api.github.com/...': Forbidden

I was greeted with a 403. Except… I could paste that exact URL into my browser and get a perfectly happy wall of JSON back. So what gives?

Rate limiting, that’s what. GitHub’s unauthenticated API is capped at 60 requests per hour, per IP address. My build doesn’t run on my IP. It runs on a shared build machine alongside who-knows-how-many other people’s deploys, all of them hammering GitHub from the same handful of addresses. By the time my build rolled around, that bucket was bone dry.

Honestly, a 429 instead here would have saved me a bit of investigating, but I digress.

The solution was to created a properly scoped Github PAT. Using an authenticated request gets 5000 requests per hour, so I went about implementing support and handed it to the build as an environment variable, and taught the template to send it along:

{{ $opts := dict }}
{{ with os.Getenv "HUGO_GITHUB_TOKEN" }}
  {{ $opts = dict "headers" (dict "Authorization" (printf "Bearer %s" .)) }}
{{ end }}
{{ $remote := try (resources.GetRemote $url $opts) }}

It’s worth noting that Hugo won’t read just any environment variable. Its security policy only lets os.Getenv see variables prefixed with HUGO_. Name your token GITHUB_TOKEN and you’ll get a confusing fistful of nothing; name it HUGO_GITHUB_TOKEN and it works. Ask me how I know.

Hark! Another Footgun!#

With the token in place, the fetch succeeded and the build promptly fell over somewhere new:

error calling len: reflect: call of reflect.Value.Type on zero Value

This never showed up locally, which tells me I should do myself a favour and do a quick local production deployment as a preflight before I push to Github and trigger an automated build. Originally, in development I rendered the changelog from a single large fixture file stored locally on disk. This was before I implemented the PAT so I wouldn’t rate limit myself locally when testing. The live stream, however, contains event shapes my fixture simply didn’t. One of them was a push event carrying no commits at all, and my template did this without a second thought:

{{ if eq (len .payload.commits) 1 }}

Call len on something that exists and isn’t there and Go has a small panic about it. The fix is boring; stop assuming the field is there. Hugo’s with only enters the block when its argument is actually… something:

{{ with .payload.commits }}
  {{ if eq (len .) 1 }}
    {{/* the one-commit case */}}
  {{ else }}
    {{/* the many-commits case */}}
  {{ end }}
{{ end }}

Since I’ve implemented PAT support, I’m not so concerned about being rate-limited during local development, though I now use the fixtures as a fallback if any request fails. This allows me to keep working locally without disruption.

Don’t let someone else’s server break your build.#

The real personal lesson is the moment your build depends on a third party at build time, you’ve effectively ceded control of your deployment to them. GitHub rate-limits you, or has a wobble, or changes a payload shape, and suddenly your perfectly good site won’t deploy and you’ll have a hard time.

So the changelog no longer treats GitHub as load-bearing. If the fetch fails for any reason it shrugs, logs a warning, and falls back to that saved fixture instead of taking the whole deploy down with it:

{{ $remote := try (resources.GetRemote $url $opts) }}
{{ with $remote.Err }}
  {{ warnf "changelog: GitHub fetch failed (%s); using the fixture" . }}
  {{ $response = os.ReadFile "static/github.json" | transform.Unmarshal }}
{{ else with $remote.Value }}
  {{ $response = . | transform.Unmarshal }}
{{ end }}

The try keyword is the hero here as it catches the error that GetRemote would otherwise throw and hands it back to me as a value I can actually do something with, rather than a smoking crater where my build used to be. Worst case, the page shows slightly stale history. That’s a trade I’ll take every single time over a red deploy or disruption to my local flow.

In conclusion…#

Ironically, this is something I’ve dealt with quite frequently at work. Github & AWS API rate limits ( yes, we frequently got rate limited by the VPC API of all things ), Yarn will throw a 5xx and even Sentry will chimp out during source map uploads. All of these things can disrupt deployments.

The point is just assume these things will happen and then build defensively around them. I, ehhhh, just need to apply this wisdom to my personal stuff. 😅

Anyway, the changelog still builds itself. It just doesn’t get to take the rest of the site down with it anymore.

Before we begin#

Today, I went ahead and made my Instagram profile private. I have no desire to delete my posts just yet, but decided to go ahead and unfollow everyone as a start. There are several ways to do this:

• API calls using an SDK, which requires a developer account.
• Manually deleting “handraulically” via the native app or browser, but that can quickly become tedious if you have more than a hundred or so follows.
• Random “GreaseMonkey” scripts off the web that may, or may not, work properly if at all.
• Reverse-engineering XHR calls from your browser and writing a simple Bash script to automate the process.

If you’ve read some of my previous blog posts, you probably can guess which one I’ll be going with.

Requirements#

This guide assumes you have some programming or scripting knowledge.

You will need the following on your machine:

• A shell terminal with Bash, or ZSH, support.
• curl to make API calls from the command line.
• jq to easily parse JSON-based responses from said API calls. This can easily be installed using Homebrew or some other supported package manager.
• A modern browser that supports a developer tools console to intercept XHR calls.

It’s worth mentioning that I am using a MacBook with the Chrome browser, but other webkit-based browsers should support similar functionality.

Fire up the browser!#

Open up your browser, or new tab, and navigate to your Instagram profile. Open your browser’s developer console and navigate to the “Network” tab. Clear out whatever requests are currently listed and then filter by “Fetch/XHR”.

Your following list#

We need to intercept an XHR request that returns a JSON body containing some of your followers. Click the “following” link and monitor the resulting requests that pop in the list on the “Network” tab.

You should see something like following/count=12... in the list. Right-click that item and select “Copy as cURL”. Paste the new value in your clipboard into a scratch file for reference later.

Be aware this command will contain all the headers required to make requests from your terminal on your behalf. Do NOT share these details with anyone. I haven’t checked how long until the tokens within the auth headers expire, so assume they are long(ish)-lived and treat them accordingly.

An unfollow request#

Next, we need to intercept an XHR request to unfollow someone. Going back to your following list, select a random user and unfollow them while once again keeping an eye on the “Network” tab.

You’re going to see something like the following; an XHR event making a POST request to “destroy” your chosen follower. Once again, you’ll right-click and “Copy and cURL”. Paste this into your scratch file as well for future reference.

Putting it all together#

Now that you have your two types of requests, we’ll need to script the following steps:

• Execute a curl request to fetch a JSON body containing the accounts you follow, one page of results at a time.
• Use jq to extract their Instagram IDs.
• Store the results in a variable named… drumroll, pls… $ids.
• Iterate through each $id.
• Execute a curl request to unfollow each $id.

Here is the meat of the script. I have included only the necessary headers required to successfully make these requests on your Instagram account’s behalf. You’ll need to swap out the ... with your own values.

You may also notice that I’ve change the count=... parameter to 100. It may be able to go higher, but I haven’t tested it.

ids=$(
  curl 'https://www.instagram.com/api/v1/friendships/.../following/?count=100&hl=en' \
    -H 'cookie: ...'           \
    -H 'x-asbd-id: ...'        \
    -H 'x-csrftoken: ...'      \
    -H 'x-ig-app-id: ...'      \
    -H 'x-ig-www-claim: ...'   \
    -H 'x-requested-with: ...' \
    -H 'x-web-session-id: ...' | jq -r '.users[].id'
)

while IFS= read -r id; do
  echo -n "Unfollowing user '${id}'"

  curl -s -o /dev/null "https://www.instagram.com/api/v1/friendships/destroy/${id}/?hl=en" \
    -H 'cookie: ...'           \
    -H 'x-asbd-id: ...'        \
    -H 'x-csrftoken: ...'      \
    -H 'x-ig-app-id: ...'      \
    -H 'x-ig-www-claim: ...'   \
    -H 'x-requested-with: ...' \
    -H 'x-web-session-id: ...' \
    --data-raw "container_module=profile&nav_chain=PolarisProfilePostsTabRoot%3AprofilePage%3A1%3Avia_cold_start%2CPolarisProfilePostsTabRoot%3AprofilePage%3A2%3Aunexpected&user_id=${id}"

  echo ' ... done!'
done <<< "${ids}"

echo "Finished"

You can save this as a file and make it executable, but I just paste this bad boy into your terminal. The above script will remove 100 accounts at a time. Just keep executing the script until you no longer see results like the following:

Unfollowing user '111'... done
Unfollowing user '222'... done
Unfollowing user '333'... done
Unfollowing user '444'... done
Unfollowing user '555'... done
Unfollowing user '666'... done
Unfollowing user '777'... done
Unfollowing user '888'... done
Finished

Caveats, gotchas & other things#

I’ve only had a few hundred accounts that I followed, so I didn’t feel the need to make this a bullet-proof solution. There’s quite a bit missing and things can go wrong. Here are some things to consider off the top of my head :

• The session tokens will expire eventually, so you will have to refer back to your “Network” tab in your developer tools console to get new ones.
• As this example only unfollows a static amount at a time, re-executing the script may become tedious for very large follow numbers. Perhaps, you can modify this script to add some basic pagination.
• There is no error handling here, so keep an eye out for potential rate limiting or expired token issues with the Instagram API.
• Constantly updating session header values can be made a bit simpler by resorting to variables instead.

In closing …#

Cleaning out old, unused or unwanted social media accounts can be liberating. I’ve recently gutted my Twitter presence and I haven’t been on Facebook in years, though I still do use Messenger to keep in touch with a handful of people. I’d prefer using Signal for this, but trying to convince other people to install yet another messaging app is like pulling teeth.

Anyway, I actually enjoy writing these kinds of posts. What other social networks should I cover? LinkedIn? Threads? What are some ways you can improve and build on the above? Lemme know in the comment section below.

Gathering Requirements#

Since we’re doing some destructive operations, we’ll need to make sure our Slack user has the appropriate permissions to manage emoji; adding & deleting. This means using a different section of the Slack interface which uses an entirely seperate set of API endpoints.

You’ll still be using the following, which can be found using instructions from the previous article:

• An API request token.
• A session cookie.
• A workspace, or team, id.

In addition, you will need your workspaces’s subdomain, or URL. This can easily be found within the Slack app itself:

Testing Your Findings#

This is an incredibly straight-forward process as it’s quite similar to what we already know. The primary difference is this is a multipart/form-data upload. So, instead of shipping of a JSON payload, it’s a form with associated fields.

With the information gathered above, you can upload directly to Slack using a simple cURL command like so:

curl -s --compressed "https://<domain>.slack.com/api/emoji.add" \
  -H 'content-type: multipart/form-data' \
  -H "cookie: d=<cookie>;" \
  -F "token=<token>" \
  -F "name=<name>" \
  -F mode=data \
  -F "image=@<local-emoji-path>"

Replace the following:

• <domain> is your workspace’s, or team’s, private URL.
• <cookie> is your session cookie value.
• <token> is your request token.
• <name> will be the named reference of your new emoji.
• <path> is the relative, or absolute, local path of your emoji file to upload.

The JSON response to this request will have the following structure if all goes well:

{ "ok": true }

And, if something went wrong:

{ 
	"ok": false,
	"error": "err_code"
}

That’s it! Now that we know how to upload from the command line.

The Implementation#

If you’re only uploading a handful of emojis, it might make sense to just do it via Slack’s UI. However, this can get a bit tedious if you have dozens, or even hundreds, to upload. We can automate things even further by:

• Gathering all supported images from a specific source directory.
• Iterating through our findings and bulk-upload them all in one go.

So, let’s do just that. But, first, let’s set up some environmental variables so we can easily configure out script:

: ${SLACK_COOKIE:=}
: ${SLACK_TOKEN:=}
: ${SLACK_DOMAIN:=}

Slack only supports png, gif and jpg image formats, so lets see what we can find from our present working directory:

files=$(find . -iname \*.gif -o -iname \*.png -o -iname \*.png -maxdepth 1)
[[ "${files}" == "" ]] && exit 0

Exit if we can’t find any results. No need to continue if we haven’t a thing to upload.

Next, we just iterate through our findings using read and some more Bash parameter expansion to determine what will be the new emoji’s reference name:

echo "${files}" | while read -r path; do 
  name=$(basename "${path%.*}")
done

We can easily parse the response bodies with jq for some error checking and we’re good to go:

if [[ $(echo "${result}" | jq -r ".ok") == false ]]; then
  echo "${result}" | jq -r ".error"
  exit 1
fi

We now have all the information we need to upload each file in bulk. Put it all together and you’ve got a working bulk emoji uploader:

#!/usr/bin/env bash

set -eo pipefail

: ${SLACK_COOKIE:=}
: ${SLACK_TOKEN:=}
: ${SLACK_DOMAIN:=}

files=$(find . -iname \*.gif -o -iname \*.png -o -iname \*.png -maxdepth 1)
[[ "${files}" == "" ]] && exit 1

echo "${files}" | while read -r path; do 
  name=$(basename "${path%.*}")

  result=$(
    curl -s --compressed "https://${SLACK_DOMAIN}.slack.com/api/emoji.add" \
      -H 'content-type: multipart/form-data' \
      -H "cookie: d=${SLACK_COOKIE};" \
      -F "token=${SLACK_TOKEN}" \
      -F "name=${name}" \
      -F mode=data \
      -F "image=@${path}" 
  )

  if [[ $(echo "${result}" | jq -r ".ok") == false ]]; then
    echo "${result}" | jq -r ".error"
    exit 1
  fi

  echo "uploaded :${name}:!"
done

There you go! To test it out yourself, save this as an executable script and make sure your present working directory has some supported images in it. Pass through the your environmental variables when executing and you’re off:

$ SLACK_DOMAIN=*** SLACK_COOKIE=*** SLACK_TOKEN=*** ./upload.sh
uploaded :stonks:!
uploaded :boop:!
uploaded :derp:!
uploaded :booyah:!
uploaded :merp-flakes:!

Nice! 😊

Once Again, Something Better!#

While perfectly functional, there’s not a lot of flexibility. No error checking, filtering or confirmation checks. If you’re looking for something a bit more fleshed out, look no further!

The Final Piece …#

So far, we’ve gone over how to download and upload large sets of emoji, but what if you want to nuke them from orbit? The final article in this series will cover how to bulk delete while using advanced filters to pin-point specific sets of emoji you wish to remove.

Hope you’ve learned something useful!

But, when it comes time to part ways it’s only understandable to want to gather your stuff for the next place to start the process again. Over the years one can collect and curate quite a nice hoard of stupid images.

I’ve been using Slack prolifically for the past few years. Unfortunately, there is no simple way of exporting your precious collection outside of the old “right-click and save” method. This is effective for smaller collections of a couple dozen or so, but becomes impractical when there are hundreds or even thousands.

And, of course, I’m not alone. There have been a non-zero number of times when someone left the company only to hit me up later asking for an emoji archive.

Yes, this really happens and something must be done about it!

What follows is an unnecessarily long dive into a little bit of reverse engineering one of Slack’s API endpoints, subverting it for our own use and writing a stupid little tool to help ourselves ( and others ) automate this process for the future.

Some Investigative Work#

There just has to be a straightforward way we can mostly automate this. So, I did some cursory digging around the Chrome Developer Tools console and found this endpoint in the “Network” tab:

https://edgeapi.slack.com/cache/T0XXXX/emojis/list?fp=97

The T0XXXX will be your workspace, or team, id. Make note of it, you’ll need it later.

If you intercept one of these requests and take a peak at the “Response” tab in the “Network” panel, you’ll see a JSON response with a structure similar to:

{
	"ok": true,
	"next_marker": "a-custom-emoji",
	"results": [
		{
			"name": "another-custom-emoji",
			"value": "https://emoji.slack-edge.com/T0XXXX/another-custom-emoji/xxxxxxx.png"
		}
		... more emojis ...
	]
}

• ok tells you whether the request was successful or not. If it returns false there will be an additional field named error that should clue you into what went wrong.
• next_marker tells you where in the list of custom emoji the next page of results should start. We use this as the value of marker in subsequent request payloads ( see below ). This is effectively how you page through large lists of emoji.
• results should be obvious, but it contains an array of objects with name and value fields.
  • name is the alias of the emoji.
  • value is the direct CDN URL to the emoji.

You may see other fields, but next_marker and value are the only fields we really care about.

Next, If you take a look at the “Payload” tab in the “Network” panel for the same request, you’ll see something similar to:

{
	"token": "xoxc-xxxx-xxxx-xxxx",
	"count": 100,
	"marker": "some-other-emoji"
}

• token is the API request token the Slack client uses to make the emoji list request on your behalf.
• count is the amount of emojis to return as a page.
• marker tells the API where in the emoji list to start paging.

The final piece of the puzzle is getting the value of your session cookie. You can grab this by clicking the “Request Headers” section under the “Headers” tab. You should see a header labeled cookie.

There’s going to be a fairly large block of text to parse through, but you’re looking for the cookie named d. Save everything between the d= and the closing ;. You’re going to need this to authenticate with the Slack API itself.

Testing Your Findings#

We now understand the structure of our payload. We also have the endpoint to hit as well as our tokens and session cookie to authenticate. Piecing it all together, you can now use cURL to hit the API directly from your terminal:

$ curl --silent https://edgeapi.slack.com/cache/<team>/emojis/list?fp=97
  -H 'cookie: d=<cookie>;' \
  --data-raw '{"token":"<token>","count":10}'

Replace the following:

• <team> is your workspace, or team, id.
• <cookie> is your session cookie value.
• <token> is your request token.

If everything worked out, you should have successful API response like the one above. If the response has root field named marker_next, make note of the associated value to help page through subsequent results. Keep doing this in a loop until your response no longer returns a marker_next field.

Once that happens, you’re at the end of the list.

With a little bit of help from jq to parse and filter the JSON responses, we can grab a simple list of URLs.

$ <previous_curl_command> | jq -r '.results[].value'
https://emoji.slack-edge.com/T0XXXX/no/060fca9aa2581a93.png
https://emoji.slack-edge.com/T0XXXX/nods/c7fe54342ab5b8b6.gif
https://emoji.slack-edge.com/T0XXXX/nods-back/fbd1b5384cdd0905.gif
https://emoji.slack-edge.com/T0XXXX/nomnomnom/612cfc74c785010d.gif
https://emoji.slack-edge.com/T0XXXX/octocat/627964d7c9.png
https://emoji.slack-edge.com/T0XXXX/ohyou/6a352df984d9c076.gif
https://emoji.slack-edge.com/T0XXXX/one-sec-cooking/e749627cb088859d.png
https://emoji.slack-edge.com/T0XXXX/oof/db94710445cbb206.png
https://emoji.slack-edge.com/T0XXXX/petrol/35ed3db238f795fc.png
https://emoji.slack-edge.com/T0XXXX/piggy/b7762ee8cd.png

We now understand how to collect everything we need, so let’s automate this a bit more.

The Implementation#

We’re going to write a little script that’ll download all the custom emojis from the target Slack workspace. It’s going to perform the following steps:

1. Define a starting JSON payload.
2. Create a run loop.
3. With each loop we make a request using the API endpoint.
4. Do some error checking.
5. Iterate through the results and save them to disk.
6. If the results contain a next_marker update the JSON payload with a marker field and continue the run loop.
7. Keep going until the last request no longer provides a next_marker.

First, we want to define some environmental variables so we can easily configure the script:

: ${SLACK_WORKSPACE_ID:=}
: ${SLACK_COOKIE:=}
: ${SLACK_TOKEN:=}

Now we define our JSON payload object. We use jq here to keep things easy. Not only is it great for parsing and filtering JSON in Bash, it also makes building and manipulating objects simple:

payload=$(
  jq -nc \
    --arg     token "${SLACK_TOKEN}" \
    --argjson count "100" \
    '{
      token: $token, 
      count: $count
    }'
)

Next, is the run loop where we make our API requests. This passes through the payload object we just defined while also targeting our workspace:

while true; do
  result=$(
    curl -s --compressed "https://edgeapi.slack.com/cache/${SLACK_WORKSPACE_ID}/emojis/list?fp=97" \
      -H "cookie: d=${SLACK_COOKIE};" \
      --data-raw "${payload}" 
  )
done

We obviously want to do some simple error checking so we know what we did wrong if the requests fail. Grab the error, spit it out and terminate the script.

if [[ $(echo "${result}" | jq -r ".ok") == false ]]; then
  echo "${result}" | jq -r ".error"
  exit 1
fi

We now start iterating through any of the results we got from the initial request. We really only care about the value field as the URL gives us all the pieces we need to give our emojis a human-readable filename.

Here we treat the resulting URL as a standard file path and use dirname paired with basename to get the name of the parent directory of the file. The parent directory holds the actual name of the emoji, while the file itself is only a random hash. We use Bash’s parameter expansion feature to construct our filename.

Finally, we download the remote file to the current directory:

echo "${result}"  | jq -r '.results[].value' | while read -r url; do 
name=$(basename $(dirname "${url}"))
curl -s -o "${name}.${url##*.}" "${url}"
done

We need to check if there are more results to page through, so let’s look for the marker_next field. If we can’t find one, then mission accomplished; all done. However, if we do get a value, we take the previous payload we constructed and add the marker field.

The next loop will pick this change up and pass it on through to the API request telling Slack to give us the next page of precious emojis.

marker=$(echo "${result}" | jq -r ".next_marker")
[[ "${marker}" == "null" ]] && exit 0

payload=$(echo "${payload}" | jq --arg marker "${marker}" '. + { marker: $marker }')

The Finished Product#

#!/usr/bin/env bash

set -eo pipefail

: ${SLACK_WORKSPACE_ID:=}
: ${SLACK_COOKIE:=}
: ${SLACK_TOKEN:=}

payload=$(
  jq -nc \
    --arg     token "${SLACK_TOKEN}" \
    --argjson count "100" \
    '{
      token: $token, 
      count: $count
    }'
)

while true; do
  result=$(
    curl -s --compressed "https://edgeapi.slack.com/cache/${SLACK_WORKSPACE_ID}/emojis/list?fp=97" \
      -H "cookie: d=${SLACK_COOKIE};" \
      --data-raw "${payload}" 
  )

  if [[ $(echo "${result}" | jq -r ".ok") == false ]]; then
    echo "${result}" | jq -r ".error"
    exit 1
  fi

  echo "${result}"  | jq -r '.results[].value' | while read -r url; do 
    name=$(basename $(dirname "${url}"))
    curl -s -o "${name}.${url##*.}" "${url}"
  done 

  marker=$(echo "${result}" | jq -r ".next_marker")
  [[ "${marker}" == "null" ]] && exit 0

  payload=$(echo "${payload}" | jq --arg marker "${marker}" '. + { marker: $marker }')
done

This is pretty much it. A barebones script that downloads all findings to its present working directory. To test it out yourself, make the script executable, define the environmental variables and fire it off like so:

$ SLACK_WORKSPACE_ID=*** SLACK_COOKIE=*** SLACK_TOKEN=*** ./fetch.sh

An Even Better Version!#

I know I just made you read through all this, but you also could’ve just downloaded the tool from here. It’s got heaps more bells and whistles ( if you’re into that sort of thing):

The Bitter Irony#

In typical bored engineer fashion, I’ve spent more time writing this article, documenting and publishing the code than I ever would have personally just “handraulically” doing this from time to time.

Hopefully, you’ve learned something new! 🤞

Bonus Relevant XKCD Image#

source: xkcd: automation