Update the pokemonSync flow
Update the pokemonSync flow so each tenant’s daily Slack message uses the selected Pokémon type and Slack user from dynamic configs, while still advancing IDs via tenant metadata.
You have access to the newly created slack_user and pokemon_type configs. Let's update pokemonSync to make use of them.
The Pokémon Trainer Academy needs the new pokemonSync to do the following:
The Pokémon of the day must always be of the type selected in the tenant's connection settings.
The Slack message should only be sent to the Slack user specified in the tenant's connection settings.
To do this we will need to:
You just saved a Pokémon type and a Slack user in your tenant's connection settings, and the CLI passes those selections to local runs.
Run
pandium local build && pandium local run <tenant-id>. The tenant configs at the top of the logs should now hold your selections:
[2026-09-08 11:30:26:118] [index] INFO: Tenant configs: {"pokemon_type":"rock","slack_user":"<YOUR-SLACK-MEMBER-ID>"}Fetch the selected Pokémon type by doing the following:
The pokemonSync.ts file should look something like this:
Run
pandium local build && pandium local run <tenant-id>.
You should get a Pokémon Slack message, but we're more interested in examining the logs; they should look something like this:
You can remove the logger.info(pokemonType)
You can learn about the shape of a Pokémon type by examining the one you just logged out or reviewing the PokéAPI docs for the type endpoint.
You'll see that each Pokémon type has the property pokemon; it's an array of the type's Pokémon. We should select the Pokémon of the day from that list!
Each member of the pokemon array has the following shape:
Change how
nextPokemonIdis defined; it should be the ID of the first member of the fetched type'spokemonarray whose ID is greater thanlastPokemonId.
Here is one way you could do this:
Run
pandium local build && pandium local run <tenant-id>.
This time the Pokémon in your Slack message should be of the type you selected, and the ID in the standard out will have jumped ahead to it. Because local runs don't update the tenant's metadata, running again will send the same Pokémon; you'll see the ID advance when you run on Pandium.
Now adjust pokemonSync to use the slack_user config
Your pokemonSync.ts could look like this now:
Run
pandium local build && pandium local run <tenant-id>.
Once again, this run's results should look the same as the last run's. This shows that accessing the Slack user's ID from the tenant's configs, instead of a hardcoded list, does not interfere with the rest of the flow's functionality.
Your pokemonSync.ts should match this one. In fact your integration files should match all the ones in this repository.
The final step is to see what this all looks like when it is run on Pandium!
Last updated
Was this helpful?