Developers

Dev module (@dashnex/dev)

@dashnex/dev connects your app with DashNex: installed by the redeploy after your first reservation, it writes every sale into Contacts, tags the buyer, emits dev.* events and adds a Module Installs block to the contact page.

What it is

@dashnex/dev connects your app with DashNex. It is installed by the app redeploy after your first name reservation.

It is hidden: it never shows in Available or Installed. Once installed, it stays in your app, and updates arrive automatically with the regular app system updates.

Sales into Contacts

On every install of one of your modules, @dashnex/dev writes to your Contacts module (@dashnex/contacts), the same way Offers records a purchase.

  1. The buyer is the business; its owner is the responsible party (team members don't matter). The owner's first name, last name and email come from DashNex ID. The contact is created for the owner, since a business's official email is rarely good for marketing.
  2. It finds or creates the contact by email (resolveContact). There is one contact per email, never a duplicate.
  3. A new contact is created as type customer. An existing contact is set to customer if it was a lead, and the new install record is added.
  4. It adds the module tag, which is the module address, for example marketing-101. A tag is unique per contact, so it is never added twice. contacts.tag_added fires, so you can start automations on it: Emails → Automations, trigger Tag added. See Automations.
  5. It emits dev.module_installed, dev.module_renewed, dev.module_refunded and dev.module_uninstalled (getEvents(), @dashnex/core) with the full record: module, version, business, owner, amount and billing, date. Use them to build your own reporting, customer overviews and more.

Events

EventWhen
dev.module_installedA business installs one of your modules
dev.module_renewedA recurring module renews
dev.module_refundedA buyer uninstalls within the refund window and is refunded, once their redeploy completes
dev.module_uninstalledThe module leaves a buyer's app without a refund, once their redeploy completes (or when a renewal lapses)

Each event carries the full record: module, version, business, owner, amount and billing, date. For what triggers a refund, see Sales, fees and refunds.

Module Installs widget

The contact page gets a Module Installs block, added through contacts.contact_get (as Offers adds Purchases). It is for support: when a buyer writes in, look them up in Contacts first.

There is one row per install, for every business of this contact that installed one of your modules:

  • The business name and its official email (Settings → General of that business). Support requests may come from it.
  • The module and the version last deployed on that business.
  • The install date and amount (price · billing).
  • The status: Installed, Refunded (refund date and amount) or Uninstalled.

The install records live in the dev module's own table, linked to the contact, like Offers' purchases. When you merge two contacts, their install records move too (contacts.contact_merge_get).

Related guides