Seeking beta feedback on iNatifier (by @cesar_stastny), an iNaturalist activity notification tool

[cesar_stastny]

Updated October 8, 2026 — current beta version 2026.10.08.145

Goal of the tool:

iNatifier is a small, free, non-commercial tool that provides a rich inbox for activity on an iNaturalist account, with optional push notifications for different kinds of activity.

It is intended to make it easier to notice, review, and keep track of iNaturalist activity, particularly for people who do a lot of identifications or follow many observations.

Niche it fills in the iNaturalist ecosystem:

I originally wanted a simple way to receive timely notifications of new iNaturalist activity on my phone and computer.

iNatifier has evolved into a more capable activity inbox that supplements the existing iNaturalist interfaces. It brings together activity on your own observations and observations you follow, with detailed filtering, configurable push notifications, and an independent read/unread state that stays synchronized across your devices.

It works in an ordinary web browser or can be installed as an app on mobile devices, with push notifications and Home Screen badges where supported.

Is there a commercial component, or do you plan to include one in the future? Are donations requested? (yes/no, explain):

No. iNatifier is free and non-commercial. I have no plans for a commercial component and am not requesting donations.

What sort of data (if any) does your app collect from its users?:

iNatifier uses iNaturalist OAuth to identify the user and read the account activity needed to provide the notification inbox.

It stores the iNaturalist account identity, a limited amount of notification/activity metadata needed for the inbox, and device information required to deliver push notifications. This includes things such as activity types and timestamps, observation references, usernames, and relevant comment excerpts.

It does not store the subjects or contents of private iNaturalist messages.

When you connect your account, authorization happens through iNaturalist. iNatifier never sees or stores your iNaturalist password. It retains an authorization token on its server so it can check for new activity on your behalf.

Users can disconnect their accounts and delete their stored iNatifier data. The iNaturalist application authorization must currently be revoked separately through iNaturalist’s account settings.

Link to your iNaturalist profile:

https://www.inaturalist.org/people/cesar_stastny

Description:

iNatifier periodically checks iNaturalist for new activity and presents it in a persistent, searchable-by-filter inbox organized into several sections:

• My Content — identifications, comments, faves, mentions, and other activity on your own observations.

• Others — activity on observations you follow or have participated in.

• Messages — notifications of new private messages, linking to the messages on iNaturalist.

• Followers — notifications when someone new follows you.

The inbox provides detailed filters for activity types, including identification relationships (Agree, Refine, Broaden, Disagree, and No ID Relation). It also recognizes mentions in comments, including edited comments, remarks accompanying identifications, and observation field activity.

Push notifications are optional and can be configured quite selectively. For example, you could choose to receive pushes only for messages, mentions, and disagreeing identifications, while still retaining everything else in the inbox. Multiple events detected together can be combined into a single push notification.

The frequency of checking for new activity is configurable: every 15 minutes, 30 minutes, hourly, or daily. iNatifier can also reduce its checking frequency during periods of inactivity to conserve iNaturalist API resources. An on-demand Refresh option is available, subject to a cooldown.

Activity can be marked read individually or in bulk. Read/unread state stays synchronized across devices within iNatifier, independently of iNaturalist’s own notification state. Notifications link directly to the relevant content on iNaturalist.

On mobile devices, iNatifier can be installed as a Progressive Web App (PWA), providing Home Screen access, push notifications, and notification badges where supported. On iOS, installation to the Home Screen is required for Web Push. The inbox also works in a regular browser without installation.

I have been developing and testing iNatifier with my own accounts and a small group of beta testers. Their suggestions have led to substantial improvements, particularly in handling activity on observations other than your own, identifying different kinds of identification activity, and controlling which events generate push notifications.

The beta remains invite-only while I continue evaluating reliability, onboarding, and API usage across different devices and browsers. The invitation requirement is not intended to be permanent.

Discussion questions or areas seeking feedback:

I’m especially interested in feedback about:

• whether the initial setup and iNaturalist authorization process are clear

• whether the browser-vs-installed-app distinction makes sense on mobile devices

• whether notifications arrive reliably and at useful times

• whether the inbox organization and detailed filters are useful in normal iNaturalist workflows

• whether the push notification settings and check frequency options are understandable

• whether using iNatifier across multiple devices works as expected

• anything that feels confusing, unnecessary, or missing

• good old-fashioned bugs

If anyone is interested in trying the beta, please reply here or send me an iNaturalist message and I can send you an invitation as capacity allows. I’m still keeping the beta relatively small while I monitor reliability and API usage.

Thanks to everyone who has already tried iNatifier or contributed suggestions. The feedback has made a real difference to the tool.

-cesar-

[lynkos]

Given the less than optimum handling of notifications on iNaturalist, this sounds interesting. I only use the web browser interface (Chrome), but if that could be useful, I’d be happy to give it a try.

[schoenitz]

One of the most useful features of a new notification workflow would be combining into a single notification multiple events (IDs, comments, @-mentions, field/project additions/edits, DQA votes, etc.) on the same content (in this context that’s things that resolve to one page, so: observations, flags, taxon swaps, journal entries, etc.). It’s not obvious if that’s part of what you’re proposing here, but if it is, I’d like to test drive.

[DianaStuder]

Sounds good.
Once it is set up, make a fresh Forum post ?

https://forum.inaturalist.org/t/inaturalist-enhancement-suite-chrome-extension-by-sessilefielder/75349
I have used this since it was first built for us. And have enjoyed steady improvements over time. Cannot imagine reverting to iNat without it !

Lots of profiles say – send a PM I ignore notifications

https://forum.inaturalist.org/t/management-of-notifications/60134/40 It is in the July to December 2026 product goals …

[cesar_stastny]

Invite sent.

[cesar_stastny]

schoenitz,

That is not how iNatifier works currently. It creates a separate notification for each ID, comment, or fave even if they all reference the same observation. Also, it currently only alerts on new identifications, comments, faves, or messages. In the future I am happy to look into the feasibility of adding other activity/event types as well as other ways to organize them as you mentioned.

If you would still like an invite, let me know.

-cesar-

[schoenitz]

Sure why not, might as well.

[cesar_stastny]

Invitation sent via iNaturalist Message.

-cesar-

[pisum]

@cesar_stastny

push notifications for new identifications, comments, faves, and messages.

what are the endpoints you’re hitting to get identifications / comments and faves? i’m trying to envision how you’re doing that while:

@cesar_stastny

Activity can be marked read and stays synchronized across devices.

synchronization would have to happen either on iNaturalist’s servers, which is possible for some of things that you’ve listed, but i don’t think is possible for all of it (unless i’m misunderstanding what you’re defining as identifications, comments, and faves). or else you must be storing at least some of this information on your own servers (unless you’re relying on, say, a Google account to sync some of that infromation)?

@cesar_stastny

iNatifier uses iNaturalist OAuth to identify the user and read the account activity needed to provide the notification inbox.

@cesar_stastny

On mobile devices it can be installed as an app, which enables push notifications and gives it a Home Screen icon with notification badges. It also works normally in a browser without installation.

i’m also curious about these two claims. in your browser-based thing, which OAuth flow are you using?

[schoenitz]

This seems to cover IDs and comments on my own observations. Those are a small minority of the notifications I get, I don’t really need help managing them. Can I include notifications for observations, etc. that I follow? They are the ones that need managing.

[cesar_stastny]

Hi @pisum. Good questions. By “stays synchronized across devices,” I mean within iNatifier. iNatifier maintains its own inbox and read/unread state on my server; it does not mark iNaturalist’s own notifications read. If you use iNatifier on two devices, both are looking at the same iNatifier account and therefore the same inbox/read state.

For identifications and comments, I’m polling the authenticated API endpoint:

GET /v1/observations/updates?observations_by=owner

using an iNaturalist API JWT. I page forward from a stored cursor and normalize the identification/comment activity into a small event record.

Faves are the awkward one. They aren’t exposed by the observation-updates API, so I’m currently using the older authenticated site endpoint:

GET /users/new_updates.json?resource_type=Observation&skip_view=true

and filtering the returned observation activity locally for the fave notifier (ActsAsVotable::Vote). skip_view=true is important because polling must not mark anything viewed at iNaturalist. This is the least robust part of the implementation because that feed only exposes unviewed activity, so I regard fave notification delivery as best-effort.

For completeness, messages come from the authenticated /messages.json endpoint. I intentionally do not retain message subjects or bodies.

iNatifier does store a normalized subset of activity on its own server because that’s what makes the persistent inbox and cross-device read state possible. For observation activity that is things like event type/time, observation ID, actor login, taxon name, up to 500 chars of comment text where applicable, thumbnail URL, and iNatifier’s read timestamp. I deliberately exclude coordinates, place text, observation descriptions, etc. For private messages I store IDs/timestamps and sender login needed to display and route the notification, but not the subject or message body. There is no Google or other third-party account involved in synchronization.

OAuth is the standard Authorization Code flow with a confidential server-side client. The browser is redirected to iNaturalist’s /oauth/authorize endpoint with response_type=code and a one-time state. iNaturalist returns the authorization code to iNatifier’s callback, and the iNatifier server exchanges that code at /oauth/token using the client ID/secret. The resulting OAuth access token stays server-side.

For API calls that require the newer API JWT, iNatifier uses that OAuth access token with /users/api_token and then uses the returned JWT against the /v1 API. The browser itself only gets an iNatifier session/remembered-device cookie; it never receives the iNaturalist OAuth token or JWT.

The OAuth state is short-lived, single-use, and tied to the browser session that initiated the flow.

iNatifier is a Progressive Web App (PWA), so the installed mobile app is the same web application running with a manifest and service worker rather than a separate native app. Where the browser/platform supports Web Push, the service worker handles push notifications; on iOS, push requires iNatifier to be installed to the Home Screen.

So the basic architecture is: iNaturalist remains the source of the activity, while iNatifier keeps a deliberately small server-side representation of that activity plus its own read state so the inbox can work consistently across devices.

[cesar_stastny]

Hi @schoenitz - Right now I deliberately restrict identification/comment activity to “My observations” because that matches my workflow - that is what I needed most from iNatifier for my own use. But what you are requesting seems a natural next step.

iNaturalist’s notification system has the concept of subscriptions to observations, including observations you explicitly follow or become subscribed to through interaction. The observation-updates API appears to support retrieving activity for those followed observations as a separate stream.

So I’m going to investigate adding something like a Following scope alongside the current My observations activity. I’d want to keep them distinguishable rather than simply flooding the existing inbox, particularly for users who follow a lot of observations.

Your earlier suggestion about grouping multiple events on the same observation also makes more sense to me in that context. I’d probably first get followed-observation activity functional before I consider how grouping could work.

So: iNatifier can’t do what you’re asking today, but I think it may be a very reasonable direction to explore.

[pisum]

thanks for the detailed explanation. i suspected your thing was constructed this way, but i just wanted to make sure.

based on your desciption, it seems like the two unique things that your thing does vs the mobile apps then are:

1. push notifications
2. fave notifications

additionally, it categorizes identifications and comments in two separate streams (vs one).

however, your thing does not provide updates on observations that that are not yours, whereas the mobile apps do.
…

i’m not suggesting that you’re not handling things securely and privately, but i would just caution folks that do use your app and stop using it to also go to their iNat account settings and explicitly revoke access for your app. if they don’t, the access tokens stored on your servers could still remain active indefinitely.
…

@schoenitz

Can I include notifications for observations, etc. that I follow?

assuming you want a web-based interface and you don’t need push notifications, you could use something i made a few years back: https://forum.inaturalist.org/t/is-there-an-easy-way-to-open-all-notifications/25913/35.

it provides information similar to what the mobile apps provide in their activity feeds (identifications + comments), but this one provides a little more detail, and it can combine updates for your observations and others’ observations in a single stream (although mentions on other’s observations have to be retrieved by explicitly looking for others’ observations).

it was a quick and dirty project, made back when there was hope that a notifications revamp would come soon. five years later, it looks like we’re now about one more year away from an actual revamp:

@DianaStuder

https://forum.inaturalist.org/t/management-of-notifications/60134/40 It is in the July to December 2026 product goals …

[cesar_stastny]

@pisum That’s a good point about revocation. You’re correct that signing out of iNatifier currently only signs that browser/device out of iNatifier; it does not revoke the underlying iNaturalist OAuth authorization, because iNatifier needs that authorization to continue checking the account in the background.

If someone stops using iNatifier today, they should revoke iNatifier from their iNaturalist account settings. I plan to add a proper “disconnect/delete my iNatifier account” function that removes the account data on the iNatifier side and, if possible, revokes the OAuth authorization at iNaturalist as part of the same operation. But that feature is not in the Beta at this point.

And yes, your summary of the current scope is basically right. One other distinction is that iNatifier maintains its own persistent inbox/read state across devices. It currently notifies on IDs, comments, and faves on the user’s observations - and messages too. With separate streams for each. The discussion here has already made me interested in expanding it to activity on observations the user follows as well.

[pisum]

@cesar_stastny

One other distinction is that iNatifier maintains its own persistent inbox/read state across devices.

ok. i figured that was the case for the faves, but i didn’t think too deeply about whether you would keep track of this on your end for identifications and comments and messages. when you view an observation, iNat itself should mark any associated updates as viewed, and i think there’s a similar mechanism for messages. so i’m not sure that you need to keep track of that on your end. suppose you get an identification notification on observation A. then outside of your app, you open up observation A. when you go to your app, is the identification notification still marked as unread? is there still a little push notification indicator on the app?

@cesar_stastny

and messages too

yes, as i recall, both the website and the apps do also have messages functionality. so besides the push notifications (and maybe independent tracking of read state?) that your thing provides, i’m not sure what additional functionality is provided by your app for messages.

[cesar_stastny]

AFAIK there is no message support in the iOS app. I could be wrong - Is there a way to see messages in the app?

[pisum]

@cesar_stastny

AFAIK there is no message support in the iOS app. I could be wrong

you might be right. i know there were plans to add that functionality, and i thought that since they’re beta testing the new app on Android, i assumed that the messages must have been implemented at this point to at least have feature parity with the existing Android app, but that may be a bad assumption.

[cesar_stastny]

@pisum iNatifier maintains its own read/unread state rather than trying to mirror iNaturalist’s viewed state. I did that deliberately and that model works well for me. But I can understand that some folks might have a different expectation. It may be worth investigating whether iNatifier can also observe iNaturalist’s viewed state and reconcile the two without causing undesired issues, spamming the iNat API, etc.

On messages: it looks like the old Android app had private messaging, but the newer iNaturalist Next app does not have message support AFAIK (I do not have Android); it was described as a planned future feature. The iOS app historically did not have messages, either old or new versions.

So for me, iNatifier’s message value is that it can alert me that a message arrived and gives me one place to see that alongside my other activity. If you click a message notification in iNatifier the actual message opens on the iNaturalist website.

[cesar_stastny]

A quick update on iNatifier, and a thank-you to everyone who tried it and commented here so far.

The feedback in this thread has been very helpful. Several of the issues people raised turned into fairly major additions rather than just small fixes.

The biggest change is that iNatifier now has an Others section. It can notify you about new activity on observations you follow, not just activity on your own observations. That was an important omission in the original beta, especially for people who contribute a lot identifications on other people’s observations.

I’ve also added notification bundling. If several new iNaturalist events arrive during the same polling cycle, iNatifier now sends one summarized notification instead of several individual pushes. The events still appear separately in the inbox so you can examine each individually.

There is also now a proper account/profile menu and a Disconnect from iNatifier function. Disconnecting stops notifications, signs you out on all devices, and deletes the account data and credentials stored by iNatifier. At the moment, the iNaturalist authorization entry still needs to be removed manually under iNaturalist Account Settings → External Applications; I’m still looking into whether iNaturalist provides a supported way for an app to remove its own authorization programmatically.

A number of smaller usability and reliability changes have gone in as well, including better unread indicators, improved filtering and navigation, backend improvements, and quite a bit general polish throughout the app.

If you considered or tried iNatifier earlier but the lack of notifications about activity on other people’s observations made it less useful to you, I’d especially be interested in hearing what you think of it now.

Thanks again to everyone who has tested it or offered suggestions. The app is substantially better because of the feedback here.

[pfau_tarleton]

@cesar_stastny

For private messages I store IDs/timestamps and sender login needed to display and route the notification, but not the subject or message body.

Is it possible that, at some future time, you could change the code to allow access of private messages without users knowing?