Skip to main content

Email preferences

Nuntiq sends partner-API recipients four kinds of email:

CategoryWhen it fires
Advance reminders60 and 30 days before a key's expires_at.
Imminent reminders7, 3, and 1 day before expires_at.
Key expired noticeOn the day expires_at passes.
Key issued noticeWhen a new key is minted on the account (does not contain the key).

Every notification email on a partner account receives all four categories by default. Each recipient can independently turn off any of them via a self-service preferences page.

The intent is to let teams that hate noise mute the long-lead reminders without losing the imminent ones, or to let an alert mailbox subscribe only to "key expired" while a Slack-bouncing inbox subscribes only to "key issued." The four toggles compose freely.

warning

You can mute every category. Doing so means a key can lapse with no email warning at all. The fallback in that case is the key_expired 401, which is loud in your integration log but only after something has already broken.

Where the page lives​

Every reminder email includes a "manage email preferences" link near the footer. Clicking it opens the supplier portal at https://<tenant>.apquery.com/supplier-access/email-preferences?token=....

The page is public — the token query parameter authenticates one specific (account, email) preference row and nothing else. There is no login, no API key. The token is opaque, 48 hex characters of CSPRNG output, minted once per recipient and stable across reminders.

The four toggles​

The page shows four switches with short descriptions:

  • Advance expiry reminders — reminder_advance. Early notice, 60 and 30 days before a key expires. Most teams keep this on.
  • Imminent expiry reminders — reminder_imminent. 7, 3, and 1 day before. Turning these off is risky on monthly keys, where the imminent tier is the only tier (no 30/60-day reminders fire for a 30-day key).
  • Key expired notice — reminder_expired. Day-0 warning. Hardest to argue for muting; this fires once and signals that something is already broken.
  • Key issued notice — key_issued. A new key was minted on the account. Useful for the AP team's audit eyes; useless for the bot mailbox that handles imminent reminders.

Programmatic access (token-authed)​

You normally never call these endpoints from your integration — they exist so the supplier-portal page can read and write preferences. But the API surface is documented in the reference and is callable if you want to script preference changes on behalf of a recipient who handed you their token.

# Read current preferences for one recipient.
curl "https://api.apreceiving.com/api/v1/partner/supplier-access/email-preferences?token=$TOKEN"

# Partial update (only the listed fields change).
curl -X POST https://api.apreceiving.com/api/v1/partner/supplier-access/email-preferences \
  -H "Content-Type: application/json" \
  -d "{ \"token\": \"$TOKEN\", \"preferences\": { \"reminder_imminent\": false } }"

The full schema lives in the API Reference.

How a suppressed reminder still counts​

When a reminder fires for a key but every recipient has opted out of that category, Nuntiq still records the milestone as handled — it inserts a supplier_api_key_reminders row with recipients=[] and moves on. The same milestone will not be evaluated again on the next run; nobody gets a flood when they re-enable a category.

This means: turning a category back on does not re-send the reminders you missed. You will get future reminders going forward, but the past ones are gone.

Categories vs. milestones​

The reminder categories (4) and the reminder milestones (up to 6 per key) are not the same axis:

Milestone     →  Category
60d           →  advance
30d           →  advance
7d            →  imminent
3d            →  imminent
1d            →  imminent
0d (expired)  →  expired

A 30-day-interval key only has the milestone set {7, 3, 1, 0} — so its reminders all fall under imminent or expired, never advance. Turning off advance on a recipient who only manages monthly keys silently does nothing useful.

What's not a preference​

  • The partner_access_invitation email (the initial magic link) always sends. It is part of the account onboarding flow, not a reminder.
  • The partner_access_code email (the 6-digit code) always sends — the partner explicitly asked for it by clicking "Send verification code" on the regen page.
  • Customer-side admin actions (a customer user revoking your key, triggering an invitation for a different recipient, etc.) do not fan out emails to you. The customer's own audit log captures those.