PII, PURLs & Access Tokens — what's changing and what you need to do

Raisely is making two connected changes to how personalized and login links work, effective 7 October 2026.

1. Personal information is being removed from URLs. Names, email addresses, and supporter IDs will no longer be passed directly inside a link.
2. Access tokens now expire and are single-use. Login links no longer work forever.

Overview

Why we're making these changes

URLs are not private. Personal data in a URL can end up in browser history, server logs, analytics tools, and third-party systems — often without anyone noticing. And login links that never expired created a long-tail security risk: if an old link was forwarded or leaked, it could grant account access indefinitely.

These changes remove both risks.

What was the old state

Personal information in URLs

Previously, personal information could be passed directly inside a URL as a query parameter. For example:

https://example.raisely.com/dashboard?firstName=Jane&email=jane@example.com

This made personalization straightforward but exposed supporter data through:

• Browser history
• Server logs and analytics tools
• Forwarded emails and shared links
• Security scanners
• Third-party tools receiving the URL without your knowledge

Access tokens

Access tokens let Raisely log a supporter in without a password. Under the old model:

• Tokens never expired
• Tokens could be reused indefinitely
• Tokens could be copied from report/export columns, webhooks, or manual copy-paste and stored or forwarded

If a token ended up in an old email, a CRM export, or a leaked log, it could grant account access for months or years.

What is the new state

Personal information in URLs

Personal information must no longer be placed directly in a URL. Instead, links carry an access token — a random string with no readable personal data.

Here's what this looks like in practice. Previously, a personalized link might have looked like this:

https://example.raisely.com/dashboard?firstName=Jane&email=jane@example.com

With the new model, the same link looks like this — carrying only the access token, with no personal data visible:

https://example.raisely.com/dashboard?access_token=eyJhbGci0iJIUzI1NiIsInR5cCI6IkpXVCJ9

The token is a randomly generated string. It contains no names, emails, or any other personal information — it simply tells Raisely who to look up securely on the server side.

When a supporter clicks the link:

1. Raisely validates the token
2. Raisely authenticates the supporter
3. Raisely opens a secure session
4. Personalization is drawn from that session — not from the URL

Raisely email templates will block saving if they contain personal data merge fields inside a URL.

Access tokens

• Tokens now expire based on your organization's setting: 48 hours (default) / 7 days / 30 days / 6 months
• Tokens are single-use — once clicked, the same token cannot be used again
• Generating a new token does not invalidate old unused tokens — they become invalid only when used or expired
• If a supporter clicks an expired or already-used link, they are guided through a request-a-fresh-link flow — they are not stranded
• If you send links from outside Raisely, you can generate fresh tokens via the Raisely API

How this affects specific workflows

Using access tokens in an external CRM (e.g. Salesforce, HubSpot, Ortto)

Old workflow:

1. Run a report or export from Raisely and copy the access token column
2. Upload the token into your CRM or email tool
3. Build a personalized link using that static token and send
4. Reuse the same token for follow-up emails or re-engagement sends months later

New workflow:

1. Set up a backend integration that calls the Raisely token-generation API at send time
2. Request a fresh token for each supporter when the send is triggered
3. Raisely returns a unique, expiring, single-use token
4. Build the personalized link using only the token — no personal data in the URL
5. Pass the link to your CRM/ESP and send
6. If the supporter hasn't clicked within the expiry window, they are guided to request a fresh link

What breaks if you don't update:

• Tokens pulled from reports/exports will expire and stop working
• After 7 October 2026, the access token column will be removed from report/export outputs entirely
• Static tokens stored in your CRM will become invalid
• Re-engagement campaigns that reuse old tokens will fail

Action required: Replace report/export token workflows with API-generated tokens before 7 October 2026.

Developer documentation:

• Batch token generation endpoint — generate tokens for multiple supporters in a single API call
• Single token generation endpoint — generate a token for one supporter at a time

Using access tokens to personalise a Raisely page (e.g. fundraiser dashboard)

Old workflow:

1. Raisely sends a fundraiser their dashboard link, which may include their name, email, or token in the URL
2. The fundraiser bookmarks the link or returns to it from their original welcome email
3. Because the token never expired, the same link worked indefinitely

New workflow:

1. Raisely sends the fundraiser a dashboard link containing only an access token — no personal data
2. When clicked, Raisely authenticates them, opens a session, and displays their personalized dashboard
3. After clicking, the token is consumed and the link no longer works
4. If the fundraiser tries the link later (or if it has expired), they are guided to request a fresh link to their inbox
5. If you send P2P fundraiser links via an external email system, you must call the Raisely API to generate fresh tokens for each send

How page personalization changes:

Previously, page merge fields read values directly from the URL — for example query.firstName and query.lastName from parameters like ?firstName=Jane&lastName=Smith.

With the new model, personalization is driven by the authenticated session. Once a supporter is logged in via their access token, use standard user merge fields instead:

user.firstName
user.lastName

If the supporter is not logged in, user merge fields will be blank. To handle this gracefully, use a conditional fallback:

{{#if user.firstName}} Welcome user.firstName!
{{else}} Welcome!
{{/if}}

What breaks if you don't update:

• Fundraisers who try to reuse a clicked link will find it no longer works (they are guided to request a new one)
• External P2P email journeys using a single stored link will fail after first use or expiry

Action required: Ensure fundraiser email journeys use Raisely-sent tokenized links, or move to the API if you send from an external system.

See Default Messages Explained

Mailchimp / Campaign Monitor / Customer.io/External Marketing Tool for donor communications

Old workflow: Export a token from Raisely once, store it as a merge field, and insert it into every email — including re-sends, automations, and anniversary campaigns.

New workflow: Call the Raisely API to generate a fresh token at the time each email is triggered. Do not store or reuse the token across sends. Include only the token in the link — no names, emails, or supporter IDs in the URL.

Action required: Audit any active automations that contain stored access tokens and rebuild them using API-generated tokens.

Developer documentation:

• Batch token generation endpoint — generate tokens for multiple supporters in a single API call
• Single token generation endpoint — generate a token for one supporter at a time

Direct mail and QR codes

Old workflow: Generate a personalized URL well in advance and print it or encode it as a QR code. The link stayed valid indefinitely.

New workflow:

• Generate tokens as close to print/send time as possible
• Choose an expiry window that covers the life of the mailing (e.g. 30-day or 6-month window)
• A used token cannot be reused — supporters who have clicked will need a fresh link
• Test the expired-link experience before printing at scale

Action required: Factor token expiry into your print production timeline. Avoid printing links months before the mailing date.

Raisely email templates with personal data merge fields in URLs

Old workflow: Some templates used merge fields like firstName or email inside a URL to pre-fill or personalize destination pages.

New workflow:

• Raisely will block saving any template that includes personal data merge fields inside a URL
• Personalization should come from the supporter's authenticated session — not the URL
• Personal data merge fields can still be used freely in email body copy

Action required: Review your active Raisely email templates and remove personal data from any URL parameters before 7 October 2026.

Recurring giving and donor portal welcome links

Old workflow: The welcome email for a new recurring donor contained a login link that worked indefinitely — donors could return to it months later.

New workflow:

• The login link in the welcome email works as normal on first click, for the duration of your configured expiry
• If a donor tries to use the link after expiry or after already clicking it, they are guided to request a fresh link
• We recommend adding a visible "log in" or "access my account" option to your campaign site as a reliable ongoing access path

Action required: Consider adding a visible login option to your campaign site. Make sure your support team is familiar with the request-a-fresh-link flow.

See Settings: Adding Navigation Menu

Webhook-delivered tokens piped into external tools

Old workflow: Some customers captured access tokens delivered in Raisely webhooks and stored them for later sends.

New workflow: Webhook-delivered tokens will expire and can only be used once. Use the Raisely API to generate tokens at send time — not in bulk in advance.

Action required: Audit any webhook-based token workflows and migrate to API token generation.

Developer documentation:

• Batch token generation endpoint — generate tokens for multiple supporters in a single API call
• Single token generation endpoint — generate a token for one supporter at a time

Summary — what to do before 7 October 2026

What you do NOT need to do

• Remove merge fields from email body copy
• Remove non-personal tracking parameters (UTM tags etc.)
• Rebuild hosted Raisely forms that don't use personal data in URLs
• Build an API integration if you only use Raisely's built-in email tools
• Worry if a supporter clicks an old link — they will be guided to request a fresh one

Need help?

Contact Raisely Support if you:

• Are unsure whether your workflow uses stored or reused access tokens
• Need help identifying personal data in your URL templates
• Want guidance on migrating to API token generation
• Have a custom integration or partner-built portal and want a technical review before the deadline