Troubleshooting

• Confirm you are checking the same email address you used to sign up.
• Check spam or quarantine folders.
• Try signing in again after clicking the verification link.

Admin is only available to the account owner. No other role or access level grants it. Ask the owner to perform admin tasks such as connecting providers.

• Confirm the provider was created in Admin → Integrations.
• Confirm the provider supports the block type you are configuring, such as Email or Text Message.

• Confirm the contact exists in Contacts.
• Confirm the flow is saved and has no blocking validation errors.
• Use a test contact first so you can safely retry.

• Open the validation or errors area.
• Select the block named in the error.
• Complete missing provider, template, timing, or condition fields, then save again.

Your account does not currently have an active subscription. Choose a plan to continue. If you just completed checkout, wait a moment and refresh if the dashboard does not update.

Flow editor routes require an active subscription. Confirm that your account has a plan selected.

Admin appears only for account owners in the current app shell. If you need access, ask the account owner to make the change or perform the admin task.

Empty states are expected for new accounts. For example, Flows may show no flows yet, Stats may show no messages or enrollments yet, and History may show no events recorded yet.

Protected dashboard routes require an active sign-in session. Sign in again to continue.

• Confirm the provider was created under Admin → Integrations.
• Confirm the provider type matches the block type you are configuring.
• Refresh the page after saving a new provider if the block was already open.

• Check the provider account credentials, OAuth permissions, API key, app password, webhook signing key, or selected phone/messaging resource, depending on the provider type.
• For OAuth providers, reconnect the account if authorization expired or was revoked.
• For API-key providers, create a fresh key in the provider console if the existing key may be invalid, then save or verify the provider again.
• For webhook providers, use Configure Webhook when auto-configuration is available, or copy the webhook URL into the provider console and then use Verify Webhook.
• For AI providers, use Verify API Key and confirm the account has access to the selected model.

• Check History for send errors.
• Confirm the provider account is active and allowed to send through the selected channel.
• Use a test contact before enrolling real contacts.

• Confirm you are signing in with the intended Google account.
• Retry the connection from Admin → Integrations.
• If authorization was revoked, reconnect the Gmail provider.

• Confirm the username matches the Gmail account that created the app password.
• Generate a new app password if the old one was copied incorrectly or revoked.

• Confirm the Gmail provider exists under Admin → Integrations.
• Confirm you are configuring an email block, not an SMS or AI block.
• Refresh the Flow Editor if the provider was created in another tab.

• Check History for the send error.
• Confirm the connected Google account is still active and authorized.
• Test with a contact you control before sending to real contacts.

• If the popup closes early or authorization is denied, restart the OAuth flow and complete the Microsoft consent step again.
• If the provider shows an expired authorization state, use Reconnect to refresh mailbox access.
• If OAuth succeeds but inbound setup fails, check whether Microsoft Graph mailbox notifications are allowed for the account and whether the connected mailbox still has valid access.

• If save or send fails, confirm you used an app password rather than the normal account password.
• If you cannot create an app password, verify that two-step verification is enabled and that your Microsoft account or tenant still permits app passwords.
• If the mailbox address is wrong, update it to the exact Microsoft mailbox that should send from Drip Drop.

• If replies do not appear, verify the provider was connected with OAuth and that the Outlook inbox subscription is active.
• If the inbound status looks expired or not configured, retry setup from the provider form.
• If a reply reaches the mailbox but is not linked to the expected outbound message, test again with a fresh Drip Drop send so the message threading headers are present.

• If saving works but webhook configuration fails, check whether the API key has the correct Event Webhooks or Inbound Parse permissions.
• If sending fails, confirm Mail Send has full access and the API key is still valid.

• If the webhook cannot be verified, compare the URL in SendGrid with the URL shown in Drip Drop.
• If signed webhook validation fails, confirm the verification key was saved and that SendGrid is actually sending signed requests.
• If verification looks manual or delayed, send a test event and check again after SendGrid has delivered traffic.

• If opens are missing, confirm Track Opens is enabled in the provider settings and that you are expecting SendGrid event tracking rather than only internal tracking.
• If clicks are missing, confirm Track Clicks is enabled and that messages are using links that SendGrid can track.

• If replies never appear, verify the Parse Hostname is configured in SendGrid and that the required MX or DNS routing is in place for that hostname.
• If Inbound Parse is enabled in Drip Drop but not configured in SendGrid, complete the manual provider-side setup.
• If replies arrive but do not match the expected outbound message, test again with a fresh send so the tracking headers are present.

• If setup fails immediately, confirm the Mailgun API key is valid and has access to the intended account/domain context.
• If sending fails, confirm the sender domain is set and matches the Mailgun domain you intend to use.
• If the wrong domain was entered, update it before debugging webhook or route behavior.

• If not all events are arriving, check whether every needed event type is configured on the Mailgun domain.
• If another set of webhook URLs is already present, review how many URLs are already attached for that event type.
• If signed validation fails, confirm the webhook signing key is saved and that Mailgun is sending the expected token, timestamp, and signature fields.

• If opens are missing, confirm Track Opens is enabled and that you are expecting Mailgun event tracking rather than only internal tracking.
• If clicks are missing, confirm Track Clicks is enabled and that the messages are using links Mailgun can track.

• If replies never appear, verify the parse domain is configured correctly and that MX or DNS routing for that hostname points to Mailgun.
• If the route exists but forwards to the wrong URL, update the forward action to the Drip Drop inbound endpoint.
• If replies arrive but do not match the expected outbound message, test again with a fresh send so the tracking headers are present.

• If the provider cannot connect, confirm the Account SID and Auth Token are correct.
• If no phone numbers appear, make sure the Twilio account actually owns a compatible number.
• If the wrong number was selected, choose the exact number that should send and receive messages for Drip Drop.

• If Drip Drop reports a conflict, check whether the number already points to another webhook URL in Twilio.
• If inbound messages or status updates do not appear, verify the webhook URL and callback settings on the Twilio number.
• If signed validation fails, check whether the saved auth token still matches the Twilio account sending the webhook.

• If messages send but replies do not appear, test the inbound webhook path with a real SMS to the configured Twilio number.
• If status updates are missing, verify the status callback is pointed at Drip Drop as expected.

• If the provider cannot connect, confirm the API key and public key are correct.
• If no messaging profiles appear, make sure the Telnyx account has accessible profiles and that the API key can list them.
• If the wrong profile was selected, switch to the one that should own inbound and outbound messaging for Drip Drop.

• If Drip Drop reports a conflict, check whether the selected messaging profile already points to another webhook URL.
• If inbound messages or status events do not appear, verify the webhook URL on the selected messaging profile in Telnyx.
• If signed validation fails, confirm the saved public key matches the Telnyx account sending the webhook.

• If messages send but replies do not appear, test the inbound webhook path with a real SMS through the selected profile.
• If sending fails only on one profile, confirm that profile is configured for the numbers or traffic you expect.

• If the provider does not validate, confirm the Anthropic API key is correct and still active.
• If the key looks right but access still fails, check whether the Anthropic account or workspace has billing or access restrictions.

• If no models appear, confirm the provider validated successfully and the Anthropic account has access to model listing.
• If the expected model is missing, it may not be enabled for that Anthropic account or it may have been renamed or retired.
• If a saved model later stops working, choose a different available model and retry the action.

• If AI actions fail intermittently, Anthropic rate limits or temporary service issues may be the cause.
• If the provider returns permission or bad-request errors, re-check the API key and selected model rather than treating it like a generic network problem.

• If the provider does not validate, confirm the OpenAI API key is correct and still active.
• If the key looks right but access still fails, check whether the OpenAI account has billing, quota, or permission restrictions.

• If no models appear, confirm the provider validated successfully and the OpenAI account can list models.
• If the expected model is missing, remember that Drip Drop only shows supported chat-capable model families in this picker.
• If a saved model later stops working, choose a different available model and retry the action.

• If AI actions fail intermittently, OpenAI rate limits, quota issues, or temporary service problems may be the cause.
• If the provider returns a bad-request or permission error, re-check the selected model and API access rather than treating it like a generic network problem.

• API key rejected: create or copy a current key from OpenRouter and check that the account can access the API.

• Model missing: refresh the provider model list later; availability is filtered and cached, and the OpenRouter account may not expose every model.

• Request denied or out of credits: review OpenRouter permissions, credits, limits, and model availability.
• Requests time out or fail temporarily: retry after checking OpenRouter service status and the provider’s returned error.

• Credentials rejected: verify the API Key ID and API Secret Key in Sendblue Dashboard and save them again.
• No line appears: confirm the Sendblue account has an available line and that the credentials can list it.

• Inbound messages do not arrive: verify the receive webhook is enabled and the provider shows inbound as configured.
• Webhook rejected: check that the saved Webhook Secret matches the sb-signing-secret value sent by Sendblue.

• Delivery status is missing: confirm the provider is sending status callbacks and review the message event in Drip Drop.

• If sending fails, check the SMTP host, port, username, and password first.
• If authentication fails, verify whether the mailbox provider requires an app password instead of the normal account password.
• If the mailbox provider expects SSL or TLS settings outside the defaults, update the provider settings to match.

• If replies never appear, confirm Enable IMAP is on and that the IMAP host and port are correct.
• If the mailbox is reachable but replies still do not appear, check the folder setting and any archive behavior that may move messages unexpectedly.
• If SSL or TLS is mismatched, IMAP can fail even when the mailbox credentials are correct.

• If a reply reaches the mailbox but is not linked to the expected outbound message, test again with a fresh Drip Drop send so the reply headers are present.
• If the mailbox receives many unrelated messages from the same sender, fallback matching may not behave the way you expect without clean reply headers.

• Confirm the file is a CSV; other file types are not accepted.
• Confirm the required first_name column is present.
• Check that email and phone values are in valid formats, then review any field-level or server validation messages.

• Add at least one email address or phone number.
• Fix any field-level validation messages.
• Check required custom fields if your workspace uses them.

• Select one or more contact rows first; the Add to flow dropdown is hidden until contacts are selected.
• Confirm a flow exists and is available for enrollment. If the flow was just created, refresh the Contacts page and try again.
• If enrollment fails, confirm the selected contacts have the channel required by the flow blocks, such as an email address for email steps or a phone number for text-message steps.

• Clear search, type, status, or tag filters.
• Confirm you are in the correct workspace.

• Confirm the template type matches the block type.
• Check whether the template status needs to be Active for the place you are selecting it.
• Refresh the flow editor if the template was created in another tab.

• Check the variable spelling and braces.
• Confirm the contact or custom field has a value.
• Preview with sample contact data before sending.

• Confirm an AI provider is connected if your workspace uses AI-assisted template writing.
• Check Settings for AI enablement and Admin → Integrations for ChatGPT or Claude provider setup, depending on your workspace configuration.

Only providers that support the required channel or method are offered. Connect providers in Settings or Integrations, then return to the template.

Check for:

• Flow limit issues
• Duplicate flow name
• Invalid provider or sender
• Invalid Notify recipients
• Archived or incompatible custom fields
• Missing required template choices

This is expected when provider, sender, message template, custom field, or recipient data was skipped. Open the block in the Flow Editor and complete the missing fields.

If Billing displays No Subscription, select a plan and complete checkout. Refresh the page after returning to DripDrop.

Confirm that:

• You are the account owner.
• Your subscription is not past due, canceled, or incomplete.
• The selected plan is available to your account.
• You are not selecting your current plan.

If you have an outstanding balance, select Manage Billing, resolve it in Stripe, then return to DripDrop and try again.

The Manage Billing option becomes available after billing has been set up for the account. Only the account owner can manage the subscription.

Add a payment method when prompted, or select Manage Billing to update your default payment method. Then return to Dashboard → Settings → Billing, select Change Plan, and try the upgrade again.

Downgrades take effect at the end of the current billing period. You can continue using your existing plan until the effective date displayed on the Billing page.

Select Keep current plan before the scheduled effective date.

Return to Dashboard → Settings → Billing and select the plan again. If checkout still doesn’t open, refresh the page and retry.

Review the usage amount and reset time. You can reduce usage, wait for the period to reset, or upgrade to a plan with higher limits.

Refresh the Billing page. If the information remains outdated, open Manage Billing to confirm the subscription status in Stripe, then return to DripDrop.

Refresh the page and try again. If the problem continues, contact support and include any error message displayed.

Refresh the page and try again. If the issue continues, check whether the problem is isolated to one tab or affects the whole settings area.

Reopen the tab and confirm the updated value persisted. For Account timezone, make sure you chose a timezone from the dropdown and clicked Save.

Be careful before removing the last working authentication method or trusted device. Generate backup codes after MFA is enabled and store them somewhere safe.

If the raw key is no longer visible, create a new key and revoke the old one instead of expecting Drip Drop to reveal the old secret again.

1. The key was copied correctly.
2. The key has not expired.
3. The key was not revoked.
4. The account is active.
5. The account subscription is active.
6. The request uses the X-API-Key header.
7. The request is sent to https://api.dripdrop.dev.
8. The endpoint, method, and payload match the live API docs.

• Confirm you are signed in to the correct account.
• The current dashboard UI only adds Admin navigation for the account owner.
• Ask the account owner or support to confirm your expected access.

• Opening /dashboard/admin should redirect to /dashboard/admin/integrations.
• If the redirect fails, try a direct child route such as /dashboard/admin/custom-fields.

• Use Try Again if the page shows Error loading integrations.
• Confirm the account is selected and reload the dashboard if provider data does not appear.

• Check Admin > Integrations first, then open the provider-specific setup docs for that service.
• Review Status, Last Verified, Inbound Status, and any provider-specific form fields.

If the field is in use, archive it instead. Archived fields stop appearing on new records while preserving existing values.

Single Choice fields require at least one non-empty choice.

• Confirm the tag has a name.
• Check that the color value is a valid hex color.

• Clear search text and filters.
• Check pagination.
• Show hidden columns if you need User or IP Address.

Compare timestamps with the timezone configured for the account in Settings.

Check:

1. Whether the contact unsubscribed, replied STOP, bounced, or triggered a spam complaint.
2. Whether suppression is account-wide or per integration.
3. Whether enrollment handling removed the contact from active flows.
4. Whether the flow is trying to send through an inactive provider, sender, or template.

Only active providers and active templates are available when configuring flow blocks. Some providers also require sender setup before they can be used.

Check:

• Provider status
• Template status
• Sender or from-address setup
• Whether the provider supports the required channel

If enrollment handling is set to suppress future sends only, the contact may remain enrolled but future suppressed sends are blocked. Use Flow Enrollments or Flow History to confirm what happened.

Confirm you are on Dashboard → Flows, clear search/filter controls, and check whether the flow is archived or complete.

Save the editor and confirm blocks and connections are present. The preview depends on saved flow structure.

Open the Flow Editor, save, and resolve any visible errors before changing status or adding more contacts.

Check filters and whether contacts are already enrolled in the flow.

Confirm at least one contact has entered the flow and enough time has passed for events to be recorded.

Refresh the page and select Try Again from the flow load error state.

Only active providers and templates are available in message-based blocks. Confirm the provider and template are active in Integrations then return to the editor.

AI blocks require an active AI integration and the account’s AI features to be enabled. Confirm the AI provider is active before adding or configuring the block.

Open the block and complete its required configuration. Template-created flows can show warnings when providers, senders, recipients, templates, or custom fields were skipped during setup.

Check whether you are trying to create an invalid connection, such as Pause → Pause or Email → Email.

Open the block named in the validation panel, correct the required fields, and save again. Review warnings before activating the flow.

Only active providers and templates are available in message-based blocks. Activate the required record in Integrations or Templates, then reopen the block.

Related Documents: Integrations, Templates

Confirm the recipient address or phone number is valid and the selected provider, sender, and template are active. Review History and Events for the delivery result.

Related Documents: History and Events

A source block is required only for message-event rules. For contact data, enrollment data, tag, reachability, or consent rules, configure the relevant rule type instead.

Check the flow timezone in Flow Settings. Time-based Pause blocks use the flow timezone, or the account timezone when no override is set.

Related Documents: Flow Settings

Confirm that variant percentages total exactly 100%.

Review the target flow or webhook URL, authentication, headers, timeout, and fail-on-error setting.

Save the flow, open the Errors panel, and complete the fields named in the current validation message.

Check for a missing Name or any surfaced server-side validation messages.

Use the full settings form if the card toggle is not enough.

Confirm whether the flow is using the account default timezone or a flow-specific override.

Reopen the editor after saving and verify you are looking at the same flow.

Those fields only appear when your account has flow custom fields configured.

Either the account has no contacts yet or all eligible contacts are already enrolled.

Clear the search box or check spelling.

The edit or create form requires at least an email address or phone number.

Select at least one contact first.

Clear search, status filters, or sort changes.

Inspect the flow configuration and the related flow history for the next clue.

The flow may not have processed any contacts yet.

Clear search and filters, then check that you are looking at the correct flow.

Not every event produces interaction records, and some rows are not expandable.

Filter by Status or Type first, then search for the contact or step name.

Cross-check the contact in Flow enrollments.

Find the matching Step in History.

Filter Status to Error and inspect the Contact column.

Filter Type to Pause or Connection.

Expand the row and review interaction events.

Inspect the related block configuration in Flow blocks or the specific flow setup in the editor.

Check the selected flow and date range first.

The selected period may contain no sends yet.

Open tracking data may not exist yet for the current selection.

Use History and events to inspect the underlying execution records.

Stats is not the right tool; switch to Flow History or Flow Enrollments.

The flow may not have processed any contacts yet.

Clear search and filters, then check that you are looking at the correct flow.

Not every event produces interaction records, and some rows are not expandable.

Filter by Status or Type first, then search for the contact or step name.

Cross-check the contact in Flow enrollments.

Find the matching Step in History.

Filter Status to Error and inspect the Contact column.

Filter Type to Pause or Connection.

Expand the row and review interaction events.

Inspect the related block configuration in Flow blocks or the specific flow setup in the editor.

A contact can remain enrolled in a flow after unsubscribing or receiving a hard-bounce suppression. DripDrop checks suppression when it is about to send, so later messages for the suppressed channel are not sent.

Review the contact in Contacts, then review its flow status in Flow Enrollments.

Check the recipient’s email address or phone number for an earlier unsubscribe, hard bounce, or SMS opt-out. Email matching is case-insensitive.

For the account’s opt-out scope and enrollment-handling rules, see Admin Compliance.

Confirm you are viewing the preview rendering rather than the normal public confirmation page.

Check whether the tracking domain is configured. Preview URL generation changes when a tracking domain is available.

The current product behavior is a single unsubscribe confirmation page. Use Admin Compliance for account-level consent and suppression settings.