Skip to content

Disconnecting and what happens after

You can switch us off at any time, and our access ends right away. Your data stays in your account either way: disconnecting removes our access, never your tables, buckets or archive.

Set the template’s Disconnect parameter to true and update the stack. In the CloudFormation console: select the stack, Update, Use existing template, set Disconnect Rhino Relay to true, and finish the update. Or with the AWS CLI:

Terminal window
aws cloudformation update-stack --stack-name rhino-relay --use-previous-template \
--capabilities CAPABILITY_NAMED_IAM \
--parameters ParameterKey=TenantId,UsePreviousValue=true ParameterKey=ExternalId,UsePreviousValue=true \
ParameterKey=SendingDomain,UsePreviousValue=true ParameterKey=ArchiveRetentionDays,UsePreviousValue=true \
ParameterKey=KmsKeyArn,UsePreviousValue=true ParameterKey=CreateTrail,UsePreviousValue=true \
ParameterKey=DataEvents,UsePreviousValue=true ParameterKey=Disconnect,ParameterValue=true

That one update removes every grant to our account:

  • The access role’s trust in our account. The trust policy is replaced by one that trusts only your own account, so we can’t open a new session from that moment.
  • The access role’s permission policy. It’s deleted, so sessions we’d already opened lose their permissions as well.
  • The forwarding rules, ForwardRule and UploadsRule, and their role. Your SES events and CSV upload notices stop reaching our event bus. ArchiveRule stays, so your own archive keeps every event.

How fast it takes effect. We can’t open a new session once the stack update finishes. A session we opened before then isn’t ended by the update: an AWS session lasts until it expires, at most an hour after it was opened. It does lose its permissions once IAM applies the deleted permission policy, usually within minutes, because permissions are checked on every call. To end those sessions at once as well, open the role rhino-relay-access-<TenantId> in IAM and choose Revoke active sessions.

If you use your own KMS key, the key-policy statement you added lets only EventBridge in your own account use it, so you can leave it or remove it.

Deleting the stack also switches us off. Tables and buckets are kept when the stack is deleted, so your data stays either way.

Check it worked: the stack’s Disconnected output shows true, and /health shows tenantState disconnected.

Terminal window
curl "$BASE/health" -H "Authorization: Bearer $KEY"
  • Sending stops at once. Campaigns in progress stop, and every request that needs your account returns 409 tenant_disconnected.
  • Work already waiting on our queues is dropped. Those messages are IDs only, and our functions drop any work for a disconnected account.
  • Unsubscribe links can’t reach your data any more. Anyone who clicks one sees that we couldn’t process it, and your contact address so they can reach you. You’re responsible for honouring unsubscribes while you’re disconnected, so consider disconnecting only between campaigns.
  • After 30 days we delete your account’s registry entry, apart from billing records we must keep. We never held your contacts, so there’s nothing else to delete or return.
  • Your data stays in your account for you to keep, move or delete: the tables, buckets, archive and trail are untouched.

To reconnect within those 30 days, set Disconnect back to false, update the stack, and click Verify in the console, or verify through the API:

Terminal window
curl -X POST "$BASE/setup/verify" -H "Authorization: Bearer $KEY"

Check it worked: the response is your /health, with the connection check showing "ok": true.

If your subscription ends and isn’t renewed:

  1. Grace period, 30 days. Everything keeps working.
  2. Read-only, 90 days. New campaigns and imports return 402 entitlement_inactive. Unsubscribe links, erasure, exports and reads keep working, which covers the legal minimum for unsubscribe links in emails you’ve sent.
  3. Disconnected, as above: we stop all work for your account, and delete the registry entry 30 days later. Your stack still grants access until you set Disconnect to true or delete it, and we recommend you do.

Renew at any point before step 3 to carry on as before.

Once you’ve disconnected and don’t plan to come back, delete the stack. Then delete the retained tables and buckets yourself if you don’t want to keep the data. If you’d like CSV files of your contacts and send history, export them before you disconnect: the export API needs the connection.